Re: [PATCH net-next 00/11] netfilter: updates for net-next

[Florian Westphal <fw@strlen.de>]

Jakub Kicinski <kuba@kernel.org> wrote:
> On Fri, 10 Apr 2026 13:23:41 +0200 Florian Westphal wrote:
> > 1-3) IPVS updates from Julian Anastasov to enhance visibility into
> >      IPVS internal state by exposing hash size, load factor etc and
> >      allows userspace to tune the load factor used for resizing hash
> >      tables.
> 
> Someone should take a look at the Sashiko reports for those, please?

https://sashiko.dev/#/patchset/20260410112352.23599-1-fw%40strlen.de

Sorry Pablo I am dumping this on you.  Already wasted 3h on saturday
on LLM crap 8-(

---------
Could this trigger the DEBUG_NET_WARN_ON_ONCE() inside skb_mac_header_len()?
If a user program sends a verdict containing the NFQA_L2HDR attribute for a
packet where the MAC header is not set, it seems this code would call
skb_mac_header_len() without first checking skb_mac_header_was_set(entry->skb).
---------

And thus a new era of cargo cult programming will be born.

Because I have no idea how on earth PF_BRIDGE packets cannot have
a mac header attached to them.

Do I add this check as LLM overlord demands?

-------------
Is it safe to access the IP header here without ensuring the packet length
is sufficient and the header is in the linear data area?
Looking at the surrounding code in nft_fwd_neigh_eval(),
skb_try_make_writable() is called with sizeof(*iph), which is 20 bytes. At
the netdev hook, skb->data points to the MAC header, meaning the 20 bytes
only covers the Ethernet header and the first 6 bytes of the IP header.
Should this code use pskb_may_pull() or skb_ensure_writable() with an
offset that accounts for skb_network_offset(skb) + sizeof(*iph) before
dereferencing iph->ttl to avoid out-of-bounds accesses?
-------------

Dunno.  Existing code does that.