linux-kernel - Re: [BUG] Possible Null-Pointer-Dereference Vulnerability in udp_gro_receive

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: <CANn89iL2jGPyPhha3J8y_FV_31tGHJ4mQSSvyewcPh4dzbOVKg@mail.gmail.com>
Date: Thu, 3 Jul 2025 22:22:39 -0700
From: Eric Dumazet <edumazet@...gle.com>
To: 邹懿 <21302010073@...udan.edu.cn>
Cc: davem <davem@...emloft.net>, dsahern <dsahern@...nel.org>, kuba <kuba@...nel.org>, 
	pabeni <pabeni@...hat.com>, netdev <netdev@...r.kernel.org>, 
	linux-kernel <linux-kernel@...r.kernel.org>
Subject: Re: [BUG] Possible Null-Pointer-Dereference Vulnerability in
 udp_gro_receive_segment Function

On Thu, Jul 3, 2025 at 8:20 PM 邹懿 <21302010073@...udan.edu.cn> wrote:
>
> Our team recently developed a null-pointer-dereference vulnerability detection tool, and we have employed it to scan the Linux Kernel (version 6.9.6). After manual review, we found some potentially vulnerable code snippets which may have null-pointer-dereference bugs. Therefore, we would appreciate your expert insight to confirm whether these vulnerabilities could indeed pose a risk to the system.
>
> Vulnerability Description:
>
> File: /net/ipv4/udp_offload.c
>
> In the function udp_gro_receive_segment, the variable uh is assigned via: struct udphdr *uh = udp_gro_udphdr(skb); However, udp_gro_udphdr() internally calls skb_gro_header(), which may fall back to skb_gro_header_slow() and potentially return NULL. If that happens, uh will be NULL, and the subsequent dereference: if (!uh->check) { may lead to a null pointer dereference (NPD).
>
> Proposed Fix:
>
> To prevent the potential null-pointer dereference, we suggest adding a NULL check before attempting to dereference.
>
> Request for Review:
>
> We would appreciate your expert insight to confirm whether this vulnerability indeed poses a risk to the system, and if the proposed fix is appropriate.
>
> Thank you for your time and consideration.


Callers of  udp_gro_receive_segment() (via udp_gro_receive()) are
udp4_gro_receive() and udp6_gro_receive()

They both bail out if udp_gro_udphdr() return NULL.

If the first call to udp_gro_udphdr() does not return NULL, another
call to udp_gro_udphdr() will return the same value.

I might miss something, but I think your tool has a false positive.

Can you double check ?

Thank you.