From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mails.dpdk.org (mails.dpdk.org [217.70.189.124]) by inbox.dpdk.org (Postfix) with ESMTP id 3BF1E462CA; Wed, 26 Feb 2025 16:19:36 +0100 (CET) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id DA9AE4029F; Wed, 26 Feb 2025 16:19:35 +0100 (CET) Received: from inbox.dpdk.org (inbox.dpdk.org [95.142.172.178]) by mails.dpdk.org (Postfix) with ESMTP id E2F264026C for ; Wed, 26 Feb 2025 16:19:34 +0100 (CET) Received: by inbox.dpdk.org (Postfix, from userid 33) id B7095462CB; Wed, 26 Feb 2025 16:19:34 +0100 (CET) From: bugzilla@dpdk.org To: dev@dpdk.org Subject: [DPDK/other Bug 1665] __rte_trace_mem_get causing out of bounds write Date: Wed, 26 Feb 2025 15:19:34 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: new X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: DPDK X-Bugzilla-Component: other X-Bugzilla-Version: 24.11 X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: oleksandrn@interfacemasters.com X-Bugzilla-Status: UNCONFIRMED X-Bugzilla-Resolution: X-Bugzilla-Priority: Normal X-Bugzilla-Assigned-To: dev@dpdk.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: bug_id short_desc product version rep_platform op_sys bug_status bug_severity priority component assigned_to reporter target_milestone Message-ID: Content-Type: multipart/alternative; boundary=17405831740.c4D0F.392278 Content-Transfer-Encoding: 7bit X-Bugzilla-URL: http://bugs.dpdk.org/ Auto-Submitted: auto-generated X-Auto-Response-Suppress: All MIME-Version: 1.0 X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org --17405831740.c4D0F.392278 Date: Wed, 26 Feb 2025 16:19:34 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: http://bugs.dpdk.org/ Auto-Submitted: auto-generated X-Auto-Response-Suppress: All https://bugs.dpdk.org/show_bug.cgi?id=3D1665 Bug ID: 1665 Summary: __rte_trace_mem_get causing out of bounds write Product: DPDK Version: 24.11 Hardware: All OS: All Status: UNCONFIRMED Severity: normal Priority: Normal Component: other Assignee: dev@dpdk.org Reporter: oleksandrn@interfacemasters.com Target Milestone: --- When almost out of trace memory, __rte_trace_mem_get can write out of bound= s. It happens in my case if I have trace events of sizes that are not aligned = to __RTE_TRACE_EVENT_HEADER_SZ. like 27,33 etc. I suspect that the issue is with the incorrect bounds check in __rte_trace_mem_get. > uint32_t offset =3D trace->offset; > if (unlikely((offset + sz) >=3D trace->len)) { // assume condition is = false, > and offset is not aligned > ...} > offset =3D RTE_ALIGN_CEIL(offset, __RTE_TRACE_EVENT_HEADER_SZ); // aft= er > offset alignment offset + size might be bigger than trace->len > void *mem =3D RTE_PTR_ADD(&trace->mem[0], offset); // returning memory= chunk > that is smaller than requested size For example: offset =3D 21, len =3D 32, size =3D 9 -> offset + size is smaller than len align offset to __RTE_TRACE_EVENT_HEADER_SZ -> offset =3D 24 offset + size is bigger than len. --=20 You are receiving this mail because: You are the assignee for the bug.= --17405831740.c4D0F.392278 Date: Wed, 26 Feb 2025 16:19:34 +0100 MIME-Version: 1.0 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: http://bugs.dpdk.org/ Auto-Submitted: auto-generated X-Auto-Response-Suppress: All
Bug ID 1665
Summary __rte_trace_mem_get causing out of bounds write
Product DPDK
Version 24.11
Hardware All
OS All
Status UNCONFIRMED
Severity normal
Priority Normal
Component other
Assignee dev@dpdk.org
Reporter oleksandrn@interfacemasters.com
Target Milestone --- 

When almost out of trace memory, _=
_rte_trace_mem_get can write out of bounds.

It happens in my case if I have trace events of sizes that are not aligned =
to
__RTE_TRACE_EVENT_HEADER_SZ. like 27,33 etc.

I suspect that the issue is with the incorrect bounds check in
__rte_trace_mem_get.

>    uint32_t offset =3D trace->offset;
>    if (unlikely((offset + sz) >=3D trace->len)) { // assume cond=
ition is false,
>    and offset is not aligned
>    ...}
>    offset =3D RTE_ALIGN_CEIL(offset, __RTE_TRACE_EVENT_HEADER_SZ); // =
after
>    offset alignment offset + size might be bigger than trace->len
>    void *mem =3D RTE_PTR_ADD(&trace->mem[0], offset); // return=
ing memory chunk
>    that is smaller than requested size


For example:
offset =3D 21, len =3D 32, size =3D 9 -> offset + size is smaller than l=
en
align offset to __RTE_TRACE_EVENT_HEADER_SZ -> offset =3D 24
offset + size is bigger than len.

You are receiving this mail because:
  • You are the assignee for the bug.
=20=20=20=20=20=20=20=20=20=20
= --17405831740.c4D0F.392278--