OESA-2026-2673

The Linux Kernel, the operating system core itself.

Security Fix(es):

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

net: hamradio: fix memory leak in mkiss_close

My local syzbot instance hit memory leak in mkissopen()[1]. The problem was in missing freenetdev() in mkiss_close().

In mkissopen() netdevice is allocated and then registered, but in mkissclose() netdevice was only unregistered, but not freed.

Fail log:

BUG: memory leak unreferenced object 0xffff8880281ba000 (size 4096): comm "syz-executor.1", pid 11443, jiffies 4295046091 (age 17.660s) hex dump (first 32 bytes): 61 78 30 00 00 00 00 00 00 00 00 00 00 00 00 00 ax0............. 00 27 fa 2a 80 88 ff ff 00 00 00 00 00 00 00 00 .'.*............ backtrace: [<ffffffff81a27201>] kvmallocnode+0x61/0xf0 [<ffffffff8706e7e8>] allocnetdevmqs+0x98/0xe80 [<ffffffff84e64192>] mkissopen+0xb2/0x6f0 [1] [<ffffffff842355db>] ttyldiscopen+0x9b/0x110 [<ffffffff84236488>] ttysetldisc+0x2e8/0x670 [<ffffffff8421f7f3>] tty_ioctl+0xda3/0x1440 [<ffffffff81c9f273>] __x64sysioctl+0x193/0x200 [<ffffffff8911263a>] dosyscall64+0x3a/0xb0 [<ffffffff89200068>] entrySYSCALL64afterhwframe+0x44/0xae

BUG: memory leak unreferenced object 0xffff8880141a9a00 (size 96): comm "syz-executor.1", pid 11443, jiffies 4295046091 (age 17.660s) hex dump (first 32 bytes): e8 a2 1b 28 80 88 ff ff e8 a2 1b 28 80 88 ff ff ...(.......(.... 98 92 9c aa b0 40 02 00 00 00 00 00 00 00 00 00 .....@.......... backtrace: [<ffffffff8709f68b>] __hwaddrcreate_ex+0x5b/0x310 [<ffffffff8709fb38>] __hwaddradd_ex+0x1f8/0x2b0 [<ffffffff870a0c7b>] devaddrinit+0x10b/0x1f0 [<ffffffff8706e88b>] allocnetdevmqs+0x13b/0xe80 [<ffffffff84e64192>] mkissopen+0xb2/0x6f0 [1] [<ffffffff842355db>] ttyldiscopen+0x9b/0x110 [<ffffffff84236488>] ttysetldisc+0x2e8/0x670 [<ffffffff8421f7f3>] ttyioctl+0xda3/0x1440 [<ffffffff81c9f273>] __x64sysioctl+0x193/0x200 [<ffffffff8911263a>] dosyscall64+0x3a/0xb0 [<ffffffff89200068>] entrySYSCALL64afterhwframe+0x44/0xae

BUG: memory leak unreferenced object 0xffff8880219bfc00 (size 512): comm "syz-executor.1", pid 11443, jiffies 4295046091 (age 17.660s) hex dump (first 32 bytes): 00 a0 1b 28 80 88 ff ff 80 8f b1 8d ff ff ff ff ...(............ 80 8f b1 8d ff ff ff ff 00 00 00 00 00 00 00 00 ................ backtrace: [<ffffffff81a27201>] kvmallocnode+0x61/0xf0 [<ffffffff8706eec7>] allocnetdevmqs+0x777/0xe80 [<ffffffff84e64192>] mkissopen+0xb2/0x6f0 [1] [<ffffffff842355db>] ttyldiscopen+0x9b/0x110 [<ffffffff84236488>] ttysetldisc+0x2e8/0x670 [<ffffffff8421f7f3>] tty_ioctl+0xda3/0x1440 [<ffffffff81c9f273>] __x64sysioctl+0x193/0x200 [<ffffffff8911263a>] dosyscall64+0x3a/0xb0 [<ffffffff89200068>] entrySYSCALL64afterhwframe+0x44/0xae

BUG: memory leak unreferenced object 0xffff888029b2b200 (size 256): comm "syz-executor.1", pid 11443, jiffies 4295046091 (age 17.660s) hex dump (first 32 bytes): 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ backtrace: [<ffffffff81a27201>] kvmallocnode+0x61/0xf0 [<ffffffff8706f062>] allocnetdevmqs+0x912/0xe80 [<ffffffff84e64192>] mkissopen+0xb2/0x6f0 [1] [<ffffffff842355db>] ttyldiscopen+0x9b/0x110 [<ffffffff84236488>] ttysetldisc+0x2e8/0x670 [<ffffffff8421f7f3>] tty_ioctl+0xda3/0x1440 [<ffffffff81c9f273>] __x64sysioctl+0x193/0x200 [<ffffffff8911263a>] dosyscall64+0x3a/0xb0 [<ffffffff89200068>] entrySYSCALL64afterhwframe+0x44/0xae(CVE-2021-47237)

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

IB/mlx5: Fix initializing CQ fragments buffer

The function initcqfragbuf() can be called to initialize the current CQ fragments buffer cq->buf, or the temporary cq->resizebuf that is filled during CQ resize operation.

However, the offending commit started to use function getcqe() for getting the CQEs, the issue with this change is that getcqe() always returns CQEs from cq->buf, which leads us to initialize the wrong buffer, and in case of enlarging the CQ we try to access elements beyond the size of the current cq->buf and eventually hit a kernel panic.

[exception RIP: initcqfragbuf+103] [ffff9f799ddcbcd8] mlx5ibresizecq at ffffffffc0835d60 [mlx5ib] [ffff9f799ddcbdb0] ibresizecq at ffffffffc05270df [ibcore] [ffff9f799ddcbdc0] lltrdmasetupqp at ffffffffc0a6a712 [llt] [ffff9f799ddcbe10] lltrdmacceventaction at ffffffffc0a6b411 [llt] [ffff9f799ddcbe98] lltrdmaclientconnthread at ffffffffc0a6bb75 [llt] [ffff9f799ddcbec8] kthread at ffffffffa66c5da1 [ffff9f799ddcbf50] retfromforknospec_begin at ffffffffa6d95ddd

Fix it by getting the needed CQE by calling mlx5fragbufgetwqe() that takes the correct source buffer as a parameter.(CVE-2021-47261)

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

smackfs: restrict bytes count in smksetcipso()

Oops, I failed to update subject line.

From 07571157c91b98ce1a4aa70967531e64b78e8346 Mon Sep 17 00:00:00 2001 Date: Mon, 12 Apr 2021 22:25:06 +0900 Subject: [PATCH] smackfs: restrict bytes count in smksetcipso()

Commit 7ef4c19d245f3dc2 ("smackfs: restrict bytes count in smackfs write functions") missed that count > SMKCIPSOMAX check applies to only format == SMKFIXED24_FMT case.(CVE-2021-47336)

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

RDMA/cma: Fix rdmaresolveroute() memory leak

Fix a memory leak when "mdaresolveroute() is called more than once on the same "rdmacmid".

This is possible if cmaqueryhandler() triggers the RDMACMEVENTROUTEERROR flow which puts the state machine back and allows rdmaresolveroute() to be called again.(CVE-2021-47345)

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

i40e: Fix NULL pointer dereference in i40edbgdump_desc

When trying to dump VFs VSI RX/TX descriptors using debugfs there was a crash due to NULL pointer dereference in i40edbgdumpdesc. Added a check to i40edbgdumpdesc that checks if VSI type is correct for dumping RX/TX descriptors.(CVE-2021-47501)

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

can: pchcan: pchcanrxnormal: fix use after free

After calling netifreceiveskb(skb), dereferencing skb is unsafe. Especially, the canframe cf which aliases skb memory is dereferenced just after the call netifreceive_skb(skb).

Reordering the lines solves the issue.(CVE-2021-47520)

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

ALSA: hda: Fix possible null-ptr-deref when assigning a stream

While AudioDSP drivers assign streams exclusively of HOST or LINK type, nothing blocks a user to attempt to assign a COUPLED stream. As supplied substream instance may be a stub, what is the case when code-loading, such scenario ends with null-ptr-deref.(CVE-2023-52806)

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

netfilter: complete validation of user input

In my recent commit, I missed that doreplace() handlers use copyfromsockptr() (which I fixed), followed by unsafe copyfromsockptroffset() calls.

In all functions, we can perform the @optlen validation before even calling xtalloctable_info() with the following check:

if ((u64)optlen < (u64)tmp.size + sizeof(tmp)) return -EINVAL;(CVE-2024-35962)

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

crypto: algif_aead - Fix minimum RX size check for decryption

The check for the minimum receive buffer size did not take the tag size into account during decryption. Fix this by adding the required extra length.(CVE-2026-43077)

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

crypto: afalg - Fix page reassignment overflow in afalgpulltsgl

When page reassignment was added to afalgpull_tsgl the original loop wasn't updated so it may try to reassign one more page than necessary.

Add the check to the reassignment so that this does not happen.

Also update the comment which still refers to the obsolete offset argument.(CVE-2026-43078)

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

PCI: Fix pcislottrylock() error handling

Commit a4e772898f8b ("PCI: Add missing bridge lock to pcibuslock()") delegates the bridge device's pcidevtrylock() to pcibustrylock() in pcislottrylock(), but it forgets to remove the corresponding pcidevunlock() when pcibustrylock() fails.

Before a4e772898f8b, the code did:

if (!pcidevtrylock(dev)) /* <- lock bridge device / goto unlock; if (dev->subordinate) { if (!pcibustrylock(dev->subordinate)) { pcidevunlock(dev); / <- unlock bridge device */ goto unlock; } }

After a4e772898f8b the bridge-device lock is no longer taken, but the pcidevunlock(dev) on the failure path was left in place, leading to the bug.

This yields one of two errors:

1. A warning that the lock is being unlocked when no one holds it.
2. An incorrect unlock of a lock that belongs to another thread.

Fix it by removing the now-redundant pcidevunlock(dev) on the failure path.

[Same patch later posted by Keith at https://patch.msgid.link/(CVE-2026-43211)

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

ipv6: prevent possible UaF in addrconfpermanentaddr()

The mentioned helper try to warn the user about an exceptional condition, but the message is delivered too late, accessing the ipv6 after its possible deletion.

Reorder the statement to avoid the possible UaF; while at it, place the warning outside the idev->lock as it needs no protection.(CVE-2026-43339)

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

RDMA/rxe: Fix double free in rxesrqfrom_init

In rxesrqfrominit(), the queue pointer 'q' is assigned to 'srq->rq.queue' before copying the SRQ number to user space. If copytouser() fails, the function calls rxequeue_cleanup() to free the queue, but leaves the now-invalid pointer in 'srq->rq.queue'.

The caller of rxesrqfrominit() (rxecreatesrq) eventually calls rxesrqcleanup() upon receiving the error, which triggers a second rxequeue_cleanup() on the same memory, leading to a double free.

The call trace looks like this: kmemcachefree+0x.../0x... rxequeuecleanup+0x1a/0x30 [rdmarxe] rxesrqcleanup+0x42/0x60 [rdmarxe] rxeelemrelease+0x31/0x70 [rdmarxe] rxecreatesrq+0x12b/0x1a0 [rdmarxe] ibcreatesrquser+0x9a/0x150 [ibcore]

Fix this by moving 'srq->rq.queue = q' after copytouser.(CVE-2026-45852)

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

sched/rt: Skip currently executing CPU in rtonextcpu()

CPU0 becomes overloaded when hosting a CPU-bound RT task, a non-CPU-bound RT task, and a CFS task stuck in kernel space. When other CPUs switch from RT to non-RT tasks, RT load balancing (LB) is triggered; with HAVERTPUSHIPI enabled, they send IPIs to CPU0 to drive the execution of rtopushirqworkfunc. During pushrttask on CPU0, if nexttask->prio < rq->donor->prio, reschedcurr() sets NEEDRESCHED and after the push operation completes, CPU0 calls rtonextcpu(). Since only CPU0 is overloaded in this scenario, rtonextcpu() should ideally return -1 (no further IPI needed).

However, multiple CPUs invoking tellcputopush() during LB increments rd->rtoloopnext. Even when rd->rtocpu is set to -1, the mismatch between rd->rtoloop and rd->rtoloopnext forces rtonextcpu() to restart its search from -1. With CPU0 remaining overloaded (satisfying rtnrmigratory && rtnrtotal > 1), it gets reselected, causing CPU0 to queue irqwork to itself and send self-IPIs repeatedly. As long as CPU0 stays overloaded and other CPUs run pullrttasks(), it falls into an infinite self-IPI loop, which triggers a CPU hardlockup due to continuous self-interrupts.

The trigging scenario is as follows:

     cpu0                      cpu1                    cpu2
                            pull_rt_task
                          tell_cpu_to_push
             <------------irq_work_queue_on

rtopushirqworkfunc pushrttask reschedcurr(rq) pullrttask rtonextcpu tellcputopush <-------------------------- atomicinc(rtoloopnext) rd->rtoloop != next rtonextcpu irqworkqueueon rtopushirqwork_func

Fix redundant self-IPI by filtering the initiating CPU in rtonextcpu(). This solution has been verified to effectively eliminate spurious self-IPIs and prevent CPU hardlockup scenarios.(CVE-2026-45919)

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

bonding: alb: fix UAF in rlbarprecv during bond up/down

The ALB RX path may access rxhashtbl concurrently with bond teardown. During rapid bond up/down cycles, rlbdeinitialize() frees rx_hashtbl while RX handlers are still running, leading to a null pointer dereference detected by KASAN.

However, the root cause is that rlbarprecv() can still be accessed after setting recv_probe to NULL, which is actually a use-after-free (UAF) issue. That is the reason for using the referenced commit in the Fixes tag.

[ 214.174138] Oops: general protection fault, probably for non-canonical address 0xdffffc000000001d: 0000 [#1] SMP KASAN PTI [ 214.186478] KASAN: null-ptr-deref in range [0x00000000000000e8-0x00000000000000ef] [ 214.194933] CPU: 30 UID: 0 PID: 2375 Comm: ping Kdump: loaded Not tainted 6.19.0-rc8+ #2 PREEMPT(voluntary) [ 214.205907] Hardware name: Dell Inc. PowerEdge R730/0WCJNT, BIOS 2.14.0 01/14/2022 [ 214.214357] RIP: 0010:rlbarprecv+0x505/0xab0 [bonding] [ 214.220320] Code: 0f 85 2b 05 00 00 48 b8 00 00 00 00 00 fc ff df 40 0f b6 ed 48 c1 e5 06 49 03 ad 78 01 00 00 48 8d 7d 28 48 89 fa 48 c1 ea 03 <0f> b6 04 02 84 c0 74 06 0f 8e 12 05 00 00 80 7d 28 00 0f 84 8c 00 [ 214.241280] RSP: 0018:ffffc900073d8870 EFLAGS: 00010206 [ 214.247116] RAX: dffffc0000000000 RBX: ffff888168556822 RCX: ffff88816855681e [ 214.255082] RDX: 000000000000001d RSI: dffffc0000000000 RDI: 00000000000000e8 [ 214.263048] RBP: 00000000000000c0 R08: 0000000000000002 R09: ffffed11192021c8 [ 214.271013] R10: ffff8888c9010e43 R11: 0000000000000001 R12: 1ffff92000e7b119 [ 214.278978] R13: ffff8888c9010e00 R14: ffff888168556822 R15: ffff888168556810 [ 214.286943] FS: 00007f85d2d9cb80(0000) GS:ffff88886ccb3000(0000) knlGS:0000000000000000 [ 214.295966] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 214.302380] CR2: 00007f0d047b5e34 CR3: 00000008a1c2e002 CR4: 00000000001726f0 [ 214.310347] Call Trace: [ 214.313070] <IRQ> [ 214.315318] ? __pfxrlbarp_recv+0x10/0x10 [bonding] [ 214.320975] bondhandleframe+0x166/0xb60 [bonding] [ 214.326537] ? __pfxbondhandle_frame+0x10/0x10 [bonding] [ 214.332680] __netifreceiveskb_core.constprop.0+0x576/0x2710 [ 214.339199] ? __pfxarpprocess+0x10/0x10 [ 214.343775] ? sched_balancefindsrcgroup+0x98/0x630 [ 214.349513] ? pfxnetifreceiveskbcore.constprop.0+0x10/0x10 [ 214.356513] ? arprcv+0x307/0x690 [ 214.360311] ? __pfxarprcv+0x10/0x10 [ 214.364499] ? __lock_acquire+0x58c/0xbd0 [ 214.368975] __netifreceivelock_acquire+0x58c/0xbd0 [ 214.368975] __netifreceiveskbonecore+0xae/0x1b0 [ 214.374518] ? pfxetif_receiveskbonecore+0x10/0x10 [ 214.380743] ? lockacquire+0x10b/0x140 [ 214.385026] processbacklog+0x3f1/0x13a0 [ 214.389502] ? processbacklog+0x3aa/0x13a0 [ 214.394174] __napipoll.constprop.0+0x9f/0x370 [ 214.399233] netrx_action+0x8c1/0xe60 [ 214.403423] ? __pfxnetrx_action+0x10/0x10 [ 214.408193] ? lockacquire.part.0+0xbd/0x260 [ 214.413058] ? schedclockcpu+0x6c/0x540 [ 214.417540] ? markheldlocks+0x40/0x70 [ 214.421920] handlesoftirqs+0x1fd/0x860 [ 214.426302] ? __pfxhandlesoftirqs+0x10/0x10 [ 214.431264] ? _neigheventsend+0x2d6/0xf50 [ 214.436131] dosoftirq+0xb1/0xf0 [ 214.439830] </IRQ>

The issue is reproducible by repeatedly running ip link set bond0 up/down while receiving ARP messages, where rlbarprecv() can race with rlbdeinitialize() and dereference a freed rxhashtbl entry.

Fix this by setting recvprobe to NULL and then calling synchronizenet() to wait for any concurrent RX processing to finish. This ensures that no RX handler can access rxhashtbl after it is freed in bondalb_deinitialize().(CVE-2026-45970)

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

crypto: algif_aead - snapshot IV for async AEAD requests

AF_ALG AEAD AIO requests currently use the socket-wide IV buffer during request processing. For async requests, later socket activity can update that shared state before the original request has fully completed, which can lead to inconsistent IV handling.

Snapshot the IV into per-request storage when preparing the AEAD request, so in-flight operations no longer depend on mutable socket state.(CVE-2026-46028)

In the Linux kernel, drmgemfbinitwithfuncs() computes sub-sampled plane dimensions using plain integer division, while the ioctl-level framebuffercheck() uses DIVROUNDUP via drmformatinfoplanewidth/height(). This inconsistency causes incorrect GEM object size validation for certain pixel formats and dimensions, e.g., NV12 with height=1 results in height=0, leading to an integer overflow in size check and allowing undersized GEM objects to pass, potentially causing out-of-bounds memory access by the GPU.(CVE-2026-46209)

['This has been assigned CVE-2026-46243, see', 'On Thursday, May 28th, 2026 at 12:07 AM, manizada <manizada () pm me> wrote:', 'Hi folks,\n\nEmailing here now that the embargo agreed upon with linux-distros@ has expired.\n\nFlagging a local root vulnerability spanning both CIFS in the kernel and\ncifs-utils in userspace (originally reported to kernel/cifs maintainers on May 16).\nThe kernel-side (only) fix has now been public for over a week and is queued for stable:\n\n3da1fdf4efbc ("smb: client: reject userspace cifs.spnego descriptions")\n\nImpact:\n Unprivileged user -> root code exec on any system where:\n - cifs-utils is installed (with the default cifs.spnego rule)\n - CIFS kernel module is loadable/compiled-in (typically the case), and\n - unprivileged user/mount namespaces are enabled.\n\nSome default AppArmor/SELinux profiles block this.\n\nBug:\n An unprivileged user can call requestkey("cifs.spnego", ...) with a forged\n CIFS SPNEGO description. The request-key rule starts cifs.upcall as root.\n cifs.upcall then trusts attacker-supplied pid, uid, creduid, and\n upcalltarget fields as if they came from kernel CIFS.\n\n For upcalltarget=app, affected cifs-utils versions switch into the supplied\n process&apos;s namespaces and perform NSS lookup before final privilege drop.\n A private mount namespace containing attacker-controlled /etc/nsswitch.conf\n and libnss*.so.2 is therefore sufficient for code execution in the root\n helper.\n\nAffected distros:\n This a non-exhaustive summary of some tested distros. The full table, including\n the cases where stock policy blocks exploitation (but relaxing AppArmor/SELinux/etc.\n enables exploitation), is in the attachment (and in an easier-to-read format in\n the writeup linked below).\n\n Stock-default exploitable distros\n (cifs-utils comes preinstalled in the profile + unprivileged namespaces permitted by default\n + the AA/SELinux policies, if any, do not block the attack):\n\n - Linux Mint Cinnamon 21.3 and 22.3\n - CentOS Stream 9 GNOME\n - Rocky Linux 9 Workstation\n - Kali Linux headless 2021.4/2022.4/2023.4/2024.4/2025.4/2026.1\n - AlmaLinux 9.7 Workstation/Azure cloud image\n - SLES 15 SP7/SAP 15 SP7/SAP 16\n\n Exploitable if cifs-utils is installed, with no other default config changes:\n - Ubuntu 18.04/20.04/22.04 Desktop/Server\n - Pop!_OS 22.04 Intel/24.04 Generic\n - Ubuntu 24.04 Desktop minimal/full and Server\n - Debian 11/12/13 netinst standard and GNOME/KDE/standard/XFCE\n - CentOS Stream 9 Cinnamon/KDE/MATE/XFCE\n - Rocky Linux 9 KDE/Workstation-Lite\n - openSUSE Leap 15.6 GNOME/KDE\n - openSUSE Tumbleweed GNOME/KDE\n - Rocky Linux 8 GenericCloud\n - Oracle Linux 8/9 KVM\n - Amazon Linux 2023 KVM\n\nImmediate-term mitigations (aside from backporting the kernel fix):\n - Blocking the CIFS module from loading (assuming it&apos;s not built-in)/uninstalling cifs-utils if not used\n - Deleting/overriding the default cifs.spnego request-key rule (if Kerberos cifs is not required),\n e.g., after adjusting for your keyctl path:\n\n cat >/etc/request-key.d/cifs.spnego.conf <<&apos;EOF&apos;\n create cifs.spnego * * /usr/sbin/keyctl negate %k 30 %S\n EOF\n\n - Disabling unprivileged user namespaces\n\nThe CVE # assignment is still pending.\n\nFull writeup:', 'PoC to validate mitigations:', 'Thanks,\n-Asim Manizada'](CVE-2026-46243)

In the Linux kernel, the following vulnerability has been resolved: procfs: fix missing RCU protection when reading realparent in dotaskstat() When reading /proc/[pid]/stat, dotaskstat() accesses task->realparent without proper RCU protection, which leads to: cpu 0 cpu 1 ----- ----- dotaskstat var = task->realparent releasetask callrcu(delayedputtaskstruct) tasktgidnrns(var) rcureadlock <--- Too late to protect task->realparent! taskpidptr <--- UAF! rcureadunlock This patch uses taskppidnrns() instead of tasktgidnrns() to add proper RCU protection for accessing task->real_parent. The Linux kernel CVE team has assigned CVE-2026-46259 to this issue.(CVE-2026-46259)