OESA-2026-1950

The Linux Kernel, the operating system core itself.

Security Fix(es):

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

btrfs: fix extent map use-after-free when handling missing device in readonechunk

Store the error code before freeing the extent_map. Though it's reference counted structure, in that function it's the first and last allocation so this would lead to a potential use-after-free.

The error can happen eg. when chunk is stored on a missing device and the degraded mount option is missing.

Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=216721(CVE-2022-50300)

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

parisc: Fix locking in pdciodcprint() firmware call

Utilize pdclock spinlock to protect parallel modifications of the iodcdbuf[] buffer, check length to prevent buffer overflow of iodcdbuf[], drop the iodcretbuf[] buffer and fix some wrong indentings.(CVE-2022-50518)

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

fs/ntfs3: Add length check in indxgetroot

This adds a length check to guarantee the retrieved index root is legit.

[ 162.459513] BUG: KASAN: use-after-free in hdrfinde.isra.0+0x10c/0x320 [ 162.460176] Read of size 2 at addr ffff8880037bca99 by task mount/243 [ 162.460851] [ 162.461252] CPU: 0 PID: 243 Comm: mount Not tainted 6.0.0-rc7 #42 [ 162.461744] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.14.0-0-g155821a1990b-prebuilt.qemu.org 04/01/2014 [ 162.462609] Call Trace: [ 162.462954] <TASK> [ 162.463276] dumpstacklvl+0x49/0x63 [ 162.463822] printreport.cold+0xf5/0x689 [ 162.464608] ? unwindgetreturnaddress+0x3a/0x60 [ 162.465766] ? hdrfinde.isra.0+0x10c/0x320 [ 162.466975] kasanreport+0xa7/0x130 [ 162.467506] ? rawspinlockirq+0xc0/0xf0 [ 162.467998] ? hdrfind_e.isra.0+0x10c/0x320 [ 162.468536] __asanload2+0x68/0x90 [ 162.468923] hdrfinde.isra.0+0x10c/0x320 [ 162.469282] ? cmpuints+0xe0/0xe0 [ 162.469557] ? cmpsdh+0x90/0x90 [ 162.469864] ? nifindattr+0x214/0x300 [ 162.470217] ? niloadmi+0x80/0x80 [ 162.470479] ? entrySYSCALL64afterhwframe+0x63/0xcd [ 162.470931] ? ntfsbreadrun+0x190/0x190 [ 162.471307] ? indxgetroot+0xe4/0x190 [ 162.471556] ? indxgetroot+0x140/0x190 [ 162.471833] ? indxinit+0x1e0/0x1e0 [ 162.472069] ? fndclear+0x115/0x140 [ 162.472363] ? rawspinlockirqsave+0x100/0x100 [ 162.472731] indxfind+0x184/0x470 [ 162.473461] ? sysvecapictimerinterrupt+0x57/0xc0 [ 162.474429] ? indxfindbuffer+0x2d0/0x2d0 [ 162.474704] ? dosyscall64+0x3b/0x90 [ 162.474962] dirsearchu+0x196/0x2f0 [ 162.475381] ? ntfsnlstoutf16+0x450/0x450 [ 162.475661] ? ntfssecurityinit+0x3d6/0x440 [ 162.475906] ? issdvalid+0x180/0x180 [ 162.476191] ntfsextendinit+0x13f/0x2c0 [ 162.476496] ? ntfsfixpostread+0x130/0x130 [ 162.476861] ? iput.part.0+0x286/0x320 [ 162.477325] ntfsfillsuper+0x11e0/0x1b50 [ 162.477709] ? putntfs+0x1d0/0x1d0 [ 162.477970] ? vsprintf+0x20/0x20 [ 162.478258] ? setblocksize+0x95/0x150 [ 162.478538] gettreebdev+0x232/0x370 [ 162.478789] ? putntfs+0x1d0/0x1d0 [ 162.479038] ntfsfsgettree+0x15/0x20 [ 162.479374] vfsgettree+0x4c/0x130 [ 162.479729] pathmount+0x654/0xfe0 [ 162.480124] ? putname+0x80/0xa0 [ 162.480484] ? finishautomount+0x2e0/0x2e0 [ 162.480894] ? putname+0x80/0xa0 [ 162.481467] ? kmemcachefree+0x1c4/0x440 [ 162.482280] ? putname+0x80/0xa0 [ 162.482714] domount+0xd6/0xf0 [ 162.483264] ? path_mount+0xfe0/0xfe0 [ 162.484782] ? __kasancheckwrite+0x14/0x20 [ 162.485593] _x64sysmount+0xca/0x110 [ 162.486024] dosyscall64+0x3b/0x90 [ 162.486543] entrySYSCALL64afterhwframe+0x63/0xcd [ 162.487141] RIP: 0033:0x7f9d374e948a [ 162.488324] Code: 48 8b 0d 11 fa 2a 00 f7 d8 64 89 01 48 83 c8 ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 49 89 ca b8 a5 00 00 008 [ 162.489728] RSP: 002b:00007ffe30e73d18 EFLAGS: 00000206 ORIGRAX: 00000000000000a5 [ 162.490971] RAX: ffffffffffffffda RBX: 0000561cdb43a060 RCX: 00007f9d374e948a [ 162.491669] RDX: 0000561cdb43a260 RSI: 0000561cdb43a2e0 RDI: 0000561cdb442af0 [ 162.492050] RBP: 0000000000000000 R08: 0000561cdb43a280 R09: 0000000000000020 [ 162.492459] R10: 00000000c0ed0000 R11: 0000000000000206 R12: 0000561cdb442af0 [ 162.493183] R13: 0000561cdb43a260 R14: 0000000000000000 R15: 00000000ffffffff [ 162.493644] </TASK> [ 162.493908] [ 162.494214] The buggy address belongs to the physical page: [ 162.494761] page:000000003e38a3d5 refcount:0 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x37bc [ 162.496064] flags: 0xfffffc0000000(node=0|zone=1|lastcpupid=0x1fffff) [ 162.497278] raw: 000fffffc0000000 ffffea00000df1c8 ffffea00000df008 0000000000000000 [ 162.498928] raw: 0000000000000000 0000000000240000 00000000ffffffff 0000000000000000 [ 162.500542] page dumped becau ---truncated---(CVE-2023-53194)

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

rpl: Fix use-after-free in rpldosrh_inline().

Running lwtdstcacherefloop.sh in selftest with KASAN triggers the splat below [0].

rpldosrhinline() fetches ipv6hdr(skb) and accesses it after skbcowhead(), which is illegal as the header could be freed then.

Let's fix it by making oldhdr to a local struct instead of a pointer.

... TEST: rpl (input) [ 57.631529] ================================================================== BUG: KASAN: slab-use-after-free in rpldosrhinline.isra.0 (net/ipv6/rpliptunnel.c:174) Read of size 40 at addr ffff888122bf96d8 by task ping6/1543

CPU: 50 UID: 0 PID: 1543 Comm: ping6 Not tainted 6.16.0-rc5-01302-gfadd1e6231b1 #23 PREEMPT(voluntary) Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 Call Trace: <IRQ> dumpstacklvl (lib/dumpstack.c:122) printreport (mm/kasan/report.c:409 mm/kasan/report.c:521) kasanreport (mm/kasan/report.c:221 mm/kasan/report.c:636) kasancheck_range (mm/kasan/generic.c:175 (discriminator 1) mm/kasan/generic.c:189 (discriminator 1)) __asanmemmove (mm/kasan/shadow.c:94 (discriminator 2)) rpldosrhinline.isra.0 (net/ipv6/rpliptunnel.c:174) rplinput (net/ipv6/rpliptunnel.c:201 net/ipv6/rpliptunnel.c:282) lwtunnelinput (net/core/lwtunnel.c:459) ipv6rcv (./include/net/dst.h:471 (discriminator 1) ./include/net/dst.h:469 (discriminator 1) net/ipv6/ip6input.c:79 (discriminator 1) ./include/linux/netfilter.h:317 (discriminator 1) ./include/linux/netfilter.h:311 (discriminator 1) net/ipv6/ip6input.c:311 (discriminator 1)) __netifreceiveskb_onecore (net/core/dev.c:5967) processbacklog (./include/linux/rcupdate.h:869 net/core/dev.c:6440) __napipoll.constprop.0 (net/core/dev.c:7452) netrx_action (net/core/dev.c:7518 net/core/dev.c:7643) handlesoftirqs (kernel/softirq.c:579) dosoftirq (kernel/softirq.c:480 (discriminator 20)) </IRQ> <TASK> __localbhenable_ip (kernel/softirq.c:407) __devqueuexmit (net/core/dev.c:4740) ip6_finishoutput2 (./include/linux/netdevice.h:3358 ./include/net/neighbour.h:526 ./include/net/neighbour.h:540 net/ipv6/ip6output.c:141) ip6finishoutput (net/ipv6/ip6output.c:215 net/ipv6/ip6output.c:226) ip6output (./include/linux/netfilter.h:306 net/ipv6/ip6output.c:248) ip6sendskb (net/ipv6/ip6output.c:1983) rawv6sendmsg (net/ipv6/raw.c:588 net/ipv6/raw.c:918) __sys_sendto (net/socket.c:714 (discriminator 1) net/socket.c:729 (discriminator 1) net/socket.c:2228 (discriminator 1)) __x64syssendto (net/socket.c:2231) dosyscall64 (arch/x86/entry/syscall64.c:63 (discriminator 1) arch/x86/entry/syscall64.c:94 (discriminator 1)) entrySYSCALL64afterhwframe (arch/x86/entry/entry64.S:130) RIP: 0033:0x7f68cffb2a06 Code: 5d e8 41 8b 93 08 03 00 00 59 5e 48 83 f8 fc 75 19 83 e2 39 83 fa 08 75 11 e8 26 ff ff ff 66 0f 1f 44 00 00 48 8b 45 10 0f 05 <48> 8b 5d f8 c9 c3 0f 1f 40 00 f3 0f 1e fa 55 48 89 e5 48 83 ec 08 RSP: 002b:00007ffefb7c53d0 EFLAGS: 00000202 ORIGRAX: 000000000000002c RAX: ffffffffffffffda RBX: 0000564cd69f10a0 RCX: 00007f68cffb2a06 RDX: 0000000000000040 RSI: 0000564cd69f10a4 RDI: 0000000000000003 RBP: 00007ffefb7c53f0 R08: 0000564cd6a032ac R09: 000000000000001c R10: 0000000000000000 R11: 0000000000000202 R12: 0000564cd69f10a4 R13: 0000000000000040 R14: 00007ffefb7c66e0 R15: 0000564cd69f10a0 </TASK>

Allocated by task 1543: kasansavestack (mm/kasan/common.c:48) kasansavetrack (mm/kasan/common.c:60 (discriminator 1) mm/kasan/common.c:69 (discriminator 1)) __kasanslaballoc (mm/kasan/common.c:319 mm/kasan/common.c:345) kmem_cacheallocnodenoprof (./include/linux/kasan.h:250 mm/slub.c:4148 mm/slub.c:4197 mm/slub.c:4249) kmallocreserve (net/core/skbuff.c:581 (discriminator 88)) __alloc_skb (net/core/skbuff.c:669) __ip6appenddata (net/ipv6/ip6output.c:1672 (discriminator 1)) ip6 ---truncated---(CVE-2025-38476)

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

ARM: tegra: Use I/O memcpy to write to IRAM

Kasan crashes the kernel trying to check boundaries when using the normal memcpy.(CVE-2025-39794)

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

btrfs: avoid potential out-of-bounds in btrfsencodefh()

The function btrfsencodefh() does not properly account for the three cases it handles.

Before writing to the file handle (fh), the function only returns to the user BTRFSFIDSIZENONCONNECTABLE (5 dwords, 20 bytes) or BTRFSFIDSIZE_CONNECTABLE (8 dwords, 32 bytes).

However, when a parent exists and the root ID of the parent and the inode are different, the function writes BTRFSFIDSIZECONNECTABLEROOT (10 dwords, 40 bytes).

If *maxlen is not large enough, this write goes out of bounds because BTRFSFIDSIZECONNECTABLEROOT is greater than BTRFSFIDSIZECONNECTABLE originally returned.

This results in an 8-byte out-of-bounds write at fid->parentrootobjectid = parentrootid.

A previous attempt to fix this issue was made but was lost.

https://lore.kernel.org/all/(CVE-2025-40205)

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

media: dvb-core: fix wrong reinitialization of ringbuffer on reopen

dvbdvropen() calls dvbringbufferinit() when a new reader opens the DVR device. dvbringbufferinit() calls initwaitqueuehead(), which reinitializes the waitqueue list head to empty.

Since dmxdev->dvrbuffer.queue is a shared waitqueue (all opens of the same DVR device share it), this orphans any existing waitqueue entries from iouring poll or epoll, leaving them with stale prev/next pointers while the list head is reset to {self, self}.

The waitqueue and spinlock in dvrbuffer are already properly initialized once in dvbdmxdev_init(). The open path only needs to reset the buffer data pointer, size, and read/write positions.

Replace the dvbringbufferinit() call in dvbdvropen() with direct assignment of data/size and a call to dvbringbufferreset(), which properly resets pread, pwrite, and error with correct memory ordering without touching the waitqueue or spinlock.(CVE-2026-23253)

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

apparmor: validate DFA start states are in bounds in unpack_pdb

Start states are read from untrusted data and used as indexes into the DFA state tables. The aadfanext() function call in unpackpdb() will access dfa->tables[YYTDID_BASE][start], and if the start state exceeds the number of states in the DFA, this results in an out-of-bound read.

================================================================== BUG: KASAN: slab-out-of-bounds in aadfanext+0x2a1/0x360 Read of size 4 at addr ffff88811956fb90 by task su/1097 ...

Reject policies with out-of-bounds start states during unpacking to prevent the issue.(CVE-2026-23269)

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

ice: Fix memory leak in icesetringparam()

In icesetringparam, txrings and xdprings are allocated before rxrings. If the allocation of rxrings fails, the code jumps to the done label leaking both txrings and xdprings. Furthermore, if the setup of an individual Rx ring fails during the loop, the code jumps to the freetx label which releases txrings but leaks xdp_rings.

Fix this by introducing a freexdp label and updating the error paths to ensure both xdprings and txrings are properly freed if rxrings allocation or setup fails.

Compile tested only. Issue found using a prototype static analysis tool and code review.(CVE-2026-23389)

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

apparmor: replace recursive profile removal with iterative approach

The profile removal code uses recursion when removing nested profiles, which can lead to kernel stack exhaustion and system crashes.

Reproducer: $ pf='a'; for ((i=0; i<1024; i++)); do echo -e "profile $pf { \n }" | apparmor_parser -K -a; pf="$pf//x"; done $ echo -n a > /sys/kernel/security/apparmor/.remove

Replace the recursive __aaprofilelist_release() approach with an iterative approach in _removeprofile(). The function repeatedly finds and removes leaf profiles until the entire subtree is removed, maintaining the same removal semantic without recursion.(CVE-2026-23404)

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

apparmor: fix: limit the number of levels of policy namespaces

Currently the number of policy namespaces is not bounded relying on the user namespace limit. However policy namespaces aren't strictly tied to user namespaces and it is possible to create them and nest them arbitrarily deep which can be used to exhaust system resource.

Hard cap policy namespaces to the same depth as user namespaces.(CVE-2026-23405)

A vulnerability exists in the AppArmor security module of the Linux kernel, stemming from a side-effect bug in the usage of the match_char macro. This macro evaluates its character parameter multiple times when traversing differential encoding chains. When invoked with *str++, the string pointer advances on each iteration of the inner do-while loop, causing the Deterministic Finite Automaton (DFA) to check different characters at each iteration and therefore skip input characters. This results in out-of-bounds reads when the pointer advances past the input buffer boundary. This vulnerability may impact the confidentiality of the kernel.(CVE-2026-23406)

An out-of-bounds read and write vulnerability exists in the AppArmor security module of the Linux kernel. In the verifydfa() function, while traversing the differential encoding chain, it reads k = DEFAULT_TABLE[j] and uses k as an array index without validating whether k is within the bounds of the valid state count (statecount). If an attacker can supply a malicious Deterministic Finite Automaton (DFA) with a crafted value where DEFAULT_TABLE[j] >= state_count, it will lead to out-of-bounds reads and writes. This vulnerability may impact the confidentiality and stability of the kernel.(CVE-2026-23407)

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

apparmor: Fix double free of nsname in aareplace_profiles()

if nsname is NULL after 1071 error = aaunpack(udata, &lh, &ns_name);

and if ent->nsname contains an nsname in 1089 } else if (ent->ns_name) {

then nsname is assigned the ent->nsname 1095 nsname = ent->nsname;

however ent->nsname is freed at 1262 aaloadentfree(ent);

and then again when freeing nsname at 1270 kfree(nsname);

Fix this by NULLing out ent->nsname after it is transferred to nsname

")(CVE-2026-23408)

A race condition vulnerability exists in the AppArmor security module of the Linux kernel, leading to a use-after-free issue. This vulnerability can be triggered when an attacker simultaneously opens rawdata files and removes an associated AppArmor profile. Since rawdata inodes are not refcounted, there is a time window during profile removal where the i_private pointer may reference freed memory, causing the system to access freed memory regions. This can result in program crashes, unexpected value usage, or arbitrary code execution, threatening the confidentiality, integrity, and availability of the system.(CVE-2026-23410)

A vulnerability exists in the AppArmor security module of the Linux kernel when handling the iprivate field of the inode structure. AppArmor was putting the reference to iprivate data on its end after removing the original entry from the file system. However the inode can and does live beyond that point and it is possible that some of the fs callback functions will be invoked after the reference has been put, which results in a race between freeing the data and accessing it through the fs. While the rawdata/loaddata is the most likely candidate to fail the race, as it has the fewest references. If properly crafted it might be possible to trigger a race for the other types stored in i_private. This vulnerability could allow a local attacker to bypass AppArmor's access control policies through a specially crafted request, leading to privilege escalation and impacting system confidentiality, integrity, and availability.(CVE-2026-23411)

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

PM: runtime: Fix a race condition related to device removal

The following code in pmruntimework() may dereference the dev->parent pointer after the parent device has been freed:

/* Maybe the parent is now able to suspend. */
if (parent && !parent->power.ignore_children) {
    spin_unlock(&dev->power.lock);

    spin_lock(&parent->power.lock);
    rpm_idle(parent, RPM_ASYNC);
    spin_unlock(&parent->power.lock);

    spin_lock(&dev->power.lock);
}

Fix this by inserting a flushwork() call in pmruntime_remove().

Without this patch blktest block/001 triggers the following complaint sporadically:

BUG: KASAN: slab-use-after-free in lockacquire+0x70/0x160 Read of size 1 at addr ffff88812bef7198 by task kworker/u553:1/3081 Workqueue: pm pmruntimework Call Trace: <TASK> dumpstacklvl+0x61/0x80 printaddressdescription.constprop.0+0x8b/0x310 printreport+0xfd/0x1d7 kasan_report+0xd8/0x1d0 _kasancheckbyte+0x42/0x60 lockacquire.part.0+0x38/0x230 lockacquire+0x70/0x160 rawspinlock+0x36/0x50 rpmsuspend+0xc6a/0xfe0 rpmidle+0x578/0x770 pmruntimework+0xee/0x120 processonework+0xde3/0x1410 workerthread+0x5eb/0xfe0 kthread+0x37b/0x480 retfromfork+0x6cb/0x920 retfromforkasm+0x11/0x20 </TASK>

Allocated by task 4314: kasansavestack+0x2a/0x50 kasansavetrack+0x18/0x40 kasansavealloc_info+0x3d/0x50 __kasan_kmalloc+0xa0/0xb0 __kmallocnoprof+0x311/0x990 scsialloctarget+0x122/0xb60 [scsimod] __scsiscantarget+0x101/0x460 [scsimod] scsiscan_channel+0x179/0x1c0 [scsimod] scsiscanhostselected+0x259/0x2d0 [scsimod] storescan+0x2d2/0x390 [scsimod] devattrstore+0x43/0x80 sysfskfwrite+0xde/0x140 kernfsfopwriteiter+0x3ef/0x670 vfswrite+0x506/0x1470 ksyswrite+0xfd/0x230 __x64syswrite+0x76/0xc0 x64syscall+0x213/0x1810 dosyscall64+0xee/0xfc0 entrySYSCALL64afterhwframe+0x4b/0x53

Freed by task 4314: kasansavestack+0x2a/0x50 kasansavetrack+0x18/0x40 kasansavefree_info+0x3f/0x50 __kasanslabfree+0x67/0x80 kfree+0x225/0x6c0 scsitargetdevrelease+0x3d/0x60 [scsimod] devicerelease+0xa3/0x220 kobjectcleanup+0x105/0x3a0 kobjectput+0x72/0xd0 putdevice+0x17/0x20 scsidevicedevrelease+0xacf/0x12c0 [scsimod] devicerelease+0xa3/0x220 kobjectcleanup+0x105/0x3a0 kobjectput+0x72/0xd0 putdevice+0x17/0x20 scsideviceput+0x7f/0xc0 [scsimod] sdevstoredelete+0xa5/0x120 [scsimod] devattrstore+0x43/0x80 sysfskfwrite+0xde/0x140 kernfsfopwriteiter+0x3ef/0x670 vfswrite+0x506/0x1470 ksys_write+0xfd/0x230 __x64syswrite+0x76/0xc0 x64syscall+0x213/0x1810(CVE-2026-23452)

In the Linux kernel, the Bluetooth SCO module's scorecvframe() function contains a use-after-free vulnerability. The function reads conn->sk under scoconnlock() but immediately releases the lock without holding a reference to the socket. A concurrent close() operation can free the socket between the lock release and the subsequent sk->skstate access, resulting in a use-after-free vulnerability. Other functions in the same file (scosocktimeout(), scoconndel()) correctly use scosockhold() to safely hold references under the lock. The vulnerability is fixed by using scosockhold() to acquire a reference before releasing the lock and adding sockput() on all exit paths.(CVE-2026-31408)

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

xen/privcmd: restrict usage in unprivileged domU

The Xen privcmd driver allows to issue arbitrary hypercalls from user space processes. This is normally no problem, as access is usually limited to root and the hypervisor will deny any hypercalls affecting other domains.

In case the guest is booted using secure boot, however, the privcmd driver would be enabling a root user process to modify e.g. kernel memory contents, thus breaking the secure boot feature.

The only known case where an unprivileged domU is really needing to use the privcmd driver is the case when it is acting as the device model for another guest. In this case all hypercalls issued via the privcmd driver will target that other guest.

Fortunately the privcmd driver can already be locked down to allow only hypercalls targeting a specific domain, but this mode can be activated from user land only today.

The target domain can be obtained from Xenstore, so when not running in dom0 restrict the privcmd driver to that target domain from the beginning, resolving the potential problem of breaking secure boot.

This is XSA-482

V2: - defer reading from Xenstore if Xenstore isn't ready yet (Jan Beulich) - wait in open() if target domain isn't known yet - issue message in case no target domain found (Jan Beulich)(CVE-2026-31788)