{"schema_version":"1.7.2","id":"OESA-2026-2673","modified":"2026-06-12T12:27:17Z","published":"2026-06-12T12:27:17Z","upstream":["CVE-2021-47237","CVE-2021-47261","CVE-2021-47336","CVE-2021-47345","CVE-2021-47501","CVE-2021-47520","CVE-2023-52806","CVE-2024-35962","CVE-2026-43077","CVE-2026-43078","CVE-2026-43211","CVE-2026-43339","CVE-2026-45852","CVE-2026-45919","CVE-2026-45970","CVE-2026-46028","CVE-2026-46209","CVE-2026-46243","CVE-2026-46259"],"summary":"kernel security update","details":"The Linux Kernel, the operating system core itself.\r\n\r\nSecurity Fix(es):\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet: hamradio: fix memory leak in mkiss_close\n\nMy local syzbot instance hit memory leak in\nmkiss_open()[1]. The problem was in missing\nfree_netdev() in mkiss_close().\n\nIn mkiss_open() netdevice is allocated and then\nregistered, but in mkiss_close() netdevice was\nonly unregistered, but not freed.\n\nFail log:\n\nBUG: memory leak\nunreferenced object 0xffff8880281ba000 (size 4096):\n  comm "syz-executor.1", pid 11443, jiffies 4295046091 (age 17.660s)\n  hex dump (first 32 bytes):\n    61 78 30 00 00 00 00 00 00 00 00 00 00 00 00 00  ax0.............\n    00 27 fa 2a 80 88 ff ff 00 00 00 00 00 00 00 00  .'.*............\n  backtrace:\n    [<ffffffff81a27201>] kvmalloc_node+0x61/0xf0\n    [<ffffffff8706e7e8>] alloc_netdev_mqs+0x98/0xe80\n    [<ffffffff84e64192>] mkiss_open+0xb2/0x6f0 [1]\n    [<ffffffff842355db>] tty_ldisc_open+0x9b/0x110\n    [<ffffffff84236488>] tty_set_ldisc+0x2e8/0x670\n    [<ffffffff8421f7f3>] tty_ioctl+0xda3/0x1440\n    [<ffffffff81c9f273>] __x64_sys_ioctl+0x193/0x200\n    [<ffffffff8911263a>] do_syscall_64+0x3a/0xb0\n    [<ffffffff89200068>] entry_SYSCALL_64_after_hwframe+0x44/0xae\n\nBUG: memory leak\nunreferenced object 0xffff8880141a9a00 (size 96):\n  comm "syz-executor.1", pid 11443, jiffies 4295046091 (age 17.660s)\n  hex dump (first 32 bytes):\n    e8 a2 1b 28 80 88 ff ff e8 a2 1b 28 80 88 ff ff  ...(.......(....\n    98 92 9c aa b0 40 02 00 00 00 00 00 00 00 00 00  .....@..........\n  backtrace:\n    [<ffffffff8709f68b>] __hw_addr_create_ex+0x5b/0x310\n    [<ffffffff8709fb38>] __hw_addr_add_ex+0x1f8/0x2b0\n    [<ffffffff870a0c7b>] dev_addr_init+0x10b/0x1f0\n    [<ffffffff8706e88b>] alloc_netdev_mqs+0x13b/0xe80\n    [<ffffffff84e64192>] mkiss_open+0xb2/0x6f0 [1]\n    [<ffffffff842355db>] tty_ldisc_open+0x9b/0x110\n    [<ffffffff84236488>] tty_set_ldisc+0x2e8/0x670\n    [<ffffffff8421f7f3>] tty_ioctl+0xda3/0x1440\n    [<ffffffff81c9f273>] __x64_sys_ioctl+0x193/0x200\n    [<ffffffff8911263a>] do_syscall_64+0x3a/0xb0\n    [<ffffffff89200068>] entry_SYSCALL_64_after_hwframe+0x44/0xae\n\nBUG: memory leak\nunreferenced object 0xffff8880219bfc00 (size 512):\n  comm "syz-executor.1", pid 11443, jiffies 4295046091 (age 17.660s)\n  hex dump (first 32 bytes):\n    00 a0 1b 28 80 88 ff ff 80 8f b1 8d ff ff ff ff  ...(............\n    80 8f b1 8d ff ff ff ff 00 00 00 00 00 00 00 00  ................\n  backtrace:\n    [<ffffffff81a27201>] kvmalloc_node+0x61/0xf0\n    [<ffffffff8706eec7>] alloc_netdev_mqs+0x777/0xe80\n    [<ffffffff84e64192>] mkiss_open+0xb2/0x6f0 [1]\n    [<ffffffff842355db>] tty_ldisc_open+0x9b/0x110\n    [<ffffffff84236488>] tty_set_ldisc+0x2e8/0x670\n    [<ffffffff8421f7f3>] tty_ioctl+0xda3/0x1440\n    [<ffffffff81c9f273>] __x64_sys_ioctl+0x193/0x200\n    [<ffffffff8911263a>] do_syscall_64+0x3a/0xb0\n    [<ffffffff89200068>] entry_SYSCALL_64_after_hwframe+0x44/0xae\n\nBUG: memory leak\nunreferenced object 0xffff888029b2b200 (size 256):\n  comm "syz-executor.1", pid 11443, jiffies 4295046091 (age 17.660s)\n  hex dump (first 32 bytes):\n    00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................\n    00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................\n  backtrace:\n    [<ffffffff81a27201>] kvmalloc_node+0x61/0xf0\n    [<ffffffff8706f062>] alloc_netdev_mqs+0x912/0xe80\n    [<ffffffff84e64192>] mkiss_open+0xb2/0x6f0 [1]\n    [<ffffffff842355db>] tty_ldisc_open+0x9b/0x110\n    [<ffffffff84236488>] tty_set_ldisc+0x2e8/0x670\n    [<ffffffff8421f7f3>] tty_ioctl+0xda3/0x1440\n    [<ffffffff81c9f273>] __x64_sys_ioctl+0x193/0x200\n    [<ffffffff8911263a>] do_syscall_64+0x3a/0xb0\n    [<ffffffff89200068>] entry_SYSCALL_64_after_hwframe+0x44/0xae(CVE-2021-47237)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nIB/mlx5: Fix initializing CQ fragments buffer\n\nThe function init_cq_frag_buf() can be called to initialize the current CQ\nfragments buffer cq->buf, or the temporary cq->resize_buf that is filled\nduring CQ resize operation.\n\nHowever, the offending commit started to use function get_cqe() for\ngetting the CQEs, the issue with this change is that get_cqe() always\nreturns CQEs from cq->buf, which leads us to initialize the wrong buffer,\nand in case of enlarging the CQ we try to access elements beyond the size\nof the current cq->buf and eventually hit a kernel panic.\n\n [exception RIP: init_cq_frag_buf+103]\n  [ffff9f799ddcbcd8] mlx5_ib_resize_cq at ffffffffc0835d60 [mlx5_ib]\n  [ffff9f799ddcbdb0] ib_resize_cq at ffffffffc05270df [ib_core]\n  [ffff9f799ddcbdc0] llt_rdma_setup_qp at ffffffffc0a6a712 [llt]\n  [ffff9f799ddcbe10] llt_rdma_cc_event_action at ffffffffc0a6b411 [llt]\n  [ffff9f799ddcbe98] llt_rdma_client_conn_thread at ffffffffc0a6bb75 [llt]\n  [ffff9f799ddcbec8] kthread at ffffffffa66c5da1\n  [ffff9f799ddcbf50] ret_from_fork_nospec_begin at ffffffffa6d95ddd\n\nFix it by getting the needed CQE by calling mlx5_frag_buf_get_wqe() that\ntakes the correct source buffer as a parameter.(CVE-2021-47261)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nsmackfs: restrict bytes count in smk_set_cipso()\n\nOops, I failed to update subject line.\n\nFrom 07571157c91b98ce1a4aa70967531e64b78e8346 Mon Sep 17 00:00:00 2001\nDate: Mon, 12 Apr 2021 22:25:06 +0900\nSubject: [PATCH] smackfs: restrict bytes count in smk_set_cipso()\n\nCommit 7ef4c19d245f3dc2 ("smackfs: restrict bytes count in smackfs write\nfunctions") missed that count > SMK_CIPSOMAX check applies to only\nformat == SMK_FIXED24_FMT case.(CVE-2021-47336)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nRDMA/cma: Fix rdma_resolve_route() memory leak\n\nFix a memory leak when "mda_resolve_route() is called more than once on\nthe same "rdma_cm_id".\n\nThis is possible if cma_query_handler() triggers the\nRDMA_CM_EVENT_ROUTE_ERROR flow which puts the state machine back and\nallows rdma_resolve_route() to be called again.(CVE-2021-47345)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ni40e: Fix NULL pointer dereference in i40e_dbg_dump_desc\n\nWhen trying to dump VFs VSI RX/TX descriptors\nusing debugfs there was a crash\ndue to NULL pointer dereference in i40e_dbg_dump_desc.\nAdded a check to i40e_dbg_dump_desc that checks if\nVSI type is correct for dumping RX/TX descriptors.(CVE-2021-47501)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ncan: pch_can: pch_can_rx_normal: fix use after free\n\nAfter calling netif_receive_skb(skb), dereferencing skb is unsafe.\nEspecially, the can_frame cf which aliases skb memory is dereferenced\njust after the call netif_receive_skb(skb).\n\nReordering the lines solves the issue.(CVE-2021-47520)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nALSA: hda: Fix possible null-ptr-deref when assigning a stream\n\nWhile AudioDSP drivers assign streams exclusively of HOST or LINK type,\nnothing blocks a user to attempt to assign a COUPLED stream. As\nsupplied substream instance may be a stub, what is the case when\ncode-loading, such scenario ends with null-ptr-deref.(CVE-2023-52806)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnetfilter: complete validation of user input\n\nIn my recent commit, I missed that do_replace() handlers\nuse copy_from_sockptr() (which I fixed), followed\nby unsafe copy_from_sockptr_offset() calls.\n\nIn all functions, we can perform the @optlen validation\nbefore even calling xt_alloc_table_info() with the following\ncheck:\n\nif ((u64)optlen < (u64)tmp.size + sizeof(tmp))\n        return -EINVAL;(CVE-2024-35962)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ncrypto: algif_aead - Fix minimum RX size check for decryption\n\nThe check for the minimum receive buffer size did not take the\ntag size into account during decryption.  Fix this by adding the\nrequired extra length.(CVE-2026-43077)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ncrypto: af_alg - Fix page reassignment overflow in af_alg_pull_tsgl\n\nWhen page reassignment was added to af_alg_pull_tsgl the original\nloop wasn't updated so it may try to reassign one more page than\nnecessary.\n\nAdd the check to the reassignment so that this does not happen.\n\nAlso update the comment which still refers to the obsolete offset\nargument.(CVE-2026-43078)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nPCI: Fix pci_slot_trylock() error handling\n\nCommit a4e772898f8b ("PCI: Add missing bridge lock to pci_bus_lock()")\ndelegates the bridge device's pci_dev_trylock() to pci_bus_trylock() in\npci_slot_trylock(), but it forgets to remove the corresponding\npci_dev_unlock() when pci_bus_trylock() fails.\n\nBefore a4e772898f8b, the code did:\n\n  if (!pci_dev_trylock(dev)) /* <- lock bridge device */\n    goto unlock;\n  if (dev->subordinate) {\n    if (!pci_bus_trylock(dev->subordinate)) {\n      pci_dev_unlock(dev);   /* <- unlock bridge device */\n      goto unlock;\n    }\n  }\n\nAfter a4e772898f8b the bridge-device lock is no longer taken, but the\npci_dev_unlock(dev) on the failure path was left in place, leading to the\nbug.\n\nThis yields one of two errors:\n\n  1. A warning that the lock is being unlocked when no one holds it.\n  2. An incorrect unlock of a lock that belongs to another thread.\n\nFix it by removing the now-redundant pci_dev_unlock(dev) on the failure\npath.\n\n[Same patch later posted by Keith at\nhttps://patch.msgid.link/(CVE-2026-43211)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nipv6: prevent possible UaF in addrconf_permanent_addr()\n\nThe mentioned helper try to warn the user about an exceptional\ncondition, but the message is delivered too late, accessing the ipv6\nafter its possible deletion.\n\nReorder the statement to avoid the possible UaF; while at it, place the\nwarning outside the idev->lock as it needs no protection.(CVE-2026-43339)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nRDMA/rxe: Fix double free in rxe_srq_from_init\n\nIn rxe_srq_from_init(), the queue pointer 'q' is assigned to\n'srq->rq.queue' before copying the SRQ number to user space.\nIf copy_to_user() fails, the function calls rxe_queue_cleanup()\nto free the queue, but leaves the now-invalid pointer in\n'srq->rq.queue'.\n\nThe caller of rxe_srq_from_init() (rxe_create_srq) eventually\ncalls rxe_srq_cleanup() upon receiving the error, which triggers\na second rxe_queue_cleanup() on the same memory, leading to a\ndouble free.\n\nThe call trace looks like this:\n   kmem_cache_free+0x.../0x...\n   rxe_queue_cleanup+0x1a/0x30 [rdma_rxe]\n   rxe_srq_cleanup+0x42/0x60 [rdma_rxe]\n   rxe_elem_release+0x31/0x70 [rdma_rxe]\n   rxe_create_srq+0x12b/0x1a0 [rdma_rxe]\n   ib_create_srq_user+0x9a/0x150 [ib_core]\n\nFix this by moving 'srq->rq.queue = q' after copy_to_user.(CVE-2026-45852)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nsched/rt: Skip currently executing CPU in rto_next_cpu()\n\nCPU0 becomes overloaded when hosting a CPU-bound RT task, a non-CPU-bound\nRT task, and a CFS task stuck in kernel space. When other CPUs switch from\nRT to non-RT tasks, RT load balancing (LB) is triggered; with\nHAVE_RT_PUSH_IPI enabled, they send IPIs to CPU0 to drive the execution\nof rto_push_irq_work_func. During push_rt_task on CPU0,\nif next_task->prio < rq->donor->prio, resched_curr() sets NEED_RESCHED\nand after the push operation completes, CPU0 calls rto_next_cpu().\nSince only CPU0 is overloaded in this scenario, rto_next_cpu() should\nideally return -1 (no further IPI needed).\n\nHowever, multiple CPUs invoking tell_cpu_to_push() during LB increments\nrd->rto_loop_next. Even when rd->rto_cpu is set to -1, the mismatch between\nrd->rto_loop and rd->rto_loop_next forces rto_next_cpu() to restart its\nsearch from -1. With CPU0 remaining overloaded (satisfying rt_nr_migratory\n&& rt_nr_total > 1), it gets reselected, causing CPU0 to queue irq_work to\nitself and send self-IPIs repeatedly. As long as CPU0 stays overloaded and\nother CPUs run pull_rt_tasks(), it falls into an infinite self-IPI loop,\nwhich triggers a CPU hardlockup due to continuous self-interrupts.\n\nThe trigging scenario is as follows:\n\n         cpu0                      cpu1                    cpu2\n                                pull_rt_task\n                              tell_cpu_to_push\n                 <------------irq_work_queue_on\nrto_push_irq_work_func\n       push_rt_task\n    resched_curr(rq)                                   pull_rt_task\n    rto_next_cpu                                     tell_cpu_to_push\n                      <-------------------------- atomic_inc(rto_loop_next)\nrd->rto_loop != next\n     rto_next_cpu\n   irq_work_queue_on\nrto_push_irq_work_func\n\nFix redundant self-IPI by filtering the initiating CPU in rto_next_cpu().\nThis solution has been verified to effectively eliminate spurious self-IPIs\nand prevent CPU hardlockup scenarios.(CVE-2026-45919)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nbonding: alb: fix UAF in rlb_arp_recv during bond up/down\n\nThe ALB RX path may access rx_hashtbl concurrently with bond\nteardown. During rapid bond up/down cycles, rlb_deinitialize()\nfrees rx_hashtbl while RX handlers are still running, leading\nto a null pointer dereference detected by KASAN.\n\nHowever, the root cause is that rlb_arp_recv() can still be accessed\nafter setting recv_probe to NULL, which is actually a use-after-free\n(UAF) issue. That is the reason for using the referenced commit in the\nFixes tag.\n\n[  214.174138] Oops: general protection fault, probably for non-canonical address 0xdffffc000000001d: 0000 [#1] SMP KASAN PTI\n[  214.186478] KASAN: null-ptr-deref in range [0x00000000000000e8-0x00000000000000ef]\n[  214.194933] CPU: 30 UID: 0 PID: 2375 Comm: ping Kdump: loaded Not tainted 6.19.0-rc8+ #2 PREEMPT(voluntary)\n[  214.205907] Hardware name: Dell Inc. PowerEdge R730/0WCJNT, BIOS 2.14.0 01/14/2022\n[  214.214357] RIP: 0010:rlb_arp_recv+0x505/0xab0 [bonding]\n[  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\n 04 02 84 c0 74 06 0f 8e 12 05 00 00 80 7d 28 00 0f 84 8c 00\n[  214.241280] RSP: 0018:ffffc900073d8870 EFLAGS: 00010206\n[  214.247116] RAX: dffffc0000000000 RBX: ffff888168556822 RCX: ffff88816855681e\n[  214.255082] RDX: 000000000000001d RSI: dffffc0000000000 RDI: 00000000000000e8\n[  214.263048] RBP: 00000000000000c0 R08: 0000000000000002 R09: ffffed11192021c8\n[  214.271013] R10: ffff8888c9010e43 R11: 0000000000000001 R12: 1ffff92000e7b119\n[  214.278978] R13: ffff8888c9010e00 R14: ffff888168556822 R15: ffff888168556810\n[  214.286943] FS:  00007f85d2d9cb80(0000) GS:ffff88886ccb3000(0000) knlGS:0000000000000000\n[  214.295966] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033\n[  214.302380] CR2: 00007f0d047b5e34 CR3: 00000008a1c2e002 CR4: 00000000001726f0\n[  214.310347] Call Trace:\n[  214.313070]  <IRQ>\n[  214.315318]  ? __pfx_rlb_arp_recv+0x10/0x10 [bonding]\n[  214.320975]  bond_handle_frame+0x166/0xb60 [bonding]\n[  214.326537]  ? __pfx_bond_handle_frame+0x10/0x10 [bonding]\n[  214.332680]  __netif_receive_skb_core.constprop.0+0x576/0x2710\n[  214.339199]  ? __pfx_arp_process+0x10/0x10\n[  214.343775]  ? sched_balance_find_src_group+0x98/0x630\n[  214.349513]  ? __pfx___netif_receive_skb_core.constprop.0+0x10/0x10\n[  214.356513]  ? arp_rcv+0x307/0x690\n[  214.360311]  ? __pfx_arp_rcv+0x10/0x10\n[  214.364499]  ? __lock_acquire+0x58c/0xbd0\n[  214.368975]  __netif_receive_skb_one_core+0xae/0x1b0\n[  214.374518]  ? __pfx___netif_receive_skb_one_core+0x10/0x10\n[  214.380743]  ? lock_acquire+0x10b/0x140\n[  214.385026]  process_backlog+0x3f1/0x13a0\n[  214.389502]  ? process_backlog+0x3aa/0x13a0\n[  214.394174]  __napi_poll.constprop.0+0x9f/0x370\n[  214.399233]  net_rx_action+0x8c1/0xe60\n[  214.403423]  ? __pfx_net_rx_action+0x10/0x10\n[  214.408193]  ? lock_acquire.part.0+0xbd/0x260\n[  214.413058]  ? sched_clock_cpu+0x6c/0x540\n[  214.417540]  ? mark_held_locks+0x40/0x70\n[  214.421920]  handle_softirqs+0x1fd/0x860\n[  214.426302]  ? __pfx_handle_softirqs+0x10/0x10\n[  214.431264]  ? __neigh_event_send+0x2d6/0xf50\n[  214.436131]  do_softirq+0xb1/0xf0\n[  214.439830]  </IRQ>\n\nThe issue is reproducible by repeatedly running\nip link set bond0 up/down while receiving ARP messages, where\nrlb_arp_recv() can race with rlb_deinitialize() and dereference\na freed rx_hashtbl entry.\n\nFix this by setting recv_probe to NULL and then calling\nsynchronize_net() to wait for any concurrent RX processing to finish.\nThis ensures that no RX handler can access rx_hashtbl after it is freed\nin bond_alb_deinitialize().(CVE-2026-45970)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ncrypto: algif_aead - snapshot IV for async AEAD requests\n\nAF_ALG AEAD AIO requests currently use the socket-wide IV buffer during\nrequest processing.  For async requests, later socket activity can\nupdate that shared state before the original request has fully\ncompleted, which can lead to inconsistent IV handling.\n\nSnapshot the IV into per-request storage when preparing the AEAD\nrequest, so in-flight operations no longer depend on mutable socket\nstate.(CVE-2026-46028)\n\nIn the Linux kernel, drm_gem_fb_init_with_funcs() computes sub-sampled plane dimensions using plain integer division, while the ioctl-level framebuffer_check() uses DIV_ROUND_UP via drm_format_info_plane_width/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)\n\n['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 request_key("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  upcall_target fields as if they came from kernel CIFS.\\n\\n  For upcall_target=app, affected cifs-utils versions switch into the supplied\\n  process\\'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\\'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 <<\\'EOF\\'\\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)\n\nIn the Linux kernel, the following vulnerability has been resolved:  procfs: fix missing RCU protection when reading real_parent in do_task_stat()  When reading /proc/[pid]/stat, do_task_stat() accesses task->real_parent without proper RCU protection, which leads to:    cpu 0                               cpu 1   -----                               -----   do_task_stat     var = task->real_parent                                       release_task                                         call_rcu(delayed_put_task_struct)     task_tgid_nr_ns(var)       rcu_read_lock   <--- Too late to protect task->real_parent!       task_pid_ptr    <--- UAF!       rcu_read_unlock  This patch uses task_ppid_nr_ns() instead of task_tgid_nr_ns() 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)","affected":[{"package":{"ecosystem":"openEuler:20.03-LTS-SP4","name":"kernel","purl":"pkg:rpm/openEuler/kernel&distro=openEuler-20.03-LTS-SP4"},"ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"4.19.90-2606.3.0.0376.oe2003sp4"}]}],"ecosystem_specific":{"aarch64":["bpftool-4.19.90-2606.3.0.0376.oe2003sp4.aarch64.rpm","bpftool-debuginfo-4.19.90-2606.3.0.0376.oe2003sp4.aarch64.rpm","kernel-4.19.90-2606.3.0.0376.oe2003sp4.aarch64.rpm","kernel-debuginfo-4.19.90-2606.3.0.0376.oe2003sp4.aarch64.rpm","kernel-debugsource-4.19.90-2606.3.0.0376.oe2003sp4.aarch64.rpm","kernel-devel-4.19.90-2606.3.0.0376.oe2003sp4.aarch64.rpm","kernel-source-4.19.90-2606.3.0.0376.oe2003sp4.aarch64.rpm","kernel-tools-4.19.90-2606.3.0.0376.oe2003sp4.aarch64.rpm","kernel-tools-debuginfo-4.19.90-2606.3.0.0376.oe2003sp4.aarch64.rpm","kernel-tools-devel-4.19.90-2606.3.0.0376.oe2003sp4.aarch64.rpm","perf-4.19.90-2606.3.0.0376.oe2003sp4.aarch64.rpm","perf-debuginfo-4.19.90-2606.3.0.0376.oe2003sp4.aarch64.rpm","python2-perf-4.19.90-2606.3.0.0376.oe2003sp4.aarch64.rpm","python2-perf-debuginfo-4.19.90-2606.3.0.0376.oe2003sp4.aarch64.rpm","python3-perf-4.19.90-2606.3.0.0376.oe2003sp4.aarch64.rpm","python3-perf-debuginfo-4.19.90-2606.3.0.0376.oe2003sp4.aarch64.rpm"],"src":["kernel-4.19.90-2606.3.0.0376.oe2003sp4.src.rpm"],"x86_64":["bpftool-4.19.90-2606.3.0.0376.oe2003sp4.x86_64.rpm","bpftool-debuginfo-4.19.90-2606.3.0.0376.oe2003sp4.x86_64.rpm","kernel-4.19.90-2606.3.0.0376.oe2003sp4.x86_64.rpm","kernel-debuginfo-4.19.90-2606.3.0.0376.oe2003sp4.x86_64.rpm","kernel-debugsource-4.19.90-2606.3.0.0376.oe2003sp4.x86_64.rpm","kernel-devel-4.19.90-2606.3.0.0376.oe2003sp4.x86_64.rpm","kernel-source-4.19.90-2606.3.0.0376.oe2003sp4.x86_64.rpm","kernel-tools-4.19.90-2606.3.0.0376.oe2003sp4.x86_64.rpm","kernel-tools-debuginfo-4.19.90-2606.3.0.0376.oe2003sp4.x86_64.rpm","kernel-tools-devel-4.19.90-2606.3.0.0376.oe2003sp4.x86_64.rpm","perf-4.19.90-2606.3.0.0376.oe2003sp4.x86_64.rpm","perf-debuginfo-4.19.90-2606.3.0.0376.oe2003sp4.x86_64.rpm","python2-perf-4.19.90-2606.3.0.0376.oe2003sp4.x86_64.rpm","python2-perf-debuginfo-4.19.90-2606.3.0.0376.oe2003sp4.x86_64.rpm","python3-perf-4.19.90-2606.3.0.0376.oe2003sp4.x86_64.rpm","python3-perf-debuginfo-4.19.90-2606.3.0.0376.oe2003sp4.x86_64.rpm"]}}],"references":[{"type":"ADVISORY","url":"https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2026-2673"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2021-47237"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2021-47261"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2021-47336"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2021-47345"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2021-47501"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2021-47520"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2023-52806"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-35962"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-43077"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-43078"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-43211"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-43339"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-45852"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-45919"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-45970"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-46028"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-46209"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-46243"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-46259"}],"database_specific":{"severity":"High"}}