OESA-2025-1626

The Linux Kernel, the operating system core itself.

Security Fix(es):

In the Linux kernel, the following vulnerability has been resolved:

scsi: target: Fix WRITE_SAME No Data Buffer crash

In newer version of the SBC specs, we have a NDOB bit that indicates there is no data buffer that gets written out. If this bit is set using commands like "sgwritesame --ndob" we will crash in targetcoreiblock/file's executewritesame handlers when we go to access the secmd->tdata_sg because its NULL.

This patch adds a check for the NDOB bit in the common WRITE SAME code because we don't support it. And, it adds a check for zero SG elements in each handler in case the initiator tries to send a normal WRITE SAME with no data buffer.(CVE-2022-21546)

In the Linux kernel, the following vulnerability has been resolved:

capabilities: fix undefined behavior in bit shift for CAPTOMASK

Shifting signed 32-bit value by 31 bits is undefined, so changing significant bit to unsigned. The UBSAN warning calltrace like below:

UBSAN: shift-out-of-bounds in security/commoncap.c:1252:2 left shift of 1 by 31 places cannot be represented in type 'int' Call Trace: <TASK> dumpstacklvl+0x7d/0xa5 dumpstack+0x15/0x1b ubsanepilogue+0xe/0x4e _ubsanhandleshiftoutofbounds+0x1e7/0x20c captaskprctl+0x561/0x6f0 securitytaskprctl+0x5a/0xb0 _x64sysprctl+0x61/0x8f0 dosyscall64+0x58/0x80 entrySYSCALL64after_hwframe+0x63/0xcd </TASK>(CVE-2022-49870)

In the Linux kernel, the following vulnerability has been resolved:

dm crypt: add condresched() to dmcryptwrite()

The loop in dmcryptwrite may be running for unbounded amount of time, thus we need condresched() in it.

This commit fixes the following warning:

[ 3391.153255][ C12] watchdog: BUG: soft lockup - CPU#12 stuck for 23s! [dmcryptwrite/2:2897] ... [ 3391.387210][ C12] Call trace: [ 3391.390338][ C12] blkattemptbiomerge.part.6+0x38/0x158 [ 3391.395970][ C12] blkattemptplugmerge+0xc0/0x1b0 [ 3391.401085][ C12] blkmqsubmitbio+0x398/0x550 [ 3391.405856][ C12] submitbionoacct+0x308/0x380 [ 3391.410630][ C12] dmcryptwrite+0x1e4/0x208 [dmcrypt] [ 3391.416005][ C12] kthread+0x130/0x138 [ 3391.419911][ C12] retfromfork+0x10/0x18(CVE-2023-53051)

In the Linux kernel, the following vulnerability has been resolved:

mm/vmscan: don't try to reclaim hwpoison folio

Syzkaller reports a bug as follows:

Injecting memory failure for pfn 0x18b00e at process virtual address 0x20ffd000 Memory failure: 0x18b00e: dirty swapcache page still referenced by 2 users Memory failure: 0x18b00e: recovery action for dirty swapcache page: Failed page: refcount:2 mapcount:0 mapping:0000000000000000 index:0x20ffd pfn:0x18b00e memcg:ffff0000dd6d9000 anon flags: 0x5ffffe00482011(locked|dirty|arch1|swapbacked|hwpoison|node=0|zone=2|lastcpupid=0xfffff) raw: 005ffffe00482011 dead000000000100 dead000000000122 ffff0000e232a7c9 raw: 0000000000020ffd 0000000000000000 00000002ffffffff ffff0000dd6d9000 page dumped because: VMBUGONFOLIO(!foliotestuptodate(folio)) ------------[ cut here ]------------ kernel BUG at mm/swapstate.c:184! Internal error: Oops - BUG: 00000000f2000800 [#1] SMP Modules linked in: CPU: 0 PID: 60 Comm: kswapd0 Not tainted 6.6.0-gcb097e7de84e #3 Hardware name: linux,dummy-virt (DT) pstate: 80400005 (Nzcv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : addtoswap+0xbc/0x158 lr : addtoswap+0xbc/0x158 sp : ffff800087f37340 x29: ffff800087f37340 x28: fffffc00052c0380 x27: ffff800087f37780 x26: ffff800087f37490 x25: ffff800087f37c78 x24: ffff800087f377a0 x23: ffff800087f37c50 x22: 0000000000000000 x21: fffffc00052c03b4 x20: 0000000000000000 x19: fffffc00052c0380 x18: 0000000000000000 x17: 296f696c6f662865 x16: 7461646f7470755f x15: 747365745f6f696c x14: 6f6621284f494c4f x13: 0000000000000001 x12: ffff600036d8b97b x11: 1fffe00036d8b97a x10: ffff600036d8b97a x9 : dfff800000000000 x8 : 00009fffc9274686 x7 : ffff0001b6c5cbd3 x6 : 0000000000000001 x5 : ffff0000c25896c0 x4 : 0000000000000000 x3 : 0000000000000000 x2 : 0000000000000000 x1 : ffff0000c25896c0 x0 : 0000000000000000 Call trace: addtoswap+0xbc/0x158 shrinkfoliolist+0x12ac/0x2648 shrinkinactivelist+0x318/0x948 shrinklruvec+0x450/0x720 shrinknodememcgs+0x280/0x4a8 shrinknode+0x128/0x978 balancepgdat+0x4f0/0xb20 kswapd+0x228/0x438 kthread+0x214/0x230 retfromfork+0x10/0x20

I can reproduce this issue with the following steps:

1) When a dirty swapcache page is isolated by reclaim process and the page isn't locked, inject memory failure for the page. meswapcachedirty() clears uptodate flag and tries to delete from lru, but fails. Reclaim process will put the hwpoisoned page back to lru.

2) The process that maps the hwpoisoned page exits, the page is deleted the page will never be freed and will be in the lru forever.

3) If we trigger a reclaim again and tries to reclaim the page, addtoswap() will trigger VMBUGON_FOLIO due to the uptodate flag is cleared.

To fix it, skip the hwpoisoned page in shrinkfoliolist(). Besides, the hwpoison folio may not be unmapped by hwpoisonusermappings() yet, unmap it in shrinkfoliolist(), otherwise the folio will fail to be unmaped by hwpoisonusermappings() since the folio isn't in lru list.(CVE-2025-37834)

In the Linux kernel, the following vulnerability has been resolved:

module: ensure that kobject_put() is safe for module type kobjects

In 'lookuporcreatemodulekobject()', an internal kobject is created using 'modulektype'. So call to 'kobjectput()' on error handling path causes an attempt to use an uninitialized completion pointer in 'modulekobjectrelease()'. In this scenario, we just want to release kobject without an extra synchronization required for a regular module unloading process, so adding an extra check whether 'complete()' is actually required makes 'kobject_put()' safe.(CVE-2025-37995)