The Linux Kernel, the operating system core itself.

Security Fix(es):

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

mISDN: fix possible memory leak in mISDNdspelement_register()

Afer commit 1fa5ae857bb1 ("driver core: get rid of struct device's busid string array"), the name of device is allocated dynamically, use putdevice() to give up the reference, so that the name can be freed in kobject_cleanup() when the refcount is 0.

The 'entry' is going to be freed in mISDNdspdevrelease(), so the kfree() is removed. listdel() is called in mISDNdspdev_release(), so it need be initialized.(CVE-2022-49821)

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

pinctrl: devicetree: fix null pointer dereferencing in pinctrldtto_map

Here is the BUG report by KASAN about null pointer dereference:

BUG: KASAN: null-ptr-deref in strcmp+0x2e/0x50 Read of size 1 at addr 0000000000000000 by task python3/2640 Call Trace: strcmp _offindproperty offindproperty pinctrldttomap

kasprintf() would return NULL pointer when kmalloc() fail to allocate. So directly return ENOMEM, if kasprintf() return NULL pointer.(CVE-2022-49832)

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

udf: Fix a slab-out-of-bounds write bug in udffindentry()

Syzbot reported a slab-out-of-bounds Write bug:

loop0: detected capacity change from 0 to 2048

BUG: KASAN: slab-out-of-bounds in udffindentry+0x8a5/0x14f0 fs/udf/namei.c:253 Write of size 105 at addr ffff8880123ff896 by task syz-executor323/3610

CPU: 0 PID: 3610 Comm: syz-executor323 Not tainted 6.1.0-rc2-syzkaller-00105-gb229b6ca5abb #0 Hardware name: Google Compute Engine/Google Compute Engine, BIOS Google 10/11/2022 Call Trace: <TASK> _dumpstack lib/dumpstack.c:88 [inline] dumpstacklvl+0x1b1/0x28e lib/dumpstack.c:106 printaddressdescription+0x74/0x340 mm/kasan/report.c:284 printreport+0x107/0x1f0 mm/kasan/report.c:395 kasanreport+0xcd/0x100 mm/kasan/report.c:495 kasancheckrange+0x2a7/0x2e0 mm/kasan/generic.c:189 memcpy+0x3c/0x60 mm/kasan/shadow.c:66 udffindentry+0x8a5/0x14f0 fs/udf/namei.c:253 udflookup+0xef/0x340 fs/udf/namei.c:309 lookupopen fs/namei.c:3391 [inline] openlastlookups fs/namei.c:3481 [inline] pathopenat+0x10e6/0x2df0 fs/namei.c:3710 dofilpopen+0x264/0x4f0 fs/namei.c:3740 dosysopenat2+0x124/0x4e0 fs/open.c:1310 dosysopen fs/open.c:1326 [inline] _dosyscreat fs/open.c:1402 [inline] _sesyscreat fs/open.c:1396 [inline] _x64syscreat+0x11f/0x160 fs/open.c:1396 dosyscallx64 arch/x86/entry/common.c:50 [inline] dosyscall64+0x3d/0xb0 arch/x86/entry/common.c:80 entrySYSCALL64afterhwframe+0x63/0xcd RIP: 0033:0x7ffab0d164d9 Code: ff ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 c0 ff ff ff f7 d8 64 89 01 48 RSP: 002b:00007ffe1a7e6bb8 EFLAGS: 00000246 ORIG_RAX: 0000000000000055 RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007ffab0d164d9 RDX: 00007ffab0d164d9 RSI: 0000000000000000 RDI: 0000000020000180 RBP: 00007ffab0cd5a10 R08: 0000000000000000 R09: 0000000000000000 R10: 00005555573552c0 R11: 0000000000000246 R12: 00007ffab0cd5aa0 R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000 </TASK>

Allocated by task 3610: kasansavestack mm/kasan/common.c:45 [inline] kasansettrack+0x3d/0x60 mm/kasan/common.c:52 _kasankmalloc mm/kasan/common.c:371 [inline] _kasankmalloc+0x97/0xb0 mm/kasan/common.c:380 kmalloc include/linux/slab.h:576 [inline] udffindentry+0x7b6/0x14f0 fs/udf/namei.c:243 udflookup+0xef/0x340 fs/udf/namei.c:309 lookupopen fs/namei.c:3391 [inline] openlastlookups fs/namei.c:3481 [inline] pathopenat+0x10e6/0x2df0 fs/namei.c:3710 dofilpopen+0x264/0x4f0 fs/namei.c:3740 dosysopenat2+0x124/0x4e0 fs/open.c:1310 dosysopen fs/open.c:1326 [inline] _dosyscreat fs/open.c:1402 [inline] _sesyscreat fs/open.c:1396 [inline] _x64syscreat+0x11f/0x160 fs/open.c:1396 dosyscallx64 arch/x86/entry/common.c:50 [inline] dosyscall64+0x3d/0xb0 arch/x86/entry/common.c:80 entrySYSCALL64afterhwframe+0x63/0xcd

The buggy address belongs to the object at ffff8880123ff800 which belongs to the cache kmalloc-256 of size 256 The buggy address is located 150 bytes inside of 256-byte region [ffff8880123ff800, ffff8880123ff900)

The buggy address belongs to the physical page: page:ffffea000048ff80 refcount:1 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x123fe head:ffffea000048ff80 order:1 compoundmapcount:0 compoundpincount:0 flags: 0xfff00000010200(slab|head|node=0|zone=1|lastcpupid=0x7ff) raw: 00fff00000010200 ffffea00004b8500 dead000000000003 ffff888012041b40 raw: 0000000000000000 0000000080100010 00000001ffffffff 0000000000000000 page dumped because: kasan: bad access detected pageowner tracks the page as allocated page last allocated via order 0, migratetype Unmovable, gfpmask 0x0(), pid 1, tgid 1 (swapper/0), ts 1841222404, freets 0 createdummystack mm/pageowner.c: ---truncated---(CVE-2022-49846)

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

ext4: update sjournalinum if it changes after journal replay

When mounting a crafted ext4 image, sjournalinum may change after journal replay, which is obviously unreasonable because we have successfully loaded and replayed the journal through the old sjournalinum. And the new sjournalinum bypasses some of the checks in ext4getjournal(), which may trigger a null pointer dereference problem. So if sjournalinum changes after the journal replay, we ignore the change, and rewrite the current journal_inum to the superblock.(CVE-2023-53091)

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

xfrm: state: fix out-of-bounds read during lookup

lookup and resize can run in parallel.

The xfrmstatehash_generation seqlock ensures a retry, but the hash functions can observe a hmask value that is too large for the new hlist array.

rehash does: rcuassignpointer(net->xfrm.statebydst, ndst) [..] net->xfrm.statehmask = nhashmask;

While state lookup does: h = xfrmdsthash(net, daddr, saddr, tmpl->reqid, encapfamily); hlistforeachentryrcu(x, net->xfrm.statebydst + h, bydst) {

This is only safe in case the update to statebydst is larger than net->xfrm.xfrmstate_hmask (or if the lookup function gets serialized via state spinlock again).

Fix this by prefetching statehmask and the associated pointers. The xfrmstatehashgeneration seqlock retry will ensure that the pointer and the hmask will be consistent.

The existing helpers, like xfrmdsthash(), are now unsafe for RCU side, add lockdep assertions to document that they are only safe for insert side.

xfrmstatelookup_byaddr() uses the spinlock rather than RCU. AFAICS this is an oversight from back when state lookup was converted to RCU, this lock should be replaced with RCU in a future patch.(CVE-2024-57982)

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

ext4: fix off-by-one error in do_split

Syzkaller detected a use-after-free issue in ext4insertdentry that was caused by out-of-bounds access due to incorrect splitting in do_split.

BUG: KASAN: use-after-free in ext4insertdentry+0x36a/0x6d0 fs/ext4/namei.c:2109 Write of size 251 at addr ffff888074572f14 by task syz-executor335/5847

CPU: 0 UID: 0 PID: 5847 Comm: syz-executor335 Not tainted 6.12.0-rc6-syzkaller-00318-ga9cda7c0ffed #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 10/30/2024 Call Trace: <TASK> _dumpstack lib/dumpstack.c:94 [inline] dumpstacklvl+0x241/0x360 lib/dumpstack.c:120 printaddressdescription mm/kasan/report.c:377 [inline] printreport+0x169/0x550 mm/kasan/report.c:488 kasanreport+0x143/0x180 mm/kasan/report.c:601 kasancheckrange+0x282/0x290 mm/kasan/generic.c:189 _asanmemcpy+0x40/0x70 mm/kasan/shadow.c:106 ext4insertdentry+0x36a/0x6d0 fs/ext4/namei.c:2109 adddirenttobuf+0x3d9/0x750 fs/ext4/namei.c:2154 makeindexeddir+0xf98/0x1600 fs/ext4/namei.c:2351 ext4addentry+0x222a/0x25d0 fs/ext4/namei.c:2455 ext4addnondir+0x8d/0x290 fs/ext4/namei.c:2796 ext4symlink+0x920/0xb50 fs/ext4/namei.c:3431 vfssymlink+0x137/0x2e0 fs/namei.c:4615 dosymlinkat+0x222/0x3a0 fs/namei.c:4641 _dosyssymlink fs/namei.c:4662 [inline] _sesyssymlink fs/namei.c:4660 [inline] _x64syssymlink+0x7a/0x90 fs/namei.c:4660 dosyscallx64 arch/x86/entry/common.c:52 [inline] dosyscall64+0xf3/0x230 arch/x86/entry/common.c:83 entrySYSCALL64after_hwframe+0x77/0x7f </TASK>

The following loop is located right above 'if' statement.

for (i = count-1; i >= 0; i--) { /* is more than half of this entry in 2nd half of the block? */ if (size + map[i].size/2 > blocksize/2) break; size += map[i].size; move++; }

'i' in this case could go down to -1, in which case sum of active entries wouldn't exceed half the block size, but previous behaviour would also do split in half if sum would exceed at the very last block, which in case of having too many long name files in a single block could lead to out-of-bounds access and following use-after-free.

Found by Linux Verification Center (linuxtesting.org) with Syzkaller.(CVE-2025-23150)

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

jbd2: remove wrong sb->s_sequence check

Journal emptiness is not determined by sb->ssequence == 0 but rather by sb->sstart == 0 (which is set a few lines above). Furthermore 0 is a valid transaction ID so the check can spuriously trigger. Remove the invalid WARN_ON.(CVE-2025-37839)