https://bugs.dpdk.org/show_bug.cgi?id=796
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.v...@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 workaround
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 where
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 return
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 also
does not check this condition and so if we call
"char *base_pkt_address = rte_pktmbuf_mtod(pkts[i],char *);"
where pkts[i]->buf_addr == NULL, then base_pkt_address will not get a valid
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 this
was produced using the uio_pci_generic driver.
Thanks
--
You are receiving this mail because:
You are the assignee for the bug.
