netdev - Re: null pointer dereference in interrupt after receiving an ip packet on veth from xsk from user space

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>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <da50bdfc-99ae-4c3a-906b-5314192fe1f5@suse.de>
Date: Tue, 21 Oct 2025 17:09:38 +0200
From: Fernando Fernandez Mancera <fmancera@...e.de>
To: Maciej Fijalkowski <maciej.fijalkowski@...el.com>,
 Jason Xing <kerneljasonxing@...il.com>
Cc: mc36 <csmate@....hu>, alekcejk@...glemail.com,
 Jonathan Lemon <jonathan.lemon@...il.com>,
 Stanislav Fomichev <sdf@...ichev.me>,
 Magnus Karlsson <magnus.karlsson@...el.com>, Björn Töpel
 <bjorn@...nel.org>, 1118437@...s.debian.org, netdev@...r.kernel.org,
 bpf@...r.kernel.org
Subject: Re: null pointer dereference in interrupt after receiving an ip
 packet on veth from xsk from user space



On 10/21/25 4:47 PM, Maciej Fijalkowski wrote:
> On Tue, Oct 21, 2025 at 07:02:06PM +0800, Jason Xing wrote:
>> On Tue, Oct 21, 2025 at 5:31 AM mc36 <csmate@....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.
> 

Ugh, sorry then. I just sent a patch to the list and didn't see your 
email. Anyway, I believe it is safer to avoid using skb control block if 
other subsystems might take control over it.

Feel free to discard my patch at: 
https://lore.kernel.org/netdev/20251021150656.6704-1-fmancera@suse.de/

Thanks,
Fernando.

>>
>> Thanks,
>> Jason
>