CVE-2025-38241
Severity CVSS v4.0:
Pending analysis
Type:
Unavailable / Other
Publication date:
09/07/2025
Last modified:
09/07/2025
Description
In the Linux kernel, the following vulnerability has been resolved:<br />
<br />
mm/shmem, swap: fix softlockup with mTHP swapin<br />
<br />
Following softlockup can be easily reproduced on my test machine with:<br />
<br />
echo always > /sys/kernel/mm/transparent_hugepage/hugepages-64kB/enabled<br />
swapon /dev/zram0 # zram0 is a 48G swap device<br />
mkdir -p /sys/fs/cgroup/memory/test<br />
echo 1G > /sys/fs/cgroup/test/memory.max<br />
echo $BASHPID > /sys/fs/cgroup/test/cgroup.procs<br />
while true; do<br />
dd if=/dev/zero of=/tmp/test.img bs=1M count=5120<br />
cat /tmp/test.img > /dev/null<br />
rm /tmp/test.img<br />
done<br />
<br />
Then after a while:<br />
watchdog: BUG: soft lockup - CPU#0 stuck for 763s! [cat:5787]<br />
Modules linked in: zram virtiofs<br />
CPU: 0 UID: 0 PID: 5787 Comm: cat Kdump: loaded Tainted: G L 6.15.0.orig-gf3021d9246bc-dirty #118 PREEMPT(voluntary)·<br />
Tainted: [L]=SOFTLOCKUP<br />
Hardware name: Red Hat KVM/RHEL-AV, BIOS 0.0.0 02/06/2015<br />
RIP: 0010:mpol_shared_policy_lookup+0xd/0x70<br />
Code: e9 b8 b4 ff ff 31 c0 c3 cc cc cc cc 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 66 0f 1f 00 0f 1f 44 00 00 41 54 55 53 8b 1f 48 85 db 74 41 4c 8d 67 08 48 89 fb 48 89 f5 4c 89 e7 e8<br />
RSP: 0018:ffffc90002b1fc28 EFLAGS: 00000202<br />
RAX: 00000000001c20ca RBX: 0000000000724e1e RCX: 0000000000000001<br />
RDX: ffff888118e214c8 RSI: 0000000000057d42 RDI: ffff888118e21518<br />
RBP: 000000000002bec8 R08: 0000000000000001 R09: 0000000000000000<br />
R10: 0000000000000bf4 R11: 0000000000000000 R12: 0000000000000001<br />
R13: 00000000001c20ca R14: 00000000001c20ca R15: 0000000000000000<br />
FS: 00007f03f995c740(0000) GS:ffff88a07ad9a000(0000) knlGS:0000000000000000<br />
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br />
CR2: 00007f03f98f1000 CR3: 0000000144626004 CR4: 0000000000770eb0<br />
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000<br />
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400<br />
PKRU: 55555554<br />
Call Trace:<br />
<br />
shmem_alloc_folio+0x31/0xc0<br />
shmem_swapin_folio+0x309/0xcf0<br />
? filemap_get_entry+0x117/0x1e0<br />
? xas_load+0xd/0xb0<br />
? filemap_get_entry+0x101/0x1e0<br />
shmem_get_folio_gfp+0x2ed/0x5b0<br />
shmem_file_read_iter+0x7f/0x2e0<br />
vfs_read+0x252/0x330<br />
ksys_read+0x68/0xf0<br />
do_syscall_64+0x4c/0x1c0<br />
entry_SYSCALL_64_after_hwframe+0x76/0x7e<br />
RIP: 0033:0x7f03f9a46991<br />
Code: 00 48 8b 15 81 14 10 00 f7 d8 64 89 02 b8 ff ff ff ff eb bd e8 20 ad 01 00 f3 0f 1e fa 80 3d 35 97 10 00 00 74 13 31 c0 0f 05 3d 00 f0 ff ff 77 4f c3 66 0f 1f 44 00 00 55 48 89 e5 48 83 ec<br />
RSP: 002b:00007fff3c52bd28 EFLAGS: 00000246 ORIG_RAX: 0000000000000000<br />
RAX: ffffffffffffffda RBX: 0000000000040000 RCX: 00007f03f9a46991<br />
RDX: 0000000000040000 RSI: 00007f03f98ba000 RDI: 0000000000000003<br />
RBP: 00007fff3c52bd50 R08: 0000000000000000 R09: 00007f03f9b9a380<br />
R10: 0000000000000022 R11: 0000000000000246 R12: 0000000000040000<br />
R13: 00007f03f98ba000 R14: 0000000000000003 R15: 0000000000000000<br />
<br />
<br />
The reason is simple, readahead brought some order 0 folio in swap cache,<br />
and the swapin mTHP folio being allocated is in conflict with it, so<br />
swapcache_prepare fails and causes shmem_swap_alloc_folio to return<br />
-EEXIST, and shmem simply retries again and again causing this loop.<br />
<br />
Fix it by applying a similar fix for anon mTHP swapin.<br />
<br />
The performance change is very slight, time of swapin 10g zero folios<br />
with shmem (test for 12 times):<br />
Before: 2.47s<br />
After: 2.48s<br />
<br />
[kasong@tencent.com: add comment]