OESA-2026-1643

The Linux Kernel, the operating system core itself.

Security Fix(es):

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

fs/xattr: missing fdput() in fremovexattr error path

In the Linux kernel, the fremovexattr() syscall calls fdget() to acquire a file reference but returns early without calling fdput() when strncpyfromuser() fails on the name argument. In multi-threaded processes where fdget() takes the slow path, this permanently leaks one file reference per call, pinning the struct file and associated kernel objects in memory. An unprivileged local user can exploit this to cause kernel memory exhaustion. The issue was inadvertently fixed by commit a71874379ec8 ("xattr: switch to CLASS(fd)").(CVE-2024-14027)

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

pps: Fix a use-after-free

On a board running ntpd and gpsd, I'm seeing a consistent use-after-free in sys_exit() from gpsd when rebooting:

pps pps1: removed
------------[ cut here ]------------
kobject: '(null)' (00000000db4bec24): is not initialized, yet kobject_put() is being called.
WARNING: CPU: 2 PID: 440 at lib/kobject.c:734 kobject_put+0x120/0x150
CPU: 2 UID: 299 PID: 440 Comm: gpsd Not tainted 6.11.0-rc6-00308-gb31c44928842 #1
Hardware name: Raspberry Pi 4 Model B Rev 1.1 (DT)
pstate: 60000005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)
pc : kobject_put+0x120/0x150
lr : kobject_put+0x120/0x150
sp : ffffffc0803d3ae0
x29: ffffffc0803d3ae0 x28: ffffff8042dc9738 x27: 0000000000000001
x26: 0000000000000000 x25: ffffff8042dc9040 x24: ffffff8042dc9440
x23: ffffff80402a4620 x22: ffffff8042ef4bd0 x21: ffffff80405cb600
x20: 000000000008001b x19: ffffff8040b3b6e0 x18: 0000000000000000
x17: 0000000000000000 x16: 0000000000000000 x15: 696e6920746f6e20
x14: 7369203a29343263 x13: 205d303434542020 x12: 0000000000000000
x11: 0000000000000000 x10: 0000000000000000 x9 : 0000000000000000
x8 : 0000000000000000 x7 : 0000000000000000 x6 : 0000000000000000
x5 : 0000000000000000 x4 : 0000000000000000 x3 : 0000000000000000
x2 : 0000000000000000 x1 : 0000000000000000 x0 : 0000000000000000
Call trace:
 kobject_put+0x120/0x150
 cdev_put+0x20/0x3c
 __fput+0x2c4/0x2d8
 ____fput+0x1c/0x38
 task_work_run+0x70/0xfc
 do_exit+0x2a0/0x924
 do_group_exit+0x34/0x90
 get_signal+0x7fc/0x8c0
 do_signal+0x128/0x13b4
 do_notify_resume+0xdc/0x160
 el0_svc+0xd4/0xf8
 el0t_64_sync_handler+0x140/0x14c
 el0t_64_sync+0x190/0x194
---[ end trace 0000000000000000 ]---

...followed by more symptoms of corruption, with similar stacks:

refcount_t: underflow; use-after-free.
kernel BUG at lib/list_debug.c:62!
Kernel panic - not syncing: Oops - BUG: Fatal exception

This happens because ppsdevicedestruct() frees the ppsdevice with the embedded cdev immediately after calling cdevdel(), but, as the comment above cdevdel() notes, fops for previously opened cdevs are still callable even after cdevdel() returns. I think this bug has always been there: I can't explain why it suddenly started happening every time I reboot this particular board.

In commit d953e0e837e6 ("pps: Fix a use-after free bug when unregistering a source."), George Spelvin suggested removing the embedded cdev. That seems like the simplest way to fix this, so I've implemented his suggestion, using __registerchrdev() with ppsidr becoming the source of truth for which minor corresponds to which device.

But now that ppsidr defines userspace visibility instead of cdevadd(), we need to be sure the pps->dev refcount can't reach zero while userspace can still find it again. So, the idrremove() call moves to ppsunregistercdev(), and ppsidr now holds a reference to pps->dev.

pps_core: source serial1 got cdev (251:1)
<...>
pps pps1: removed
pps_core: unregistering pps1
pps_core: deallocating pps1(CVE-2024-57979)

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

Bluetooth: MGMT: Fix possible UAFs

This attemps to fix possible UAFs caused by struct mgmtpending being freed while still being processed like in the following trace, in order to fix mgmtpendingvalid is introduce and use to check if the mgmtpending hasn't been removed from the pending list, on the complete callbacks it is used to check and in addtion remove the cmd from the list while holding mgmtpendinglock to avoid TOCTOU problems since if the cmd is left on the list it can still be accessed and freed.

BUG: KASAN: slab-use-after-free in mgmtaddadvpatternsmonitor_sync+0x35/0x50 net/bluetooth/mgmt.c:5223 Read of size 8 at addr ffff8880709d4dc0 by task kworker/u11:0/55

CPU: 0 UID: 0 PID: 55 Comm: kworker/u11:0 Not tainted 6.16.4 #2 PREEMPT(full) Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.10.2-1ubuntu1 04/01/2014 Workqueue: hci0 hcicmdsyncwork Call Trace: <TASK> dumpstacklvl+0x189/0x250 lib/dumpstack.c:120 printaddressdescription mm/kasan/report.c:378 [inline] printreport+0xca/0x240 mm/kasan/report.c:482 kasanreport+0x118/0x150 mm/kasan/report.c:595 mgmtaddadvpatternsmonitorsync+0x35/0x50 net/bluetooth/mgmt.c:5223 hcicmdsyncwork+0x210/0x3a0 net/bluetooth/hcisync.c:332 processonework kernel/workqueue.c:3238 [inline] processscheduledworks+0xade/0x17b0 kernel/workqueue.c:3321 workerthread+0x8a0/0xda0 kernel/workqueue.c:3402 kthread+0x711/0x8a0 kernel/kthread.c:464 retfromfork+0x3fc/0x770 arch/x86/kernel/process.c:148 retfromforkasm+0x1a/0x30 home/kwqcheii/source/fuzzing/kernel/kasan/linux-6.16.4/arch/x86/entry/entry64.S:245 </TASK>

Allocated by task 12210: kasansavestack mm/kasan/common.c:47 [inline] kasansavetrack+0x3e/0x80 mm/kasan/common.c:68 poisonkmallocredzone mm/kasan/common.c:377 [inline] __kasankmalloc+0x93/0xb0 mm/kasan/common.c:394 kasankmalloc include/linux/kasan.h:260 [inline] __kmalloccachenoprof+0x230/0x3d0 mm/slub.c:4364 kmallocnoprof include/linux/slab.h:905 [inline] kzallocnoprof include/linux/slab.h:1039 [inline] mgmtpendingnew+0x65/0x1e0 net/bluetooth/mgmtutil.c:269 mgmtpendingadd+0x35/0x140 net/bluetooth/mgmtutil.c:296 __addadvpatternsmonitor+0x130/0x200 net/bluetooth/mgmt.c:5247 addadvpatternsmonitor+0x214/0x360 net/bluetooth/mgmt.c:5364 hcimgmtcmd+0x9c9/0xef0 net/bluetooth/hcisock.c:1719 hcisocksendmsg+0x6ca/0xef0 net/bluetooth/hcisock.c:1839 socksendmsgnosec net/socket.c:714 [inline] __socksendmsg+0x219/0x270 net/socket.c:729 sockwriteiter+0x258/0x330 net/socket.c:1133 newsyncwrite fs/readwrite.c:593 [inline] vfswrite+0x5c9/0xb30 fs/readwrite.c:686 ksyswrite+0x145/0x250 fs/readwrite.c:738 dosyscallx64 arch/x86/entry/syscall64.c:63 [inline] dosyscall64+0xfa/0x3b0 arch/x86/entry/syscall64.c:94 entrySYSCALL64afterhwframe+0x77/0x7f

Freed by task 12221: kasansavestack mm/kasan/common.c:47 [inline] kasansavetrack+0x3e/0x80 mm/kasan/common.c:68 kasansavefreeinfo+0x46/0x50 mm/kasan/generic.c:576 poisonslab_object mm/kasan/common.c:247 [inline] __kasanslabfree+0x62/0x70 mm/kasan/common.c:264 kasanslabfree include/linux/kasan.h:233 [inline] slabfreehook mm/slub.c:2381 [inline] slabfree mm/slub.c:4648 [inline] kfree+0x18e/0x440 mm/slub.c:4847 mgmtpendingfree net/bluetooth/mgmtutil.c:311 [inline] mgmtpendingforeach+0x30d/0x380 net/bluetooth/mgmt_util.c:257 __mgmtpoweroff+0x169/0x350 net/bluetooth/mgmt.c:9444 hcidevclosesync+0x754/0x1330 net/bluetooth/hcisync.c:5290 hcidevdoclose net/bluetooth/hcicore.c:501 [inline] hcidevclose+0x108/0x200 net/bluetooth/hcicore.c:526 sockdoioctl+0xd9/0x300 net/socket.c:1192 sockioctl+0x576/0x790 net/socket.c:1313 vfs_ioctl fs/ioctl.c:51 [inline] __dosysioctl fs/ioctl.c:907 [inline] _sesysioctl+0xf9/0x170 fs/ioctl.c:893 dosyscallx64 arch/x86/entry/syscall64.c:63 [inline] dosyscall64+0xf ---truncated---(CVE-2025-39981)

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

dmaengine: xilinx: xdma: Fix regmap max_register

The max_register field is assigned the size of the register memory region instead of the offset of the last register. The result is that reading from the regmap via debugfs can cause a segmentation fault:

tail /sys/kernel/debug/regmap/xdma.1.auto/registers Unable to handle kernel paging request at virtual address ffff800082f70000 Mem abort info: ESR = 0x0000000096000007 EC = 0x25: DABT (current EL), IL = 32 bits SET = 0, FnV = 0 EA = 0, S1PTW = 0 FSC = 0x07: level 3 translation fault [...] Call trace: regmapmmioread32le+0x10/0x30 regmapbusregread+0x74/0xc0 regmapread+0x68/0x198 regmapread+0x54/0x88 regmapreaddebugfs+0x140/0x380 regmapmapreadfile+0x30/0x48 fullproxyread+0x68/0xc8 vfsread+0xcc/0x310 ksysread+0x7c/0x120 __arm64sysread+0x24/0x40 invokesyscall.constprop.0+0x64/0x108 doel0svc+0xb0/0xd8 el0svc+0x38/0x130 el0t64synchandler+0x120/0x138 el0t64sync+0x194/0x198 Code: aa1e03e9 d503201f f9400000 8b214000 (b9400000) ---[ end trace 0000000000000000 ]--- note: tail[1217] exited with irqs disabled note: tail[1217] exited with preemptcount 1 Segmentation fault(CVE-2025-71195)

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

smb/server: fix refcount leak in parsedurablehandle_context()

When the command is a replay operation and -ENOEXEC is returned, the refcount of ksmbd_file must be released.(CVE-2025-71204)

In the Linux kernel, a vulnerability has been identified involving the fix for hugetlbpmdshared() function. The vulnerability prevents proper detection of shared PMD tables because sharing/unsharing operations no longer affect the refcount of a PMD table. This allows page migration functions like mbind() or migratepages() to incorrectly permit migration of folios mapped into such shared PMD tables, even though the folios are not exclusive. In smaps, these folios would be incorrectly accounted as "private" instead of "shared", and PMMMAP_EXCLUSIVE would be wrongly set in the pagemap interface.(CVE-2026-23100)

A race condition vulnerability exists in the LED subsystem (led-class) of the Linux kernel. The root cause is that an LED device is added to the global LED list (leds_list) prematurely, before it is fully initialized. Specifically, in the led_classdev_register() function, the LED device is added to leds_list before the call to led_init_core(), which performs core initialization including setting up the set_brightness_work workqueue. This leaves a time window during which if the LED's default trigger (e.g., provided by snd_ctl_led.ko) registers asynchronously (led_trigger_register), it may trigger a led_set_brightness() call, which in turn attempts to queue work on the uninitialized set_brightness_work workqueue. This race condition is hit by the EC driver on specific hardware (like Lenovo ThinkPad T14s) when registering multiple LEDs in quick succession, causing the kernel to issue a warning (WARNING) and potentially leading to system instability.(CVE-2026-23101)

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

iouring/io-wq: check IOWQBITEXIT inside work run loop

Currently this is checked before running the pending work. Normally this is quite fine, as work items either end up blocking (which will create a new worker for other items), or they complete fairly quickly. But syzbot reports an issue where io-wq takes seemingly forever to exit, and with a bit of debugging, this turns out to be because it queues a bunch of big (2GB - 4096b) reads with a /dev/msr* file. Since this file type doesn't support ->readiter(), looprw_iter() ends up handling them. Each read returns 16MB of data read, which takes 20 (!!) seconds. With a bunch of these pending, processing the whole chain can take a long time. Easily longer than the syzbot uninterruptible sleep timeout of 140 seconds. This then triggers a complaint off the io-wq exit path:

INFO: task syz.4.135:6326 blocked for more than 143 seconds. Not tainted syzkaller #0 Blocked by coredump. "echo 0 > /proc/sys/kernel/hungtasktimeoutsecs" disables this message. task:syz.4.135 state:D stack:26824 pid:6326 tgid:6324 ppid:5957 taskflags:0x400548 flags:0x00080000 Call Trace: <TASK> context_switch kernel/sched/core.c:5256 [inline] __schedule+0x1139/0x6150 kernel/sched/core.c:6863 __scheduleloop kernel/sched/core.c:6945 [inline] schedule+0xe7/0x3a0 kernel/sched/core.c:6960 scheduletimeout+0x257/0x290 kernel/time/sleeptimeout.c:75 dowaitforcommon kernel/sched/completion.c:100 [inline] __waitforcommon+0x2fc/0x4e0 kernel/sched/completion.c:121 iowqexitworkers iouring/io-wq.c:1328 [inline] iowqputandexit+0x271/0x8a0 iouring/io-wq.c:1356 iouringcleantctx+0x10d/0x190 iouring/tctx.c:203 iouringcancelgeneric+0x69c/0x9a0 iouring/cancel.c:651 iouringfilescancel include/linux/iouring.h:19 [inline] doexit+0x2ce/0x2bd0 kernel/exit.c:911 dogroupexit+0xd3/0x2a0 kernel/exit.c:1112 getsignal+0x2671/0x26d0 kernel/signal.c:3034 archdosignalor_restart+0x8f/0x7e0 arch/x86/kernel/signal.c:337 __exittousermodeloop kernel/entry/common.c:41 [inline] exittousermodeloop+0x8c/0x540 kernel/entry/common.c:75 __exittousermodeprepare include/linux/irq-entry-common.h:226 [inline] syscallexittousermodeprepare include/linux/irq-entry-common.h:256 [inline] syscallexittousermodework include/linux/entry-common.h:159 [inline] syscallexittousermode include/linux/entry-common.h:194 [inline] dosyscall64+0x4ee/0xf80 arch/x86/entry/syscall64.c:100 entrySYSCALL64afterhwframe+0x77/0x7f RIP: 0033:0x7fa02738f749 RSP: 002b:00007fa0281ae0e8 EFLAGS: 00000246 ORIGRAX: 00000000000000ca RAX: fffffffffffffe00 RBX: 00007fa0275e6098 RCX: 00007fa02738f749 RDX: 0000000000000000 RSI: 0000000000000080 RDI: 00007fa0275e6098 RBP: 00007fa0275e6090 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000 R13: 00007fa0275e6128 R14: 00007fff14e4fcb0 R15: 00007fff14e4fd98

There's really nothing wrong here, outside of processing these reads will take a LONG time. However, we can speed up the exit by checking the IOWQBITEXIT inside the ioworkerhandlework() loop, as syzbot will exit the ring after queueing up all of these reads. Then once the first item is processed, io-wq will simply cancel the rest. That should avoid syzbot running into this complaint again.(CVE-2026-23113)

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

bonding: provide a net pointer to __skbflowdissect()

After 3cbf4ffba5ee ("net: plumb network namespace into __skbflowdissect") we have to provide a net pointer to __skbflowdissect(), either via skb->dev, skb->sk, or a user provided pointer.

In the following case, syzbot was able to cook a bare skb.

WARNING: net/core/flow_dissector.c:1131 at __skbflowdissect+0xb57/0x68b0 net/core/flowdissector.c:1131, CPU#1: syz.2.1418/11053 Call Trace: <TASK> bondflowdissect drivers/net/bonding/bondmain.c:4093 [inline] __bondxmithash+0x2d7/0xba0 drivers/net/bonding/bond_main.c:4157 bondxmithashxdp drivers/net/bonding/bondmain.c:4208 [inline] bondxdpxmit3adxorslaveget drivers/net/bonding/bondmain.c:5139 [inline] bondxdpgetxmitslave+0x1fd/0x710 drivers/net/bonding/bondmain.c:5515 xdpmasterredirect+0x13f/0x2c0 net/core/filter.c:4388 bpfprogrunxdp include/net/xdp.h:700 [inline] bpftestrun+0x6b2/0x7d0 net/bpf/testrun.c:421 bpfprogtestrunxdp+0x795/0x10e0 net/bpf/testrun.c:1390 bpfprogtestrun+0x2c7/0x340 kernel/bpf/syscall.c:4703 __sys_bpf+0x562/0x860 kernel/bpf/syscall.c:6182 __dosysbpf kernel/bpf/syscall.c:6274 [inline] __sesysbpf kernel/bpf/syscall.c:6272 [inline] __x64sysbpf+0x7c/0x90 kernel/bpf/syscall.c:6272 dosyscallx64 arch/x86/entry/syscall64.c:63 [inline] dosyscall64+0xec/0xf80 arch/x86/entry/syscall64.c:94(CVE-2026-23119)

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

sctp: move SCTPCMDASSOCSHKEY right after SCTPCMDPEERINIT

A null-ptr-deref was reported in the SCTP transmit path when SCTP-AUTH key initialization fails:

================================================================== KASAN: null-ptr-deref in range [0x0000000000000018-0x000000000000001f] CPU: 0 PID: 16 Comm: ksoftirqd/0 Tainted: G W 6.6.0 #2 RIP: 0010:sctppacketbundleauth net/sctp/output.c:264 [inline] RIP: 0010:sctppacketappendchunk+0xb36/0x1260 net/sctp/output.c:401 Call Trace:

sctppackettransmitchunk+0x31/0x250 net/sctp/output.c:189 sctpoutqflushdata+0xa29/0x26d0 net/sctp/outqueue.c:1111 sctpoutqflush+0xc80/0x1240 net/sctp/outqueue.c:1217 sctpcmdinterpreter.isra.0+0x19a5/0x62c0 net/sctp/smsideeffect.c:1787 sctpsideeffects net/sctp/smsideeffect.c:1198 [inline] sctpdosm+0x1a3/0x670 net/sctp/smsideeffect.c:1169 sctpassocbhrcv+0x33e/0x640 net/sctp/associola.c:1052 sctpinqpush+0x1dd/0x280 net/sctp/inqueue.c:88 sctprcv+0x11ae/0x3100 net/sctp/input.c:243 sctp6rcv+0x3d/0x60 net/sctp/ipv6.c:1127

The issue is triggered when sctpauthasocinitactivekey() fails in sctpsfdo51Cack() while processing an INIT_ACK. In this case, the command sequence is currently:

• SCTPCMDPEER_INIT
• SCTPCMDTIMERSTOP (T1INIT)
• SCTPCMDTIMERSTART (T1COOKIE)
• SCTPCMDNEWSTATE (COOKIEECHOED)
• SCTPCMDASSOC_SHKEY
• SCTPCMDGENCOOKIEECHO

If SCTPCMDASSOCSHKEY fails, asoc->shkey remains NULL, while asoc->peer.authcapable and asoc->peer.peerchunks have already been set by SCTPCMDPEERINIT. This allows a DATA chunk with auth = 1 and shkey = NULL to be queued by sctpdatamsgfrom_user().

Since command interpretation stops on failure, no COOKIEECHO should been sent via SCTPCMDGENCOOKIEECHO. However, the T1COOKIE timer has already been started, and it may enqueue a COOKIEECHO into the outqueue later. As a result, the DATA chunk can be transmitted together with the COOKIEECHO in sctpoutqflush_data(), leading to the observed issue.

Similar to the other places where it calls sctpauthasocinitactivekey() right after sctpprocessinit(), this patch moves the SCTPCMDASSOCSHKEY immediately after SCTPCMDPEERINIT, before stopping T1INIT and starting T1COOKIE. This ensures that if shared key generation fails, authenticated DATA cannot be sent. It also allows the T1INIT timer to retransmit INIT, giving the client another chance to process INIT_ACK and retry key setup.(CVE-2026-23125)

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

arm64: Set __nocfi on swsusparchresume()

A DABT is reported[1] on an android based system when resume from hiberate. This happens because swsusparchsuspendexit() is marked with SYMCODE_*() and does not have a CFI hash, but swsusparchresume() will attempt to verify the CFI hash when calling a copy of swsusparchsuspend_exit().

Given that there's an existing requirement that the entrypoint to swsusparchsuspendexit() is the first byte of the .hibernateexit.text section, we cannot fix this by marking swsusparchsuspendexit() with SYMFUNC_*(). The simplest fix for now is to disable the CFI check in swsusparchresume().

Mark swsusparchresume() as __nocfi to disable the CFI check.

[1] [ 22.991934][ T1] Unable to handle kernel paging request at virtual address 0000000109170ffc [ 22.991934][ T1] Mem abort info: [ 22.991934][ T1] ESR = 0x0000000096000007 [ 22.991934][ T1] EC = 0x25: DABT (current EL), IL = 32 bits [ 22.991934][ T1] SET = 0, FnV = 0 [ 22.991934][ T1] EA = 0, S1PTW = 0 [ 22.991934][ T1] FSC = 0x07: level 3 translation fault [ 22.991934][ T1] Data abort info: [ 22.991934][ T1] ISV = 0, ISS = 0x00000007, ISS2 = 0x00000000 [ 22.991934][ T1] CM = 0, WnR = 0, TnD = 0, TagAccess = 0 [ 22.991934][ T1] GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0 [ 22.991934][ T1] [0000000109170ffc] user address but activemm is swapper [ 22.991934][ T1] Internal error: Oops: 0000000096000007 [#1] PREEMPT SMP [ 22.991934][ T1] Dumping ftrace buffer: [ 22.991934][ T1] (ftrace buffer empty) [ 22.991934][ T1] Modules linked in: [ 22.991934][ T1] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 6.6.98-android15-8-g0b1d2aee7fc3-dirty-4k #1 688c7060a825a3ac418fe53881730b355915a419 [ 22.991934][ T1] Hardware name: Unisoc UMS9360-base Board (DT) [ 22.991934][ T1] pstate: 804000c5 (Nzcv daIF +PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 22.991934][ T1] pc : swsusparchresume+0x2ac/0x344 [ 22.991934][ T1] lr : swsusparchresume+0x294/0x344 [ 22.991934][ T1] sp : ffffffc08006b960 [ 22.991934][ T1] x29: ffffffc08006b9c0 x28: 0000000000000000 x27: 0000000000000000 [ 22.991934][ T1] x26: 0000000000000000 x25: 0000000000000000 x24: 0000000000000820 [ 22.991934][ T1] x23: ffffffd0817e3000 x22: ffffffd0817e3000 x21: 0000000000000000 [ 22.991934][ T1] x20: ffffff8089171000 x19: ffffffd08252c8c8 x18: ffffffc080061058 [ 22.991934][ T1] x17: 00000000529c6ef0 x16: 00000000529c6ef0 x15: 0000000000000004 [ 22.991934][ T1] x14: ffffff8178c88000 x13: 0000000000000006 x12: 0000000000000000 [ 22.991934][ T1] x11: 0000000000000015 x10: 0000000000000001 x9 : ffffffd082533000 [ 22.991934][ T1] x8 : 0000000109171000 x7 : 205b5d3433393139 x6 : 392e32322020205b [ 22.991934][ T1] x5 : 000000010916f000 x4 : 000000008164b000 x3 : ffffff808a4e0530 [ 22.991934][ T1] x2 : ffffffd08058e784 x1 : 0000000082326000 x0 : 000000010a283000 [ 22.991934][ T1] Call trace: [ 22.991934][ T1] swsusparchresume+0x2ac/0x344 [ 22.991934][ T1] hibernationrestore+0x158/0x18c [ 22.991934][ T1] loadimageandrestore+0xb0/0xec [ 22.991934][ T1] softwareresume+0xf4/0x19c [ 22.991934][ T1] softwareresumeinitcall+0x34/0x78 [ 22.991934][ T1] dooneinitcall+0xe8/0x370 [ 22.991934][ T1] doinitcalllevel+0xc8/0x19c [ 22.991934][ T1] doinitcalls+0x70/0xc0 [ 22.991934][ T1] dobasicsetup+0x1c/0x28 [ 22.991934][ T1] kernelinitfreeable+0xe0/0x148 [ 22.991934][ T1] kernelinit+0x20/0x1a8 [ 22.991934][ T1] retfromfork+0x10/0x20 [ 22.991934][ T1] Code: a9400a61 f94013e0 f9438923 f9400a64 (b85fc110)

catalin.marinas@arm.com: commit log updated by Mark Rutland

In the Linux kernel, the following vulnerability has been resolved: bpf, testrun: Subtract size of xdpframe from allowed metadata size The xdpframe structure takes up part of the XDP frame headroom, limiting the size of the metadata. However, in bpftestrun, we don't take this into account, which makes it possible for userspace to supply a metadata size that is too large (taking up the entire headroom). If userspace supplies such a large metadata size in live packet mode, the xdpupdateframefrombuff() call in xdptestruninitpage() call will fail, after which packet transmission proceeds with an uninitialised frame structure, leading to the usual Bad Stuff. The commit in the Fixes tag fixed a related bug where the second check in xdpupdateframefrom_buff() could fail, but did not add any additional constraints on the metadata size. Complete the fix by adding an additional check on the metadata size. Reorder the checks slightly to make the logic clearer and add a comment. The Linux kernel CVE team has assigned CVE-2026-23140 to this issue.(CVE-2026-23140)

In the Linux kernel, there is a vulnerability in the shmem (shared memory) subsystem. When truncating a large swap entry, if the index points to the middle of a large swap entry and the entry doesn't cross the end boundary, it causes an infinite loop condition. An attacker could potentially exploit this vulnerability to cause denial of service.(CVE-2026-23177)

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

ceph: fix oops due to invalid pointer for kfree() in parse_longname()

This fixes a kernel oops when reading ceph snapshot directories (.snap), for example by simply running ls /mnt/my_ceph/.snap.

The variable str is guarded by _free(kfree), but advanced by one for skipping the initial '' in snapshot names. Thus, kfree() is called with an invalid pointer. This patch removes the need for advancing the pointer so kfree() is called with correct memory pointer.

Steps to reproduce:

1. Create snapshots on a cephfs volume (I've 63 snaps in my testcase)

2. Add cephfs mount to fstab $ echo "(CVE-2026-23201)

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

macvlan: fix error recovery in macvlancommonnewlink()

valis provided a nice repro to crash the kernel:

ip link add p1 type veth peer p2 ip link set address 00:00:00:00:00:20 dev p1 ip link set up dev p1 ip link set up dev p2

ip link add mv0 link p2 type macvlan mode source ip link add invalid% link p2 type macvlan mode source macaddr add 00:00:00:00:00:20

ping -c1 -I p1 1.2.3.4

He also gave a very detailed analysis:

<quote valis>

The issue is triggered when a new macvlan link is created with MACVLANMODESOURCE mode and MACVLANMACADDRADD (or MACVLANMACADDRSET) parameter, lower device already has a macvlan port and registernetdevice() called from macvlancommon_newlink() fails (e.g. because of the invalid link name).

In this case macvlanhashaddsource is called from macvlanchangesources() / macvlancommon_newlink():

This adds a reference to vlan to the port's vlansourcehash using macvlansourceentry.

vlan is a pointer to the priv data of the link that is being created.

When registernetdevice() fails, the error is returned from macvlannewlink() to rtnlnewlinkcreate():

    if (ops->newlink)
            err = ops->newlink(dev, &params, extack);
    else
            err = register_netdevice(dev);
    if (err < 0) {
            free_netdev(dev);
            goto out;
    }

and freenetdev() is called, causing a kvfree() on the struct netdevice that is still referenced in the source entry attached to the lower device's macvlan port.

Now all packets sent on the macvlan port with a matching source mac address will trigger a use-after-free in macvlanforwardsource().

</quote valis>

With all that, my fix is to make sure we call macvlanflushsources() regardless of @create value whenever "goto destroymacvlanport;" path is taken.

Many thanks to valis for following up on this issue.(CVE-2026-23209)

In the Linux kernel, the following vulnerability has been resolved: ksmbd: add channlock to protect ksmbdchannlist xarray ksmbdchannlist xarray lacks synchronization, allowing use-after-free in multi-channel sessions (between lookupchannlist() and ksmbdchanndel). Adds rwsemaphore channlock to struct ksmbdsession and protects all xaload/xastore/xa_erase accesses. The Linux kernel CVE team has assigned CVE-2026-23226 to this issue.(CVE-2026-23226)

In the Linux kernel, the following vulnerability has been resolved: crypto: virtio - Add spinlock protection with virtqueue notification When VM boots with one virtio-crypto PCI device and builtin backend, run openssl benchmark command with multiple processes, such as openssl speed -evp aes-128-cbc -engine afalg -seconds 10 -multi 32 openssl processes will hangup and there is error reported like this: virtiocrypto virtio0: dataq.0:id 3 is not a head! It seems that the data virtqueue need protection when it is handled for virtio done notification. If the spinlock protection is added in virtcryptodone_task(), openssl benchmark with multiple processes works well. The Linux kernel CVE team has assigned CVE-2026-23229 to this issue.(CVE-2026-23229)

In the Linux kernel, a NULL pointer dereference vulnerability exists in the Classmate laptop driver. The vulnerability occurs in platform/x86/classmate-laptop driver where code using the accel object may run before that object's address is stored in the driver data of the input device. Specifically, sysfs attributes may be accessed before initializing the device, causing devgetdrvdata() calls to return NULL and leading to NULL pointer dereference.(CVE-2026-23237)