lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [day] [month] [year] [list]
Message-ID: <87h5wh34sl.fsf@cloudflare.com>
Date: Thu, 02 Oct 2025 13:46:02 +0200
From: Jakub Sitnicki <jakub@...udflare.com>
To: Sunil Goutham <sgoutham@...vell.com>, Geetha sowjanya
 <gakula@...vell.com>, Subbaraya Sundeep <sbhatta@...vell.com>, hariprasad
 <hkelam@...vell.com>, Bharat Bhushan <bbhushan2@...vell.com>
Cc: netdev@...r.kernel.org
Subject: marvell/octeontx2: XDP vs skb headroom reservation

Hi,

I'm auditing calls to skb_metadata_set() in drivers and something seems
off in oceontx2. I may be completely misreading the code. I'm a total
stranger to that driver.

It would seem that there is a difference between the amount of headroom
that the driver reserves for the XDP buffer vs the skb that is built
from on that buffer, while the two should match.

In the receive handler we have:

otx2_rcv_pkt_handler
  otx2_xdp_rcv_pkt_handler if pfvf->xdp_prog
    xdp_prepare_buff(..., OTX2_HEAD_ROOM, ...)
      where OTX2_HEAD_ROOM = OTX2_ALIGN = 128
  skb = napi_get_frags
    napi_alloc_skb
      skb_reserve(NET_SKB_PAD + NET_IP_ALIGN)
        where NET_SKB_PAD = 64, NET_IP_ALIGN = 0 on x86
  napi_gro_frags

There are no other calls to skb_reserve there, so we seem to have a
mismatch. 128B of headroom in XDP buff, and only 64B of headroom in skb
head.

Again, I could be totally wrong about this, I'm not familiar with the
driver, but I thought you might want to double check this.

Thanks,
-jkbs

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ