linux-kernel - [BUG] BUG: scheduling while atomic in throttle_direct

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: <CAOU40uDrsJH2562F4FdxEatGmxRyX0anmFiXN97+gOKDqAHmbA@mail.gmail.com>
Date: Mon, 26 May 2025 23:49:30 +0800
From: Xianying Wang <wangxianying546@...il.com>
To: akpm@...ux-foundation.org
Cc: linux-mm@...ck.org, linux-kernel@...r.kernel.org
Subject: [BUG] BUG: scheduling while atomic in throttle_direct_reclaim

Hi,

I discovered a kernel crash described as "BUG: scheduling while atomic
in throttle_direct_reclaim." This issue occurs in the memory reclaim
path, specifically in the throttle_direct_reclaim function
(mm/vmscan.c), where the kernel attempts to perform a potentially
blocking operation (schedule_timeout) while still in an atomic or
non-preemptible context, leading to an invalid scheduling state and
triggering __schedule_bug().

The crash trace shows that this condition can occur when the kernel
mounts a specially crafted ISO9660 image via syz_mount_image$iso9660.
During image parsing, the VFS initiates page readahead through
read_pages, which issues block I/O backed by a loop device. This leads
to a SCSI read path where scsi_alloc_sgtables
(drivers/scsi/scsi_lib.c) attempts to allocate memory for a
scatterlist using mempool_alloc. If memory pressure is present,
mempool_alloc triggers try_to_free_pages, and subsequently
throttle_direct_reclaim.

At this point, the kernel is likely in an atomic context due to
earlier direct reclaim or preemption disabling within the block layer
or SCSI stack. As a result, schedule_timeout is not allowed and
triggers a BUG.

I recommend reviewing the reclaim context propagation in:

scsi_alloc_sgtables and sg_alloc_table_chained
mempool_alloc in SCSI I/O paths
throttle_direct_reclaim to ensure blocking calls are not made from
atomic contexts

This can be reproduced on:

HEAD commit:

commit e8f897f4afef0031fe618a8e94127a0934896aba

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

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

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

C reproducer : https://pastebin.com/raw/1dku01DG

Best regards,

Xianying