Bug#1118437: null pointer dereference in interrupt after receiving an ip packet on veth from xsk from user space
- To: Jason Xing <kerneljasonxing@gmail.com>
- Cc: mc36 <csmate@nop.hu>, <alekcejk@googlemail.com>, Jonathan Lemon <jonathan.lemon@gmail.com>, Stanislav Fomichev <sdf@fomichev.me>, "Magnus Karlsson" <magnus.karlsson@intel.com>, Björn Töpel <bjorn@kernel.org>, <1118437@bugs.debian.org>, <netdev@vger.kernel.org>, <bpf@vger.kernel.org>
- Subject: Bug#1118437: null pointer dereference in interrupt after receiving an ip packet on veth from xsk from user space
- From: Maciej Fijalkowski <maciej.fijalkowski@intel.com>
- Date: Tue, 21 Oct 2025 16:47:55 +0200
- Message-id: <[🔎] aPedG99fdFBnbIqz@boxer>
- Reply-to: Maciej Fijalkowski <maciej.fijalkowski@intel.com>, 1118437@bugs.debian.org
- In-reply-to: <[🔎] CAL+tcoA0TKWQY4oP4jJ5BHmEnA+HzHRrgsnQL9vRpnaqb+_8Ag@mail.gmail.com>
- References: <[🔎] 0435b904-f44f-48f8-afb0-68868474bf1c@nop.hu> <[🔎] CAL+tcoA5qDAcnZpmULsnD=X6aVP-ztRxPv5z1OSP-nvtNEk+-w@mail.gmail.com> <[🔎] 643fbe8f-ba76-49b4-9fb7-403535fd5638@nop.hu> <[🔎] CAL+tcoDqgQbs20xV34RFWDoE5YPXS-ne3FBns2n9t4eggx8LAQ@mail.gmail.com> <[🔎] d8808206-0951-4512-91cb-58839ba9b8c4@nop.hu> <[🔎] CAL+tcoA0TKWQY4oP4jJ5BHmEnA+HzHRrgsnQL9vRpnaqb+_8Ag@mail.gmail.com> <[🔎] 176091056328.779313.4901801207060344593.reportbug@noti>
On Tue, Oct 21, 2025 at 07:02:06PM +0800, Jason Xing wrote:
> On Tue, Oct 21, 2025 at 5:31 AM mc36 <csmate@nop.hu> wrote:
> >
> > hi,
> >
> > On 10/20/25 11:04, Jason Xing wrote:
> > >
> > > I followed your steps you attached in your code:
> > > ////// gcc xskInt.c -lxdp
> > > ////// sudo ip link add veth1 type veth
> > > ////// sudo ip link set veth0 up
> > > ////// sudo ip link set veth1 up
> >
> > ip link set dev veth1 address 3a:10:5c:53:b3:5c
>
> Great, it indeed helps me reproduce the issue, so I managed to see the
> exact same stack. Let me dig into it more deeply.
splat comes from skb_orphan() calling skb->destructor() with ::cb field
being already taken by IP layer. A hotfix would simply be moving this call
before we memset cb in ip_rcv_core():
diff --git a/net/ipv4/ip_input.c b/net/ipv4/ip_input.c
index 273578579a6b..db30645f8c35 100644
--- a/net/ipv4/ip_input.c
+++ b/net/ipv4/ip_input.c
@@ -535,14 +535,14 @@ static struct sk_buff *ip_rcv_core(struct sk_buff *skb, struct net *net)
iph = ip_hdr(skb);
skb->transport_header = skb->network_header + iph->ihl*4;
- /* Remove any debris in the socket control block */
- memset(IPCB(skb), 0, sizeof(struct inet_skb_parm));
- IPCB(skb)->iif = skb->skb_iif;
-
/* Must drop socket now because of tproxy. */
if (!skb_sk_is_prefetched(skb))
skb_orphan(skb);
+ /* Remove any debris in the socket control block */
+ memset(IPCB(skb), 0, sizeof(struct inet_skb_parm));
+ IPCB(skb)->iif = skb->skb_iif;
+
return skb;
csum_error:
However, I do not understand why setting mac addr on one veth interface
triggers this path.
>
> Thanks,
> Jason
Reply to: