NACK/Cmnt: [SRU][J][PATCH 0/1] CVE-2025-37928

[Edoardo Canepa]

Rejected for the following reasons:

Please drop this and mark the CVE not-affected for 5.15; if it must be
carried, it needs a real adaptation using the tree's own restart idiom,
not the upstream hunk.


The upstream splat depends on dm_bufio_lock() taking spin_lock_bh()
under c->no_sleep, which only exists once the dm-bufio tasklet rework
is present; in 5.15 dm_bufio_lock() is unconditionally
mutex_lock_nested() (dm-bufio.c:168), there is no try_verify_in_tasklet
or no_sleep anywhere in drivers/md, and __scan() runs only from
shrink_work(), a plain workqueue item, so the cond_resched() it is
replacing is perfectly legal here.
Worse, the transplant is not safe on this tree: upstream's pre-image
loop is "while (true) { b = cache_evict(...); if (!b) break; ... }" and
carries no iterator across the reschedule point, whereas jammy's is
list_for_each_entry_safe_reverse(b, tmp, &c->lru[l], lru_list)
(dm-bufio.c:1662), so dropping c->lock leaves tmp exposed to
do_global_cleanup() and __evict_old_buffers(), which take the same
per-client lock from separate dm_bufio_wq work items and can free it
via __try_evict_buffer() -> __free_buffer_wake(), or relink it to the
other LRU with __relink_lru()'s list_move() and send the resumed walk
off the wrong list head.
The file states the rule itself in dm_bufio_write_dirty_buffers(),
which runs the same list_for_each_entry_safe_reverse over c->lru[],
takes b->hold_count before unlocking, and still restarts from "again:"
(dm-bufio.c:1281, comment at :1311) - this patch drops the lock in the
sibling loop and just keeps going, while also gating the only
cond_resched() on "freed % 16", which never re-triggers when the LRU is
full of non-evictable buffers.

On 9/10/26 05:24, Cengiz Can via kernel-team wrote:
> https://ubuntu.com/security/CVE-2025-37928
>
> [ Impact ]
>
> In the Linux kernel, the following vulnerability has been resolved:
>
> dm-bufio: don't schedule in atomic context
>
> A BUG was reported as below when CONFIG_DEBUG_ATOMIC_SLEEP and
> try_verify_in_tasklet are enabled. [ 129.444685][ T934] BUG: sleeping function
> called from invalid context at drivers/md/dm-bufio.c:2421 [ 129.444723][ T934]
> in_atomic(): 1, irqs_disabled(): 0, non_block: 0, pid: 934, name: kworker/1:4 [
> 129.444740][ T934] preempt_count: 201, expected: 0 [ 129.444756][ T934] RCU
> nest depth: 0, expected: 0 [ 129.444781][ T934] Preemption disabled at: [
> 129.444789][ T934] [<ffffffd816231900>] shrink_work+0x21c/0x248 [ 129.445167][
> T934] kernel BUG at kernel/sched/walt/walt_debug.c:16! [ 129.445183][ T934]
> Internal error: Oops - BUG: 00000000f2000800 [#1] PREEMPT SMP [ 129.445204][
> T934] Skip md ftrace buffer dump for: 0x1609e0 [ 129.447348][ T934] CPU: 1 PID:
> 934 Comm: kworker/1:4 Tainted: G W OE 6.6.56-android15-8-o-g6f82312b30b9-debug
> #1 1400000003000000474e5500b3187743670464e8 [ 129.447362][ T934] Hardware name:
> Qualcomm Technologies, Inc. Parrot QRD, Alpha-M (DT) [ 129.447373][ T934]
> Workqueue: dm_bufio_cache shrink_work [ 129.447394][ T934] pstate: 60400005
> (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 129.447406][ T934] pc :
> android_rvh_schedule_bug+0x0/0x8 [sched_walt_debug] [ 129.447435][ T934] lr :
> __traceiter_android_rvh_schedule_bug+0x44/0x6c [ 129.447451][ T934] sp :
> ffffffc0843dbc90 [ 129.447459][ T934] x29: ffffffc0843dbc90 x28:
> ffffffffffffffff x27: 0000000000000c8b [ 129.447479][ T934] x26:
> 0000000000000040 x25: ffffff804b3d6260 x24: ffffffd816232b68 [ 129.447497][
> T934] x23: ffffff805171c5b4 x22: 0000000000000000 x21: ffffffd816231900 [
> 129.447517][ T934] x20: ffffff80306ba898 x19: 0000000000000000 x18:
> ffffffc084159030 [ 129.447535][ T934] x17: 00000000d2b5dd1f x16:
> 00000000d2b5dd1f x15: ffffffd816720358 [ 129.447554][ T934] x14:
> 0000000000000004 x13: ffffff89ef978000 x12: 0000000000000003 [ 129.447572][
> T934] x11: ffffffd817a823c4 x10: 0000000000000202 x9 : 7e779c5735de9400 [
> 129.447591][ T934] x8 : ffffffd81560d004 x7 : 205b5d3938373434 x6 :
> ffffffd8167397c8 [ 129.447610][ T934] x5 : 0000000000000000 x4 :
> 0000000000000001 x3 : ffffffc0843db9e0 [ 129.447629][ T934] x2 :
> 0000000000002f15 x1 : 0000000000000000 x0 : 0000000000000000 [ 129.447647][
> T934] Call trace: [ 129.447655][ T934] android_rvh_schedule_bug+0x0/0x8
> [sched_walt_debug 1400000003000000474e550080cce8a8a78606b6] [ 129.447681][
> T934] __might_resched+0x190/0x1a8 [ 129.447694][ T934] shrink_work+0x180/0x248
> [ 129.447706][ T934] process_one_work+0x260/0x624 [ 129.447718][ T934]
> worker_thread+0x28c/0x454 [ 129.447729][ T934] kthread+0x118/0x158 [
> 129.447742][ T934] ret_from_fork+0x10/0x20 [ 129.447761][ T934] Code: ????????
> ???????? ???????? d2b5dd1f (d4210000) [ 129.447772][ T934] ---[ end trace
> 0000000000000000 ]---
>
> dm_bufio_lock will call spin_lock_bh when try_verify_in_tasklet is enabled, and
> __scan will be called in atomic context.
>
> [ Fix ]
>
> jammy/linux: backported from a3d8f0a7f5e8; android_rvh_schedule_bug+0x0/0x8 [sched_walt_debug
>
> [ Test Plan ]
>
> Build and boot tested.
>
> [ Where Problems Could Occur ]
>
> A regression from this change would surface in the device-mapper buffer cache
> (dm-bufio) shrinker and memory-reclaim path, so systems that stack targets on
> top of dm-bufio, such as dm-verity and dm-integrity, are the most likely to be
> affected under memory pressure. Systems that do not use device-mapper targets
> built on dm-bufio are not affected.
>
> [ Other Info ]
>
> Kybele flow-v11-25-ga27c0fa6. Reference: 1b69150a/v1
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_signature.asc
Type: application/pgp-signature
Size: 840 bytes
Desc: OpenPGP digital signature
URL: <https://lists.ubuntu.com/archives/kernel-team/attachments/20260915/b1f69a74/attachment-0001.sig>