linux-kernel - [BUG] WARNING in sendmsg

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

Message-ID: <CAOU40uC6U3PS3cu7RmK71DPA_jbW_ZY0FBkBjCdjVArCiZO-fA@mail.gmail.com>
Date: Mon, 9 Jun 2025 21:39:59 +0800
From: Xianying Wang <wangxianying546@...il.com>
To: davem@...emloft.net
Cc: edumazet@...gle.com, kuba@...nel.org, pabeni@...hat.com, 
	netdev@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: [BUG] WARNING in sendmsg

Hi,

I discovered a kernel WARNING described as "WARNING in sendmsg"when
fuzzing the Linux 6.8 kernel using Syzkaller. This issue occurs in the
memory allocation path within the sendmsg system call, specifically in
the __alloc_pages function at mm/page_alloc.c:4545. The warning is
triggered by a WARN_ON_ONCE assertion in the page allocator during an
attempt to allocate memory via kmalloc from the socket layer.

This occurs when invoking sendmsg, which internally attempts to
allocate memory for socket buffers via sock_kmalloc(net/core/sock.c).
The allocation triggers a warning due to either an invalid allocation
context (e.g., atomic context with GFP_KERNEL) or memory pressure
conditions that violate allocation constraints.

This may be triggered by an unusual runtime state induced by the
fuzzing program — such as mounting a compressed ext4 filesystem via
loop device, performing ptrace and socket operations, and using
certain sysctl interfaces. This combination may have placed the system
in a constrained memory context, causing __alloc_pages to emit a
warning.

I recommend reviewing the use of kmalloc in sock_kmalloc, particularly
the GFP flags used under socket send operations, and whether the call
can occur in atomic or memory-constrained contexts. It may be
necessary to guard such allocations or use GFP_ATOMIC where
appropriate.

This can be reproduced on:

HEAD commit:

e8f897f4afef0031fe618a8e94127a0934896aba

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

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

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

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

Let me know if you need more details or testing.

Best regards,

Xianying