netdev - Re: [net-next PATCH 0/4] fbnic: Synchronize address handling with BMC

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <CAKgT0UdrVYpWW-4BVda7A7dwta-d_mod1-3dy2vNcx+b-+YtTQ@mail.gmail.com>
Date: Thu, 28 Aug 2025 08:09:19 -0700
From: Alexander Duyck <alexander.duyck@...il.com>
To: Paolo Abeni <pabeni@...hat.com>
Cc: netdev@...r.kernel.org, kuba@...nel.org, kernel-team@...a.com, 
	andrew+netdev@...n.ch, davem@...emloft.net, 
	Mohsin Bashir <mohsin.bashr@...il.com>
Subject: Re: [net-next PATCH 0/4] fbnic: Synchronize address handling with BMC

On Thu, Aug 28, 2025 at 5:50 AM Paolo Abeni <pabeni@...hat.com> wrote:
>
> On 8/28/25 12:46 PM, Paolo Abeni wrote:
> > On 8/26/25 9:44 PM, Alexander Duyck wrote:
> >> The fbnic driver needs to communicate with the BMC if it is operating on
> >> the RMII-based transport (RBT) of the same port the host is on. To enable
> >> this we need to add rules that will route BMC traffic to the RBT/BMC and
> >> the BMC and firmware need to configure rules on the RBT side of the
> >> interface to route traffic from the BMC to the host instead of the MAC.
> >>
> >> To enable that this patch set addresses two issues. First it will cause the
> >> TCAM to be reconfigured in the event that the BMC was not previously
> >> present when the driver was loaded, but the FW sends a notification that
> >> the FW capabilities have changed and a BMC w/ various MAC addresses is now
> >> present. Second it adds support for sending a message to the firmware so
> >> that if the host adds additional MAC addresses the FW can be made aware and
> >> route traffic for those addresses from the RBT to the host instead of the
> >> MAC.
> >
> > The CI is observing a few possible leaks on top of this series:
> >
> > unreferenced object 0xffff888011146040 (size 216):
> >   comm "napi/enp1s0-0", pid 4116, jiffies 4295559830
> >   hex dump (first 32 bytes):
> >     c0 bc a0 08 80 88 ff ff 00 00 00 00 00 00 00 00  ................
> >     00 40 02 08 80 88 ff ff 00 00 00 00 00 00 00 00  .@..............
> >   backtrace (crc d10d3409):
> >     kmem_cache_alloc_bulk_noprof+0x115/0x160
> >     napi_skb_cache_get+0x423/0x750
> >     napi_build_skb+0x19/0x210
> >     xdp_build_skb_from_buff+0xda/0x820
> >     fbnic_run_xdp+0x36c/0x550
> >     fbnic_clean_rcq+0x540/0x1790
> >     fbnic_poll+0x142/0x290
> >     __napi_poll.constprop.0+0x9f/0x460
> >     napi_threaded_poll_loop+0x44d/0x610
> >     napi_threaded_poll+0x17/0x30
> >     kthread+0x37b/0x5f0
> >     ret_from_fork+0x240/0x320
> >     ret_from_fork_asm+0x11/0x20
> > unreferenced object 0xffff888008a0bcc0 (size 216):
> >   comm "napi/enp1s0-0", pid 4116, jiffies 4295560865
> >   hex dump (first 32 bytes):
> >     00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
> >     00 40 02 08 80 88 ff ff 00 00 00 00 00 00 00 00  .@..............
> >   backtrace (crc d69e2bd9):
> >     kmem_cache_alloc_node_noprof+0x289/0x330
> >     __alloc_skb+0x20f/0x2e0
> >     __tcp_send_ack.part.0+0x68/0x6b0
> >     tcp_rcv_established+0x69c/0x2340
> >     tcp_v6_do_rcv+0x9b4/0x1370
> >     tcp_v6_rcv+0x1bc5/0x2f90
> >     ip6_protocol_deliver_rcu+0x112/0x1140
> >     ip6_input+0x201/0x5e0
> >     ip6_sublist_rcv_finish+0x91/0x260
> >     ip6_list_rcv_finish.constprop.0+0x55b/0xa10
> >     ipv6_list_rcv+0x318/0x4b0
> >     __netif_receive_skb_list_core+0x4c6/0x980
> >     netif_receive_skb_list_internal+0x63c/0xe50
> >     gro_complete.constprop.0+0x54d/0x750
> >     __gro_flush+0x14a/0x490
> >     __napi_poll.constprop.0+0x319/0x460
> >
> > But AFAICS they don't look related to the changes in this series,
>
> I went over the series with more attention, I'm reasonably sure the leak
> are unrelated. Possibly is kmemleak fouled by some unfortunate timing?
>
> In any case I'm applying this series now.
>
> /P

Yeah, as far as I can tell this would most likely be related to the
recent XDP changes that were added by Mohsin. I added him to the Cc
just so he is aware. As far as I know we haven't seen anything similar
in our CI, but we will keep an eye out for it and will track it
internally as a sighting in the event that we start seeing similar
issues.

Thanks,

- Alex