{"schema_version":"1.7.2","id":"OESA-2026-2493","modified":"2026-05-29T13:34:38Z","published":"2026-05-29T13:34:38Z","upstream":["CVE-2026-23292","CVE-2026-23296","CVE-2026-23313","CVE-2026-23317","CVE-2026-23352","CVE-2026-23360","CVE-2026-23374","CVE-2026-23383","CVE-2026-31503","CVE-2026-31752","CVE-2026-43053","CVE-2026-43054","CVE-2026-43057","CVE-2026-43119","CVE-2026-43123","CVE-2026-43134","CVE-2026-43147","CVE-2026-43170","CVE-2026-43223","CVE-2026-43261","CVE-2026-43289","CVE-2026-43344","CVE-2026-43381","CVE-2026-43408","CVE-2026-43416","CVE-2026-43427","CVE-2026-43470","CVE-2026-43472","CVE-2026-43483","CVE-2026-43492"],"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\nscsi: target: Fix recursive locking in __configfs_open_file()\n\nIn flush_write_buffer, &p->frag_sem is acquired and then the loaded store\nfunction is called, which, here, is target_core_item_dbroot_store().  This\nfunction called filp_open(), following which these functions were called\n(in reverse order), according to the call trace:\n\n  down_read\n  __configfs_open_file\n  do_dentry_open\n  vfs_open\n  do_open\n  path_openat\n  do_filp_open\n  file_open_name\n  filp_open\n  target_core_item_dbroot_store\n  flush_write_buffer\n  configfs_write_iter\n\ntarget_core_item_dbroot_store() tries to validate the new file path by\ntrying to open the file path provided to it; however, in this case, the bug\nreport shows:\n\ndb_root: not a directory: /sys/kernel/config/target/dbroot\n\nindicating that the same configfs file was tried to be opened, on which it\nis currently working on. Thus, it is trying to acquire frag_sem semaphore\nof the same file of which it already holds the semaphore obtained in\nflush_write_buffer(), leading to acquiring the semaphore in a nested manner\nand a possibility of recursive locking.\n\nFix this by modifying target_core_item_dbroot_store() to use kern_path()\ninstead of filp_open() to avoid opening the file using filesystem-specific\nfunction __configfs_open_file(), and further modifying it to make this fix\ncompatible.(CVE-2026-23292)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nscsi: core: Fix refcount leak for tagset_refcnt\n\nThis leak will cause a hang when tearing down the SCSI host. For example,\niscsid hangs with the following call trace:\n\n[130120.652718] scsi_alloc_sdev: Allocation failure during SCSI scanning, some SCSI devices might not be configured\n\nPID: 2528     TASK: ffff9d0408974e00  CPU: 3    COMMAND: "iscsid"\n #0 [ffffb5b9c134b9e0] __schedule at ffffffff860657d4\n #1 [ffffb5b9c134ba28] schedule at ffffffff86065c6f\n #2 [ffffb5b9c134ba40] schedule_timeout at ffffffff86069fb0\n #3 [ffffb5b9c134bab0] __wait_for_common at ffffffff8606674f\n #4 [ffffb5b9c134bb10] scsi_remove_host at ffffffff85bfe84b\n #5 [ffffb5b9c134bb30] iscsi_sw_tcp_session_destroy at ffffffffc03031c4 [iscsi_tcp]\n #6 [ffffb5b9c134bb48] iscsi_if_recv_msg at ffffffffc0292692 [scsi_transport_iscsi]\n #7 [ffffb5b9c134bb98] iscsi_if_rx at ffffffffc02929c2 [scsi_transport_iscsi]\n #8 [ffffb5b9c134bbf0] netlink_unicast at ffffffff85e551d6\n #9 [ffffb5b9c134bc38] netlink_sendmsg at ffffffff85e554ef(CVE-2026-23296)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ni40e: Fix preempt count leak in napi poll tracepoint\n\nUsing get_cpu() in the tracepoint assignment causes an obvious preempt\ncount leak because nothing invokes put_cpu() to undo it:\n\n  softirq: huh, entered softirq 3 NET_RX with preempt_count 00000100, exited with 00000101?\n\nThis clearly has seen a lot of testing in the last 3+ years...\n\nUse smp_processor_id() instead.(CVE-2026-23313)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ndrm/vmwgfx: Return the correct value in vmw_translate_ptr functions\n\nBefore the referenced fixes these functions used a lookup function that\nreturned a pointer. This was changed to another lookup function that\nreturned an error code with the pointer becoming an out parameter.\n\nThe error path when the lookup failed was not changed to reflect this\nchange and the code continued to return the PTR_ERR of the now\nuninitialized pointer. This could cause the vmw_translate_ptr functions\nto return success when they actually failed causing further uninitialized\nand OOB accesses.(CVE-2026-23317)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nx86/efi: defer freeing of boot services memory\n\nefi_free_boot_services() frees memory occupied by EFI_BOOT_SERVICES_CODE\nand EFI_BOOT_SERVICES_DATA using memblock_free_late().\n\nThere are two issue with that: memblock_free_late() should be used for\nmemory allocated with memblock_alloc() while the memory reserved with\nmemblock_reserve() should be freed with free_reserved_area().\n\nMore acutely, with CONFIG_DEFERRED_STRUCT_PAGE_INIT=y\nefi_free_boot_services() is called before deferred initialization of the\nmemory map is complete.\n\nBenjamin Herrenschmidt reports that this causes a leak of ~140MB of\nRAM on EC2 t3a.nano instances which only have 512MB or RAM.\n\nIf the freed memory resides in the areas that memory map for them is\nstill uninitialized, they won't be actually freed because\nmemblock_free_late() calls memblock_free_pages() and the latter skips\nuninitialized pages.\n\nUsing free_reserved_area() at this point is also problematic because\n__free_page() accesses the buddy of the freed page and that again might\nend up in uninitialized part of the memory map.\n\nDelaying the entire efi_free_boot_services() could be problematic\nbecause in addition to freeing boot services memory it updates\nefi.memmap without any synchronization and that's undesirable late in\nboot when there is concurrency.\n\nMore robust approach is to only defer freeing of the EFI boot services\nmemory.\n\nSplit efi_free_boot_services() in two. First efi_unmap_boot_services()\ncollects ranges that should be freed into an array then\nefi_free_boot_services() later frees them after deferred init is complete.(CVE-2026-23352)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnvme: fix admin queue leak on controller reset\n\nWhen nvme_alloc_admin_tag_set() is called during a controller reset,\na previous admin queue may still exist. Release it properly before\nallocating a new one to avoid orphaning the old queue.\n\nThis fixes a regression introduced by commit 03b3bcd319b3 ("nvme: fix\nadmin request_queue lifetime").(CVE-2026-23360)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nblktrace: fix __this_cpu_read/write in preemptible context\n\ntracing_record_cmdline() internally uses __this_cpu_read() and\n__this_cpu_write() on the per-CPU variable trace_cmdline_save, and\ntrace_save_cmdline() explicitly asserts preemption is disabled via\nlockdep_assert_preemption_disabled(). These operations are only safe\nwhen preemption is off, as they were designed to be called from the\nscheduler context (probe_wakeup_sched_switch() / probe_wakeup()).\n\n__blk_add_trace() was calling tracing_record_cmdline(current) early in\nthe blk_tracer path, before ring buffer reservation, from process\ncontext where preemption is fully enabled. This triggers the following\nusing blktests/blktrace/002:\n\nblktrace/002 (blktrace ftrace corruption with sysfs trace)   [failed]\n    runtime  0.367s  ...  0.437s\n    something found in dmesg:\n    [   81.211018] run blktests blktrace/002 at 2026-02-25 22:24:33\n    [   81.239580] null_blk: disk nullb1 created\n    [   81.357294] BUG: using __this_cpu_read() in preemptible [00000000] code: dd/2516\n    [   81.362842] caller is tracing_record_cmdline+0x10/0x40\n    [   81.362872] CPU: 16 UID: 0 PID: 2516 Comm: dd Tainted: G                 N  7.0.0-rc1lblk+ #84 PREEMPT(full)\n    [   81.362877] Tainted: [N]=TEST\n    [   81.362878] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.17.0-0-gb52ca86e094d-prebuilt.qemu.org 04/01/2014\n    [   81.362881] Call Trace:\n    [   81.362884]  <TASK>\n    [   81.362886]  dump_stack_lvl+0x8d/0xb0\n    ...\n    (See '/mnt/sda/blktests/results/nodev/blktrace/002.dmesg' for the entire message)\n\n[   81.211018] run blktests blktrace/002 at 2026-02-25 22:24:33\n[   81.239580] null_blk: disk nullb1 created\n[   81.357294] BUG: using __this_cpu_read() in preemptible [00000000] code: dd/2516\n[   81.362842] caller is tracing_record_cmdline+0x10/0x40\n[   81.362872] CPU: 16 UID: 0 PID: 2516 Comm: dd Tainted: G                 N  7.0.0-rc1lblk+ #84 PREEMPT(full)\n[   81.362877] Tainted: [N]=TEST\n[   81.362878] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.17.0-0-gb52ca86e094d-prebuilt.qemu.org 04/01/2014\n[   81.362881] Call Trace:\n[   81.362884]  <TASK>\n[   81.362886]  dump_stack_lvl+0x8d/0xb0\n[   81.362895]  check_preemption_disabled+0xce/0xe0\n[   81.362902]  tracing_record_cmdline+0x10/0x40\n[   81.362923]  __blk_add_trace+0x307/0x5d0\n[   81.362934]  ? lock_acquire+0xe0/0x300\n[   81.362940]  ? iov_iter_extract_pages+0x101/0xa30\n[   81.362959]  blk_add_trace_bio+0x106/0x1e0\n[   81.362968]  submit_bio_noacct_nocheck+0x24b/0x3a0\n[   81.362979]  ? lockdep_init_map_type+0x58/0x260\n[   81.362988]  submit_bio_wait+0x56/0x90\n[   81.363009]  __blkdev_direct_IO_simple+0x16c/0x250\n[   81.363026]  ? __pfx_submit_bio_wait_endio+0x10/0x10\n[   81.363038]  ? rcu_read_lock_any_held+0x73/0xa0\n[   81.363051]  blkdev_read_iter+0xc1/0x140\n[   81.363059]  vfs_read+0x20b/0x330\n[   81.363083]  ksys_read+0x67/0xe0\n[   81.363090]  do_syscall_64+0xbf/0xf00\n[   81.363102]  entry_SYSCALL_64_after_hwframe+0x76/0x7e\n[   81.363106] RIP: 0033:0x7f281906029d\n[   81.363111] Code: 31 c0 e9 c6 fe ff ff 50 48 8d 3d 66 63 0a 00 e8 59 ff 01 00 66 0f 1f 84 00 00 00 00 00 80 3d 41 33 0e 00 00 74 17 31 c0 0f 05 <48> 3d 00 f0 ff ff 77 5b c3 66 2e 0f 1f 84 00 00 00 00 00 48 83 ec\n[   81.363113] RSP: 002b:00007ffca127dd48 EFLAGS: 00000246 ORIG_RAX: 0000000000000000\n[   81.363120] RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007f281906029d\n[   81.363122] RDX: 0000000000001000 RSI: 0000559f8bfae000 RDI: 0000000000000000\n[   81.363123] RBP: 0000000000001000 R08: 0000002863a10a81 R09: 00007f281915f000\n[   81.363124] R10: 00007f2818f77b60 R11: 0000000000000246 R12: 0000559f8bfae000\n[   81.363126] R13: 0000000000000000 R14: 0000000000000000 R15: 000000000000000a\n[   81.363142]  </TASK>\n\nThe same BUG fires from blk_add_trace_plug(), blk_add_trace_unplug(),\nand blk_add_trace_rq() paths as well.\n\nThe purpose of tracin\n---truncated---(CVE-2026-23374)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nbpf, arm64: Force 8-byte alignment for JIT buffer to prevent atomic tearing\n\nstruct bpf_plt contains a u64 target field. Currently, the BPF JIT\nallocator requests an alignment of 4 bytes (sizeof(u32)) for the JIT\nbuffer.\n\nBecause the base address of the JIT buffer can be 4-byte aligned (e.g.,\nending in 0x4 or 0xc), the relative padding logic in build_plt() fails\nto ensure that target lands on an 8-byte boundary.\n\nThis leads to two issues:\n1. UBSAN reports misaligned-access warnings when dereferencing the\n   structure.\n2. More critically, target is updated concurrently via WRITE_ONCE() in\n   bpf_arch_text_poke() while the JIT'd code executes ldr. On arm64,\n   64-bit loads/stores are only guaranteed to be single-copy atomic if\n   they are 64-bit aligned. A misaligned target risks a torn read,\n   causing the JIT to jump to a corrupted address.\n\nFix this by increasing the allocation alignment requirement to 8 bytes\n(sizeof(u64)) in bpf_jit_binary_pack_alloc(). This anchors the base of\nthe JIT buffer to an 8-byte boundary, allowing the relative padding math\nin build_plt() to correctly align the target field.(CVE-2026-23383)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nudp: Fix wildcard bind conflict check when using hash2\n\nWhen binding a udp_sock to a local address and port, UDP uses\ntwo hashes (udptable->hash and udptable->hash2) for collision\ndetection. The current code switches to "hash2" when\nhslot->count > 10.\n\n"hash2" is keyed by local address and local port.\n"hash" is keyed by local port only.\n\nThe issue can be shown in the following bind sequence (pseudo code):\n\nbind(fd1,  "[fd00::1]:8888")\nbind(fd2,  "[fd00::2]:8888")\nbind(fd3,  "[fd00::3]:8888")\nbind(fd4,  "[fd00::4]:8888")\nbind(fd5,  "[fd00::5]:8888")\nbind(fd6,  "[fd00::6]:8888")\nbind(fd7,  "[fd00::7]:8888")\nbind(fd8,  "[fd00::8]:8888")\nbind(fd9,  "[fd00::9]:8888")\nbind(fd10, "[fd00::10]:8888")\n\n/* Correctly return -EADDRINUSE because "hash" is used\n * instead of "hash2". udp_lib_lport_inuse() detects the\n * conflict.\n */\nbind(fail_fd, "[::]:8888")\n\n/* After one more socket is bound to "[fd00::11]:8888",\n * hslot->count exceeds 10 and "hash2" is used instead.\n */\nbind(fd11, "[fd00::11]:8888")\nbind(fail_fd, "[::]:8888")      /* succeeds unexpectedly */\n\nThe same issue applies to the IPv4 wildcard address "0.0.0.0"\nand the IPv4-mapped wildcard address "::ffff:0.0.0.0". For\nexample, if there are existing sockets bound to\n"192.168.1.[1-11]:8888", then binding "0.0.0.0:8888" or\n"[::ffff:0.0.0.0]:8888" can also miss the conflict when\nhslot->count > 10.\n\nTCP inet_csk_get_port() already has the correct check in\ninet_use_bhash2_on_bind(). Rename it to\ninet_use_hash2_on_bind() and move it to inet_hashtables.h\nso udp.c can reuse it in this fix.(CVE-2026-31503)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nbridge: br_nd_send: validate ND option lengths\n\nbr_nd_send() walks ND options according to option-provided lengths.\nA malformed option can make the parser advance beyond the computed\noption span or use a too-short source LLADDR option payload.\n\nValidate option lengths against the remaining NS option area before\nadvancing, and only read source LLADDR when the option is large enough\nfor an Ethernet address.(CVE-2026-31752)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nxfs: close crash window in attr dabtree inactivation\n\nWhen inactivating an inode with node-format extended attributes,\nxfs_attr3_node_inactive() invalidates all child leaf/node blocks via\nxfs_trans_binval(), but intentionally does not remove the corresponding\nentries from their parent node blocks.  The implicit assumption is that\nxfs_attr_inactive() will truncate the entire attr fork to zero extents\nafterwards, so log recovery will never reach the root node and follow\nthose stale pointers.\n\nHowever, if a log shutdown occurs after the leaf/node block cancellations\ncommit but before the attr bmap truncation commits, this assumption\nbreaks.  Recovery replays the attr bmap intact (the inode still has\nattr fork extents), but suppresses replay of all cancelled leaf/node\nblocks, maybe leaving them as stale data on disk.  On the next mount,\nxlog_recover_process_iunlinks() retries inactivation and attempts to\nread the root node via the attr bmap. If the root node was not replayed,\nreading the unreplayed root block triggers a metadata verification\nfailure immediately; if it was replayed, following its child pointers\nto unreplayed child blocks triggers the same failure:\n\n XFS (pmem0): Metadata corruption detected at\n xfs_da3_node_read_verify+0x53/0x220, xfs_da3_node block 0x78\n XFS (pmem0): Unmount and run xfs_repair\n XFS (pmem0): First 128 bytes of corrupted metadata buffer:\n 00000000: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................\n 00000010: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................\n 00000020: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................\n 00000030: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................\n 00000040: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................\n 00000050: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................\n 00000060: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................\n 00000070: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................\n XFS (pmem0): metadata I/O error in "xfs_da_read_buf+0x104/0x190" at daddr 0x78 len 8 error 117\n\nFix this in two places:\n\nIn xfs_attr3_node_inactive(), after calling xfs_trans_binval() on a\nchild block, immediately remove the entry that references it from the\nparent node in the same transaction.  This eliminates the window where\nthe parent holds a pointer to a cancelled block.  Once all children are\nremoved, the now-empty root node is converted to a leaf block within the\nsame transaction. This node-to-leaf conversion is necessary for crash\nsafety. If the system shutdown after the empty node is written to the\nlog but before the second-phase bmap truncation commits, log recovery\nwill attempt to verify the root block on disk. xfs_da3_node_verify()\ndoes not permit a node block with count == 0; such a block will fail\nverification and trigger a metadata corruption shutdown. on the other\nhand, leaf blocks are allowed to have this transient state.\n\nIn xfs_attr_inactive(), split the attr fork truncation into two explicit\nphases.  First, truncate all extents beyond the root block (the child\nextents whose parent references have already been removed above).\nSecond, invalidate the root block and truncate the attr bmap to zero in\na single transaction.  The two operations in the second phase must be\natomic: as long as the attr bmap has any non-zero length, recovery can\nfollow it to the root block, so the root block invalidation must commit\ntogether with the bmap-to-zero truncation.(CVE-2026-43053)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nscsi: target: tcm_loop: Drain commands in target_reset handler\n\ntcm_loop_target_reset() violates the SCSI EH contract: it returns SUCCESS\nwithout draining any in-flight commands.  The SCSI EH documentation\n(scsi_eh.rst) requires that when a reset handler returns SUCCESS the driver\nhas made lower layers "forget about timed out scmds" and is ready for new\ncommands.  Every other SCSI LLD (virtio_scsi, mpt3sas, ipr, scsi_debug,\nmpi3mr) enforces this by draining or completing outstanding commands before\nreturning SUCCESS.\n\nBecause tcm_loop_target_reset() doesn't drain, the SCSI EH reuses in-flight\nscsi_cmnd structures for recovery commands (e.g. TUR) while the target core\nstill has async completion work queued for the old se_cmd.  The memset in\nqueuecommand zeroes se_lun and lun_ref_active, causing\ntransport_lun_remove_cmd() to skip its percpu_ref_put().  The leaked LUN\nreference prevents transport_clear_lun_ref() from completing, hanging\nconfigfs LUN unlink forever in D-state:\n\n  INFO: task rm:264 blocked for more than 122 seconds.\n  rm              D    0   264    258 0x00004000\n  Call Trace:\n   __schedule+0x3d0/0x8e0\n   schedule+0x36/0xf0\n   transport_clear_lun_ref+0x78/0x90 [target_core_mod]\n   core_tpg_remove_lun+0x28/0xb0 [target_core_mod]\n   target_fabric_port_unlink+0x50/0x60 [target_core_mod]\n   configfs_unlink+0x156/0x1f0 [configfs]\n   vfs_unlink+0x109/0x290\n   do_unlinkat+0x1d5/0x2d0\n\nFix this by making tcm_loop_target_reset() actually drain commands:\n\n 1. Issue TMR_LUN_RESET via tcm_loop_issue_tmr() to drain all commands that\n    the target core knows about (those not yet CMD_T_COMPLETE).\n\n 2. Use blk_mq_tagset_busy_iter() to iterate all started requests and\n    flush_work() on each se_cmd — this drains any deferred completion work\n    for commands that already had CMD_T_COMPLETE set before the TMR (which\n    the TMR skips via __target_check_io_state()).  This is the same pattern\n    used by mpi3mr, scsi_debug, and libsas to drain outstanding commands\n    during reset.(CVE-2026-43054)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet: correctly handle tunneled traffic on IPV6_CSUM GSO fallback\n\nNETIF_F_IPV6_CSUM only advertises support for checksum offload of\npackets without IPv6 extension headers. Packets with extension\nheaders must fall back onto software checksumming. Since TSO\ndepends on checksum offload, those must revert to GSO.\n\nThe below commit introduces that fallback. It always checks\nnetwork header length. For tunneled packets, the inner header length\nmust be checked instead. Extend the check accordingly.\n\nA special case is tunneled packets without inner IP protocol. Such as\nRFC 6951 SCTP in UDP. Those are not standard IPv6 followed by\ntransport header either, so also must revert to the software GSO path.(CVE-2026-43057)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nBluetooth: hci_sync: annotate data-races around hdev->req_status\n\n__hci_cmd_sync_sk() sets hdev->req_status under hdev->req_lock:\n\n    hdev->req_status = HCI_REQ_PEND;\n\nHowever, several other functions read or write hdev->req_status without\nholding any lock:\n\n  - hci_send_cmd_sync() reads req_status in hci_cmd_work (workqueue)\n  - hci_cmd_sync_complete() reads/writes from HCI event completion\n  - hci_cmd_sync_cancel() / hci_cmd_sync_cancel_sync() read/write\n  - hci_abort_conn() reads in connection abort path\n\nSince __hci_cmd_sync_sk() runs on hdev->req_workqueue while\nhci_send_cmd_sync() runs on hdev->workqueue, these are different\nworkqueues that can execute concurrently on different CPUs. The plain\nC accesses constitute a data race.\n\nAdd READ_ONCE()/WRITE_ONCE() annotations on all concurrent accesses\nto hdev->req_status to prevent potential compiler optimizations that\ncould affect correctness (e.g., load fusing in the wait_event\ncondition or store reordering).(CVE-2026-43119)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nfbcon: check return value of con2fb_acquire_newinfo()\n\nIf fbcon_open() fails when called from con2fb_acquire_newinfo() then\ninfo->fbcon_par pointer remains NULL which is later dereferenced.\n\nAdd check for return value of the function con2fb_acquire_newinfo() to\navoid it.\n\nFound by Linux Verification Center (linuxtesting.org) with SVACE.(CVE-2026-43123)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nBluetooth: L2CAP: Fix missing key size check for L2CAP_LE_CONN_REQ\n\nThis adds a check for encryption key size upon receiving\nL2CAP_LE_CONN_REQ which is required by L2CAP/LE/CFC/BV-15-C which\nexpects L2CAP_CR_LE_BAD_KEY_SIZE.(CVE-2026-43134)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nRevert "PCI/IOV: Add PCI rescan-remove locking when enabling/disabling SR-IOV"\n\nThis reverts commit 05703271c3cd ("PCI/IOV: Add PCI rescan-remove locking\nwhen enabling/disabling SR-IOV"), which causes a deadlock by recursively\ntaking pci_rescan_remove_lock when sriov_del_vfs() is called as part of\npci_stop_and_remove_bus_device(). For example with the following sequence\nof commands:\n\n  $ echo <NUM> > /sys/bus/pci/devices/<pf>/sriov_numvfs\n  $ echo 1 > /sys/bus/pci/devices/<pf>/remove\n\nA trimmed trace of the deadlock on a mlx5 device is as below:\n\n  zsh/5715 is trying to acquire lock:\n  000002597926ef50 (pci_rescan_remove_lock){+.+.}-{3:3}, at: sriov_disable+0x34/0x140\n\n  but task is already holding lock:\n  000002597926ef50 (pci_rescan_remove_lock){+.+.}-{3:3}, at: pci_stop_and_remove_bus_device_locked+0x24/0x80\n  ...\n  Call Trace:\n   [<00000259778c4f90>] dump_stack_lvl+0xc0/0x110\n   [<00000259779c844e>] print_deadlock_bug+0x31e/0x330\n   [<00000259779c1908>] __lock_acquire+0x16c8/0x32f0\n   [<00000259779bffac>] lock_acquire+0x14c/0x350\n   [<00000259789643a6>] __mutex_lock_common+0xe6/0x1520\n   [<000002597896413c>] mutex_lock_nested+0x3c/0x50\n   [<00000259784a07e4>] sriov_disable+0x34/0x140\n   [<00000258f7d6dd80>] mlx5_sriov_disable+0x50/0x80 [mlx5_core]\n   [<00000258f7d5745e>] remove_one+0x5e/0xf0 [mlx5_core]\n   [<00000259784857fc>] pci_device_remove+0x3c/0xa0\n   [<000002597851012e>] device_release_driver_internal+0x18e/0x280\n   [<000002597847ae22>] pci_stop_bus_device+0x82/0xa0\n   [<000002597847afce>] pci_stop_and_remove_bus_device_locked+0x5e/0x80\n   [<00000259784972c2>] remove_store+0x72/0x90\n   [<0000025977e6661a>] kernfs_fop_write_iter+0x15a/0x200\n   [<0000025977d7241c>] vfs_write+0x24c/0x300\n   [<0000025977d72696>] ksys_write+0x86/0x110\n   [<000002597895b61c>] __do_syscall+0x14c/0x400\n   [<000002597896e0ee>] system_call+0x6e/0x90\n\nThis alone is not a complete fix as it restores the issue the cited commit\ntried to solve. A new fix will be provided as a follow on.(CVE-2026-43147)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nusb: dwc3: gadget: Move vbus draw to workqueue context\n\nCurrently dwc3_gadget_vbus_draw() can be called from atomic\ncontext, which in turn invokes power-supply-core APIs. And\nsome these PMIC APIs have operations that may sleep, leading\nto kernel panic.\n\nFix this by moving the vbus_draw into a workqueue context.(CVE-2026-43170)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nmedia: pvrusb2: fix URB leak in pvr2_send_request_ex\n\nWhen pvr2_send_request_ex() submits a write URB successfully but fails to\nsubmit the read URB (e.g. returns -ENOMEM), it returns immediately without\nwaiting for the write URB to complete. Since the driver reuses the same\nURB structure, a subsequent call to pvr2_send_request_ex() attempts to\nsubmit the still-active write URB, triggering a 'URB submitted while\nactive' warning in usb_submit_urb().\n\nFix this by ensuring the write URB is unlinked and waited upon if the read\nURB submission fails.(CVE-2026-43223)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\narm64: Add support for TSV110 Spectre-BHB mitigation\n\nThe TSV110 processor is vulnerable to the Spectre-BHB (Branch History\nBuffer) attack, which can be exploited to leak information through\nbranch prediction side channels. This commit adds the MIDR of TSV110\nto the list for software mitigation.(CVE-2026-43261)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nkexec: derive purgatory entry from symbol\n\nkexec_load_purgatory() derives image->start by locating e_entry inside an\nSHF_EXECINSTR section.  If the purgatory object contains multiple\nexecutable sections with overlapping sh_addr, the entrypoint check can\nmatch more than once and trigger a WARN.\n\nDerive the entry section from the purgatory_start symbol when present and\ncompute image->start from its final placement.  Keep the existing e_entry\nfallback for purgatories that do not expose the symbol.\n\nWARNING: kernel/kexec_file.c:1009 at kexec_load_purgatory+0x395/0x3c0, CPU#10: kexec/1784\nCall Trace:\n <TASK>\n bzImage64_load+0x133/0xa00\n __do_sys_kexec_file_load+0x2b3/0x5c0\n do_syscall_64+0x81/0x610\n entry_SYSCALL_64_after_hwframe+0x76/0x7e\n\n[(CVE-2026-43289)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nperf/x86/intel/uncore: Fix die ID init and look up bugs\n\nIn snbep_pci2phy_map_init(), in the nr_node_ids > 8 path,\nuncore_device_to_die() may return -1 when all CPUs associated\nwith the UBOX device are offline.\n\nRemove the WARN_ON_ONCE(die_id == -1) check for two reasons:\n\n- The current code breaks out of the loop. This is incorrect because\n  pci_get_device() does not guarantee iteration in domain or bus order,\n  so additional UBOX devices may be skipped during the scan.\n\n- Returning -EINVAL is incorrect, since marking offline buses with\n  die_id == -1 is expected and should not be treated as an error.\n\nSeparately, when NUMA is disabled on a NUMA-capable platform,\npcibus_to_node() returns NUMA_NO_NODE, causing uncore_device_to_die()\nto return -1 for all PCI devices.  As a result,\nspr_update_device_location(), used on Intel SPR and EMR, ignores the\ncorresponding PMON units and does not add them to the RB tree.\n\nFix this by using uncore_pcibus_to_dieid(), which retrieves topology\nfrom the UBOX GIDNIDMAP register and works regardless of whether NUMA\nis enabled in Linux.  This requires snbep_pci2phy_map_init() to be\nadded in spr_uncore_pci_init().\n\nKeep uncore_device_to_die() only for the nr_node_ids > 8 case, where\nNUMA is expected to be enabled.(CVE-2026-43344)\n\nThe Linux kernel Nouveau graphics driver has a race condition/null pointer dereference issue in DPCD (DisplayPort Configuration Data) AUX channel transmission processing. When the GPU device enters the suspend state due to runtime power management (runtime PM), if the user space program (such as through the /dev/drm_dp_ interface) attempts to initiate an AUX transfer request, the driver will try to access the GSP (Graphics System Processor) firmware code of the suspended device, causing the kernel to crash.(CVE-2026-43381)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nceph: add a bunch of missing ceph_path_info initializers\n\nceph_mdsc_build_path() must be called with a zero-initialized\nceph_path_info parameter, or else the following\nceph_mdsc_free_path_info() may crash.\n\nExample crash (on Linux 6.18.12):\n\n  virt_to_cache: Object is not a Slab page!\n  WARNING: CPU: 184 PID: 2871736 at mm/slub.c:6732 kmem_cache_free+0x316/0x400\n  [...]\n  Call Trace:\n   [...]\n   ceph_open+0x13d/0x3e0\n   do_dentry_open+0x134/0x480\n   vfs_open+0x2a/0xe0\n   path_openat+0x9a3/0x1160\n  [...]\n  cache_from_obj: Wrong slab cache. names_cache but object is from ceph_inode_info\n  WARNING: CPU: 184 PID: 2871736 at mm/slub.c:6746 kmem_cache_free+0x2dd/0x400\n  [...]\n  kernel BUG at mm/slub.c:634!\n  Oops: invalid opcode: 0000 [#1] SMP NOPTI\n  RIP: 0010:__slab_free+0x1a4/0x350\n\nSome of the ceph_mdsc_build_path() callers had initializers, but\nothers had not, even though they were all added by commit 15f519e9f883\n("ceph: fix race condition validating r_parent before applying state").\nThe ones without initializer are suspectible to random crashes.  (I can\nimagine it could even be possible to exploit this bug to elevate\nprivileges.)\n\nUnfortunately, these Ceph functions are undocumented and its semantics\ncan only be derived from the code.  I see that ceph_mdsc_build_path()\ninitializes the structure only on success, but not on error.\n\nCalling ceph_mdsc_free_path_info() after a failed\nceph_mdsc_build_path() call does not even make sense, but that's what\nall callers do, and for it to be safe, the structure must be\nzero-initialized.  The least intrusive approach to fix this is\ntherefore to add initializers everywhere.(CVE-2026-43408)\n\nIn the Linux kernel, the following vulnerability has been resolved: powerpc, perf: Check that current->mm is alive before getting user callchain. It may happen that mm is already released, which leads to kernel panic. This adds the NULL check for current->mm, similarly to commit 20afc60f892d ("x86, perf: Check that current->mm is alive before getting user callchain"). I was getting this panic when running a profiling BPF program (profile.py from bcc-tools). In addition, move storing the top-level stack entry to generic perf_callchain_user to make sure the top-level entry is always captured, even if current->mm is NULL.(CVE-2026-43416)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nusb: class: cdc-wdm: fix reordering issue in read code path\n\nQuoting the bug report:\n\nDue to compiler optimization or CPU out-of-order execution, the\ndesc->length update can be reordered before the memmove. If this\nhappens, wdm_read() can see the new length and call copy_to_user() on\nuninitialized memory. This also violates LKMM data race rules [1].\n\nFix it by using WRITE_ONCE and memory barriers.(CVE-2026-43427)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnfs: return EISDIR on nfs3_proc_create if d_alias is a dir\n\nIf we found an alias through nfs3_do_create/nfs_add_or_obtain\n/d_splice_alias which happens to be a dir dentry, we don't return\nany error, and simply forget about this alias, but the original\ndentry we were adding and passed as parameter remains negative.\n\nThis later causes an oops on nfs_atomic_open_v23/finish_open since we\nsupply a negative dentry to do_dentry_open.\n\nThis has been observed running lustre-racer, where dirs and files are\ncreated/removed concurrently with the same name and O_EXCL is not\nused to open files (frequent file redirection).\n\nWhile d_splice_alias typically returns a directory alias or NULL, we\nexplicitly check d_is_dir() to ensure that we don't attempt to perform\nfile operations (like finish_open) on a directory inode, which triggers\nthe observed oops.(CVE-2026-43470)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nunshare: fix unshare_fs() handling\n\nThere's an unpleasant corner case in unshare(2), when we have a\nCLONE_NEWNS in flags and current->fs hadn't been shared at all; in that\ncase copy_mnt_ns() gets passed current->fs instead of a private copy,\nwhich causes interesting warts in proof of correctness]\n\n> I guess if private means fs->users == 1, the condition could still be true.\n\nUnfortunately, it's worse than just a convoluted proof of correctness.\nConsider the case when we have CLONE_NEWCGROUP in addition to CLONE_NEWNS\n(and current->fs->users == 1).\n\nWe pass current->fs to copy_mnt_ns(), all right.  Suppose it succeeds and\nflips current->fs->{pwd,root} to corresponding locations in the new namespace.\nNow we proceed to copy_cgroup_ns(), which fails (e.g. with -ENOMEM).\nWe call put_mnt_ns() on the namespace created by copy_mnt_ns(), it's\ndestroyed and its mount tree is dissolved, but...  current->fs->root and\ncurrent->fs->pwd are both left pointing to now detached mounts.\n\nThey are pinning those, so it's not a UAF, but it leaves the calling\nprocess with unshare(2) failing with -ENOMEM _and_ leaving it with\npwd and root on detached isolated mounts.  The last part is clearly a bug.\n\nThere is other fun related to that mess (races with pivot_root(), including\nthe one between pivot_root() and fork(), of all things), but this one\nis easy to isolate and fix - treat CLONE_NEWNS as "allocate a new\nfs_struct even if it hadn't been shared in the first place".  Sure, we could\ngo for something like "if both CLONE_NEWNS *and* one of the things that might\nend up failing after copy_mnt_ns() call in create_new_namespaces() are set,\nforce allocation of new fs_struct", but let's keep it simple - the cost\nof copy_fs_struct() is trivial.\n\nAnother benefit is that copy_mnt_ns() with CLONE_NEWNS *always* gets\na freshly allocated fs_struct, yet to be attached to anything.  That\nseriously simplifies the analysis...\n\nFWIW, that bug had been there since the introduction of unshare(2) ;-/(CVE-2026-43472)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nKVM: SVM: Set/clear CR8 write interception when AVIC is (de)activated\n\nExplicitly set/clear CR8 write interception when AVIC is (de)activated to\nfix a bug where KVM leaves the interception enabled after AVIC is\nactivated.  E.g. if KVM emulates INIT=>WFS while AVIC is deactivated, CR8\nwill remain intercepted in perpetuity.\n\nOn its own, the dangling CR8 intercept is "just" a performance issue, but\ncombined with the TPR sync bug fixed by commit d02e48830e3f ("KVM: SVM:\nSync TPR from LAPIC into VMCB::V_TPR even if AVIC is active"), the danging\nintercept is fatal to Windows guests as the TPR seen by hardware gets\nwildly out of sync with reality.\n\nNote, VMX isn't affected by the bug as TPR_THRESHOLD is explicitly ignored\nwhen Virtual Interrupt Delivery is enabled, i.e. when APICv is active in\nKVM's world.  I.e. there's no need to trigger update_cr8_intercept(), this\nis firmly an SVM implementation flaw/detail.\n\nWARN if KVM gets a CR8 write #VMEXIT while AVIC is active, as KVM should\nnever enter the guest with AVIC enabled and CR8 writes intercepted.\n\n[Squash fix to avic_deactivate_vmcb. - Paolo](CVE-2026-43483)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nlib/crypto: mpi: Fix integer underflow in mpi_read_raw_from_sgl()\n\nYiming reports an integer underflow in mpi_read_raw_from_sgl() when\nsubtracting "lzeros" from the unsigned "nbytes".\n\nFor this to happen, the scatterlist "sgl" needs to occupy more bytes\nthan the "nbytes" parameter and the first "nbytes + 1" bytes of the\nscatterlist must be zero.  Under these conditions, the while loop\niterating over the scatterlist will count more zeroes than "nbytes",\nsubtract the number of zeroes from "nbytes" and cause the underflow.\n\nWhen commit 2d4d1eea540b ("lib/mpi: Add mpi sgl helpers") originally\nintroduced the bug, it couldn't be triggered because all callers of\nmpi_read_raw_from_sgl() passed a scatterlist whose length was equal to\n"nbytes".\n\nHowever since commit 63ba4d67594a ("KEYS: asymmetric: Use new crypto\ninterface without scatterlists"), the underflow can now actually be\ntriggered.  When invoking a KEYCTL_PKEY_ENCRYPT system call with a\nlarger "out_len" than "in_len" and filling the "in" buffer with zeroes,\ncrypto_akcipher_sync_prep() will create an all-zero scatterlist used for\nboth the "src" and "dst" member of struct akcipher_request and thereby\nfulfil the conditions to trigger the bug:\n\n  sys_keyctl()\n    keyctl_pkey_e_d_s()\n      asymmetric_key_eds_op()\n        software_key_eds_op()\n          crypto_akcipher_sync_encrypt()\n            crypto_akcipher_sync_prep()\n              crypto_akcipher_encrypt()\n                rsa_enc()\n                  mpi_read_raw_from_sgl()\n\nTo the user this will be visible as a DoS as the kernel spins forever,\ncausing soft lockup splats as a side effect.\n\nFix it.(CVE-2026-43492)","affected":[{"package":{"ecosystem":"openEuler:24.03-LTS","name":"kernel","purl":"pkg:rpm/openEuler/kernel&distro=openEuler-24.03-LTS"},"ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"6.6.0-145.0.13.139.oe2403"}]}],"ecosystem_specific":{"aarch64":["bpftool-6.6.0-145.0.13.139.oe2403.aarch64.rpm","bpftool-debuginfo-6.6.0-145.0.13.139.oe2403.aarch64.rpm","kernel-6.6.0-145.0.13.139.oe2403.aarch64.rpm","kernel-debuginfo-6.6.0-145.0.13.139.oe2403.aarch64.rpm","kernel-debugsource-6.6.0-145.0.13.139.oe2403.aarch64.rpm","kernel-devel-6.6.0-145.0.13.139.oe2403.aarch64.rpm","kernel-headers-6.6.0-145.0.13.139.oe2403.aarch64.rpm","kernel-source-6.6.0-145.0.13.139.oe2403.aarch64.rpm","kernel-tools-6.6.0-145.0.13.139.oe2403.aarch64.rpm","kernel-tools-debuginfo-6.6.0-145.0.13.139.oe2403.aarch64.rpm","kernel-tools-devel-6.6.0-145.0.13.139.oe2403.aarch64.rpm","perf-6.6.0-145.0.13.139.oe2403.aarch64.rpm","perf-debuginfo-6.6.0-145.0.13.139.oe2403.aarch64.rpm","python3-perf-6.6.0-145.0.13.139.oe2403.aarch64.rpm","python3-perf-debuginfo-6.6.0-145.0.13.139.oe2403.aarch64.rpm"],"src":["kernel-6.6.0-145.0.13.139.oe2403.src.rpm"],"x86_64":["bpftool-6.6.0-145.0.13.139.oe2403.x86_64.rpm","bpftool-debuginfo-6.6.0-145.0.13.139.oe2403.x86_64.rpm","kernel-6.6.0-145.0.13.139.oe2403.x86_64.rpm","kernel-debuginfo-6.6.0-145.0.13.139.oe2403.x86_64.rpm","kernel-debugsource-6.6.0-145.0.13.139.oe2403.x86_64.rpm","kernel-devel-6.6.0-145.0.13.139.oe2403.x86_64.rpm","kernel-headers-6.6.0-145.0.13.139.oe2403.x86_64.rpm","kernel-source-6.6.0-145.0.13.139.oe2403.x86_64.rpm","kernel-tools-6.6.0-145.0.13.139.oe2403.x86_64.rpm","kernel-tools-debuginfo-6.6.0-145.0.13.139.oe2403.x86_64.rpm","kernel-tools-devel-6.6.0-145.0.13.139.oe2403.x86_64.rpm","perf-6.6.0-145.0.13.139.oe2403.x86_64.rpm","perf-debuginfo-6.6.0-145.0.13.139.oe2403.x86_64.rpm","python3-perf-6.6.0-145.0.13.139.oe2403.x86_64.rpm","python3-perf-debuginfo-6.6.0-145.0.13.139.oe2403.x86_64.rpm"]}}],"references":[{"type":"ADVISORY","url":"https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2026-2493"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-23292"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-23296"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-23313"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-23317"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-23352"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-23360"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-23374"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-23383"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-31503"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-31752"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-43053"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-43054"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-43057"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-43119"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-43123"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-43134"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-43147"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-43170"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-43223"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-43261"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-43289"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-43344"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-43381"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-43408"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-43416"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-43427"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-43470"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-43472"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-43483"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-43492"}],"database_specific":{"severity":"High"}}