netdev - [BUG] BUG: unable to handle kernel paging request in napi_skb_cache

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: <CAOU40uD8Ogy=bLf6gOK1dVJRNBcW5zMDLnwjiEuipHN8j2TPPQ@mail.gmail.com>
Date: Wed, 16 Jul 2025 16:29:11 +0800
From: Xianying Wang <wangxianying546@...il.com>
To: davem@...emloft.net
Cc: edumazet@...gle.com, kuba@...nel.org, pabeni@...hat.com, horms@...nel.org, 
	netdev@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: [BUG] BUG: unable to handle kernel paging request in napi_skb_cache_get

Hi,

I discovered a kernel page fault using the Syzkaller framework,
described as BUG: unable to handle kernel paging request. This issue
was reproduced on kernel version 6.16.0-rc5.

>From the dmesg log, the crash occurs directly within the
napi_skb_cache_get function (net/core/skbuff.c:295) during the network
softirq context. The page fault itself (#PF: error_code(0x000b) -
reserved bit violation) indicates that the kernel tried to write to a
memory address with invalid page table entries, strongly suggesting
memory corruption.

Meanwhile, a second stack trace points to the probable source of
corruption, where kfree is called from the iter_file_splice_write
function (fs/splice.c:767) during a sendfile system call.

This crash is likely caused by the interaction between these two
paths. I suspect this is a use-after-free or double-free
vulnerability. The sendfile/splice path appears to incorrectly free an
SKB, corrupting the memory pool (napi_skb_cache). Subsequently, when
the network receive path attempts to allocate from this corrupted
pool, it receives an invalid pointer, leading to the page fault.

Therefore, I recommend reviewing the SKB lifecycle management in the
sendfile/splice implementation, specifically around
iter_file_splice_write, and its interaction with the NAPI SKB cache.

This can be reproduced on:

HEAD commit:

d7b8f8e20813f0179d8ef519541a3527e7661d3a

report: https://pastebin.com/raw/X5w3B46p

console output : https://pastebin.com/raw/aDMVEtzw

kernel config : https://pastebin.com/raw/xAVw5DnH

C reproducer : https://pastebin.com/raw/Gu48eTDw

Let me know if you need more details or testing.

Best regards,

Xianying