From mboxrd@z Thu Jan 1 00:00:00 1970
Return-Path: <dev-bounces@dpdk.org>
Received: from mails.dpdk.org (mails.dpdk.org [217.70.189.124])
by inbox.dpdk.org (Postfix) with ESMTP id B99FEA0C43;
Thu, 26 Aug 2021 16:39:56 +0200 (CEST)
Received: from [217.70.189.124] (localhost [127.0.0.1])
by mails.dpdk.org (Postfix) with ESMTP id 698BB4120D;
Thu, 26 Aug 2021 16:39:56 +0200 (CEST)
Received: from inbox.dpdk.org (inbox.dpdk.org [95.142.172.178])
by mails.dpdk.org (Postfix) with ESMTP id 4915540689
for <dev@dpdk.org>; Thu, 26 Aug 2021 16:39:55 +0200 (CEST)
Received: by inbox.dpdk.org (Postfix, from userid 33)
id 2B736A0C4B; Thu, 26 Aug 2021 16:39:55 +0200 (CEST)
From: bugzilla@dpdk.org
To: dev@dpdk.org
Date: Thu, 26 Aug 2021 14:39:55 +0000
X-Bugzilla-Reason: AssignedTo
X-Bugzilla-Type: new
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: DPDK
X-Bugzilla-Component: ethdev
X-Bugzilla-Version: 21.05
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: camilo.vega@mail.utoronto.ca
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: <bug-796-3@http.bugs.dpdk.org/>
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
MIME-Version: 1.0
Subject: [dpdk-dev] [Bug 796] Lack of error checking in rte_pktmbuf_mtod
could lead to a seg fault
X-BeenThere: dev@dpdk.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: DPDK patches and discussions <dev.dpdk.org>
List-Unsubscribe: <https://mails.dpdk.org/options/dev>,
<mailto:dev-request@dpdk.org?subject=unsubscribe>
List-Archive: <http://mails.dpdk.org/archives/dev/>
List-Post: <mailto:dev@dpdk.org>
List-Help: <mailto:dev-request@dpdk.org?subject=help>
List-Subscribe: <https://mails.dpdk.org/listinfo/dev>,
<mailto:dev-request@dpdk.org?subject=subscribe>
Errors-To: dev-bounces@dpdk.org
Sender: "dev" <dev-bounces@dpdk.org>
https://bugs.dpdk.org/show_bug.cgi?id=3D796
Bug ID: 796
Summary: Lack of error checking in rte_pktmbuf_mtod could lead
to a seg fault
Product: DPDK
Version: 21.05
Hardware: All
OS: All
Status: UNCONFIRMED
Severity: normal
Priority: Normal
Component: ethdev
Assignee: dev@dpdk.org
Reporter: camilo.vega@mail.utoronto.ca
Target Milestone: ---
I have been working with DPDK and I came across a bug that unless well
documented could lead to a segmentation fault at runtime. I have a workarou=
nd
but I wanted to let you know to help the community improve. When calling
rte_eth_rx_burst at very high speeds (above 10G), we will on very rare
occasions (It usually takes hours to reproduce) we receive packet bursts wh=
ere
most of the packets are valid but one or more packets in the middle have
pkts[i]->buf_addr equal to NULL (potentially due to a NIC glitch I assume).=
The
problem is that this parameter is usually abstracted away from the user who
would normally just use the rte_pktmbuf_mtod to perform the checks and retu=
rn
the address to the payload rather than accessing it directly, and therefore
would not think, unless the documentation explicitly requires it, to check =
if
pkts[i]->buf_addr is NULL for any of the values or not. rte_pktmbuf_mtod al=
so
does not check this condition and so if we call=20
"char *base_pkt_address =3D rte_pktmbuf_mtod(pkts[i],char *);"=20
where pkts[i]->buf_addr =3D=3D NULL, then base_pkt_address will not get a v=
alid
address but instead gets 0+the size of the preamble (which is usually the
constant 0x80). This is not a value the user would normally be checking for,
they would instead typically check if base_pkt_address is NULL and otherwise
assume the pointer is valid. Attempting to use the data pointed to by
base_pkt_address will then lead to a segmentation fault as we try to access
invalid address 0x80.
I am using dpdk-21.05. I have an older NIC that does not support VFIO so th=
is
was produced using the uio_pci_generic driver.
Thanks
--=20
You are receiving this mail because:
You are the assignee for the bug.=