{"id":"OESA-2026-3704","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: hns3: add VLAN id validation before using\n\nCurrently, the VLAN id may be used without validation when\nreceive a VLAN configuration mailbox from VF. The length of\nvlan_del_fail_bmap is BITS_TO_LONGS(VLAN_N_VID). It may cause\nout-of-bounds memory access once the VLAN id is bigger than\nor equal to VLAN_N_VID.\n\nTherefore, VLAN id needs to be checked to ensure it is within\nthe range of VLAN_N_VID.(CVE-2025-71112)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\next4: fix string copying in parse_apply_sb_mount_options()\n\nstrscpy_pad() can't be used to copy a non-NUL-term string into a NUL-term\nstring of possibly bigger size.  Commit 0efc5990bca5 ("string.h: Introduce\nmemtostr() and memtostr_pad()") provides additional information in that\nregard.  So if this happens, the following warning is observed:\n\nstrnlen: detected buffer overflow: 65 byte read of buffer size 64\nWARNING: CPU: 0 PID: 28655 at lib/string_helpers.c:1032 __fortify_report+0x96/0xc0 lib/string_helpers.c:1032\nModules linked in:\nCPU: 0 UID: 0 PID: 28655 Comm: syz-executor.3 Not tainted 6.12.54-syzkaller-00144-g5f0270f1ba00 #0\nHardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014\nRIP: 0010:__fortify_report+0x96/0xc0 lib/string_helpers.c:1032\nCall Trace:\n <TASK>\n __fortify_panic+0x1f/0x30 lib/string_helpers.c:1039\n strnlen include/linux/fortify-string.h:235 [inline]\n sized_strscpy include/linux/fortify-string.h:309 [inline]\n parse_apply_sb_mount_options fs/ext4/super.c:2504 [inline]\n __ext4_fill_super fs/ext4/super.c:5261 [inline]\n ext4_fill_super+0x3c35/0xad00 fs/ext4/super.c:5706\n get_tree_bdev_flags+0x387/0x620 fs/super.c:1636\n vfs_get_tree+0x93/0x380 fs/super.c:1814\n do_new_mount fs/namespace.c:3553 [inline]\n path_mount+0x6ae/0x1f70 fs/namespace.c:3880\n do_mount fs/namespace.c:3893 [inline]\n __do_sys_mount fs/namespace.c:4103 [inline]\n __se_sys_mount fs/namespace.c:4080 [inline]\n __x64_sys_mount+0x280/0x300 fs/namespace.c:4080\n do_syscall_x64 arch/x86/entry/common.c:52 [inline]\n do_syscall_64+0x64/0x140 arch/x86/entry/common.c:83\n entry_SYSCALL_64_after_hwframe+0x76/0x7e\n\nSince userspace is expected to provide s_mount_opts field to be at most 63\ncharacters long with the ending byte being NUL-term, use a 64-byte buffer\nwhich matches the size of s_mount_opts, so that strscpy_pad() does its job\nproperly.  Return with error if the user still managed to provide a\nnon-NUL-term string here.\n\nFound by Linux Verification Center (linuxtesting.org) with Syzkaller.(CVE-2025-71123)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nRDMA/umad: Reject negative data_len in ib_umad_write\n\nib_umad_write computes data_len from user-controlled count and the\nMAD header sizes. With a mismatched user MAD header size and RMPP\nheader length, data_len can become negative and reach ib_create_send_mad().\nThis can make the padding calculation exceed the segment size and trigger\nan out-of-bounds memset in alloc_send_rmpp_list().\n\nAdd an explicit check to reject negative data_len before creating the\nsend buffer.\n\nKASAN splat:\n[  211.363464] BUG: KASAN: slab-out-of-bounds in ib_create_send_mad+0xa01/0x11b0\n[  211.364077] Write of size 220 at addr ffff88800c3fa1f8 by task spray_thread/102\n[  211.365867] ib_create_send_mad+0xa01/0x11b0\n[  211.365887] ib_umad_write+0x853/0x1c80(CVE-2026-23243)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnvme: fix memory allocation in nvme_pr_read_keys()\n\nnvme_pr_read_keys() takes num_keys from userspace and uses it to\ncalculate the allocation size for rse via struct_size(). The upper\nlimit is PR_KEYS_MAX (64K).\n\nA malicious or buggy userspace can pass a large num_keys value that\nresults in a 4MB allocation attempt at most, causing a warning in\nthe page allocator when the order exceeds MAX_PAGE_ORDER.\n\nTo fix this, use kvzalloc() instead of kzalloc().\n\nThis bug has the same reasoning and fix with the patch below:\nhttps://lore.kernel.org/linux-block/(CVE-2026-23244)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nmedia: dvb-core: fix wrong reinitialization of ringbuffer on reopen\n\ndvb_dvr_open() calls dvb_ringbuffer_init() when a new reader opens the\nDVR device.  dvb_ringbuffer_init() calls init_waitqueue_head(), which\nreinitializes the waitqueue list head to empty.\n\nSince dmxdev->dvr_buffer.queue is a shared waitqueue (all opens of the\nsame DVR device share it), this orphans any existing waitqueue entries\nfrom io_uring poll or epoll, leaving them with stale prev/next pointers\nwhile the list head is reset to {self, self}.\n\nThe waitqueue and spinlock in dvr_buffer are already properly\ninitialized once in dvb_dmxdev_init().  The open path only needs to\nreset the buffer data pointer, size, and read/write positions.\n\nReplace the dvb_ringbuffer_init() call in dvb_dvr_open() with direct\nassignment of data/size and a call to dvb_ringbuffer_reset(), which\nproperly resets pread, pwrite, and error with correct memory ordering\nwithout touching the waitqueue or spinlock.(CVE-2026-23253)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\napparmor: fix unprivileged local user can do privileged policy management\n\nAn unprivileged local user can load, replace, and remove profiles by\nopening the apparmorfs interfaces, via a confused deputy attack, by\npassing the opened fd to a privileged process, and getting the\nprivileged process to write to the interface.\n\nThis does require a privileged target that can be manipulated to do\nthe write for the unprivileged process, but once such access is\nachieved full policy management is possible and all the possible\nimplications that implies: removing confinement, DoS of system or\ntarget applications by denying all execution, by-passing the\nunprivileged user namespace restriction, to exploiting kernel bugs for\na local privilege escalation.\n\nThe policy management interface can not have its permissions simply\nchanged from 0666 to 0600 because non-root processes need to be able\nto load policy to different policy namespaces.\n\nInstead ensure the task writing the interface has privileges that\nare a subset of the task that opened the interface. This is already\ndone via policy for confined processes, but unconfined can delegate\naccess to the opened fd, by-passing the usual policy check.(CVE-2026-23268)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nperf: Fix __perf_event_overflow() vs perf_remove_from_context() race\n\nMake sure that __perf_event_overflow() runs with IRQs disabled for all\npossible callchains. Specifically the software events can end up running\nit with only preemption disabled.\n\nThis opens up a race vs perf_event_exit_event() and friends that will go\nand free various things the overflow path expects to be present, like\nthe BPF program.(CVE-2026-23271)\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\nbpf: Fix a UAF issue in bpf_trampoline_link_cgroup_shim\n\nThe root cause of this bug is that when 'bpf_link_put' reduces the\nrefcount of 'shim_link->link.link' to zero, the resource is considered\nreleased but may still be referenced via 'tr->progs_hlist' in\n'cgroup_shim_find'. The actual cleanup of 'tr->progs_hlist' in\n'bpf_shim_tramp_link_release' is deferred. During this window, another\nprocess can cause a use-after-free via 'bpf_trampoline_link_cgroup_shim'.\n\nBased on Martin KaFai Lau's suggestions, I have created a simple patch.\n\nTo fix this:\n   Add an atomic non-zero check in 'bpf_trampoline_link_cgroup_shim'.\n   Only increment the refcount if it is not already zero.\n\nTesting:\n   I verified the fix by adding a delay in\n   'bpf_shim_tramp_link_release' to make the bug easier to trigger:\n\nstatic void bpf_shim_tramp_link_release(struct bpf_link *link)\n{\n\t/* ... */\n\tif (!shim_link->trampoline)\n\t\treturn;\n\n+\tmsleep(100);\n\tWARN_ON_ONCE(bpf_trampoline_unlink_prog(&shim_link->link,\n\t\tshim_link->trampoline, NULL));\n\tbpf_trampoline_put(shim_link->trampoline);\n}\n\nBefore the patch, running a PoC easily reproduced the crash(almost 100%)\nwith a call trace similar to KaiyanM's report.\nAfter the patch, the bug no longer occurs even after millions of\niterations.(CVE-2026-23319)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nbpf: Fix stack-out-of-bounds write in devmap\n\nget_upper_ifindexes() iterates over all upper devices and writes their\nindices into an array without checking bounds.\n\nAlso the callers assume that the max number of upper devices is\nMAX_NEST_DEV and allocate excluded_devices[1+MAX_NEST_DEV] on the stack,\nbut that assumption is not correct and the number of upper devices could\nbe larger than MAX_NEST_DEV (e.g., many macvlans), causing a\nstack-out-of-bounds write.\n\nAdd a max parameter to get_upper_ifindexes() to avoid the issue.\nWhen there are too many upper devices, return -EOVERFLOW and abort the\nredirect.\n\nTo reproduce, create more than MAX_NEST_DEV(8) macvlans on a device with\nan XDP program attached using BPF_F_BROADCAST | BPF_F_EXCLUDE_INGRESS.\nThen send a packet to the device to trigger the XDP redirect path.(CVE-2026-23359)\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\nSquashfs: check metadata block offset is within range\n\nSyzkaller reports a "general protection fault in squashfs_copy_data"\n\nThis is ultimately caused by a corrupted index look-up table, which\nproduces a negative metadata block offset.\n\nThis is subsequently passed to squashfs_copy_data (via\nsquashfs_read_metadata) where the negative offset causes an out of bounds\naccess.\n\nThe fix is to check that the offset is within range in\nsquashfs_read_metadata.  This will trap this and other cases.(CVE-2026-23388)\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\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, the following vulnerability has been resolved:\n\nsched/fair: Clear rel_deadline when initializing forked entities\n\nA yield-triggered crash can happen when a newly forked sched_entity\nenters the fair class with se->rel_deadline unexpectedly set.\n\nThe failing sequence is:\n\n  1. A task is forked while se->rel_deadline is still set.\n  2. __sched_fork() initializes vruntime, vlag and other sched_entity\n     state, but does not clear rel_deadline.\n  3. On the first enqueue, enqueue_entity() calls place_entity().\n  4. Because se->rel_deadline is set, place_entity() treats se->deadline\n     as a relative deadline and converts it to an absolute deadline by\n     adding the current vruntime.\n  5. However, the forked entity's deadline is not a valid inherited\n     relative deadline for this new scheduling instance, so the conversion\n     produces an abnormally large deadline.\n  6. If the task later calls sched_yield(), yield_task_fair() advances\n     se->vruntime to se->deadline.\n  7. The inflated vruntime is then used by the following enqueue path,\n     where the vruntime-derived key can overflow when multiplied by the\n     entity weight.\n  8. This corrupts cfs_rq->sum_w_vruntime, breaks EEVDF eligibility\n     calculation, and can eventually make all entities appear ineligible.\n     pick_next_entity() may then return NULL unexpectedly, leading to a\n     later NULL dereference.\n\nA captured trace shows the effect clearly. Before yield, the entity's\nvruntime was around:\n\n  9834017729983308\n\nAfter yield_task_fair() executed:\n\n  se->vruntime = se->deadline\n\nthe vruntime jumped to:\n\n  19668035460670230\n\nand the deadline was later advanced further to:\n\n  19668035463470230\n\nThis shows that the deadline had already become abnormally large before\nyield_task_fair() copied it into vruntime.\n\nrel_deadline is only meaningful when se->deadline really carries a\nrelative deadline that still needs to be placed against vruntime. A\nfreshly forked sched_entity should not inherit or retain this state.\nClear se->rel_deadline in __sched_fork(), together with the other\nsched_entity runtime state, so that the first enqueue does not interpret\nthe new entity's deadline as a stale relative deadline.(CVE-2026-52980)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ncrypto: hisilicon/sec2 - prevent req used-after-free for sec\n\nDuring packet transmission, if the system is under heavy load,\nthe hardware might complete processing the packet and free the\nrequest memory (req) before the transmission function finishes.\nIf the software subsequently accesses this req, a use-after-free\nerror will occur. The qp_ctx memory exists throughout the packet\nsending process, so replace the req with the qp_ctx.(CVE-2026-53055)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nsctp: validate cached peer INIT chunk length in COOKIE_ECHO processing\n\nWhen a listening SCTP server processes a COOKIE_ECHO chunk, the cached\npeer INIT chunk embedded after the cookie is parsed and its parameters\nare later walked by sctp_process_init() using sctp_walk_params().\n\nHowever, the chunk header length of this cached INIT chunk was not\nvalidated against the remaining buffer in the COOKIE_ECHO payload. If\nthe length field is inflated, the parameter walk can run beyond the\nactual received data, leading to out-of-bounds reads and potential\nmemory corruption during later parameter handling (e.g. STATE_COOKIE\nprocessing and kmemdup() copies).\n\nAdd a bounds check in sctp_unpack_cookie() to ensure the cached INIT\nchunk length does not exceed the available data in the COOKIE_ECHO\nbuffer before it is used.(CVE-2026-53246)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nserial: 8250_dw: unregister 8250 port if clk_notifier_register() fails\n\ndw8250_probe() registers the 8250 port via serial8250_register_8250_port()\nand then, if the device has a clock, registers a clock notifier. If\nclk_notifier_register() fails, probe returns the error but leaves the\n8250 port registered. The matching serial8250_unregister_port() lives\nin dw8250_remove(), which is not called when probe fails, so the port\nslot stays occupied until the device is rebound or the system is\nrebooted. The devm-allocated driver data is freed while the port still\nreferences it (via the saved private_data and serial_in/serial_out\ncallbacks), so any access to that port slot before a rebind is a\nuse-after-free hazard.\n\nUnregister the port on the clk_notifier_register() error path.(CVE-2026-53384)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\npNFS: Fix use-after-free in pnfs_update_layout()\n\nWhen hitting the NFS_LAYOUT_RETURN branch in pnfs_update_layout(),\nthe code calls pnfs_prepare_to_retry_layoutget(lo). If it succeeds,\npnfs_put_layout_hdr(lo) is called before trace_pnfs_update_layout(),\nwhich still references 'lo'. This results in a use-after-free when the\ntracepoint accesses lo's fields.\n\nFix this by moving the tracepoint call before pnfs_put_layout_hdr(lo).(CVE-2026-63800)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet: skmsg: preserve sg.copy across SG transforms\n\nThe sk_msg sg.copy bitmap is part of the scatterlist entry ownership\nstate. A set bit tells sk_msg_compute_data_pointers() not to expose the\nentry through writable BPF ctx->data. This protects entries backed by\npages that are not private to the sk_msg, such as splice-backed file\npage-cache pages.\n\nSeveral sk_msg transform paths move, copy, split, or compact\nmsg->sg.data[] entries without moving the matching sg.copy bit. This can\nmake an externally backed entry arrive at a new slot with a clear copy\nbit. A later SK_MSG verdict can then expose sg_virt(sge) as writable\nctx->data and BPF stores can modify the original page cache.\n\nKeep sg.copy synchronized with sg.data[] whenever entries are\ntransferred, shifted, split, or copied into a new sk_msg. Clear the bit\nwhen an entry is replaced by a newly allocated private page or freed.\nThis covers the BPF pull/push/pop helpers, sk_msg_shift_left/right(),\nsk_msg_xfer(), and tls_split_open_record(), including the partial tail\nentry created during TLS open-record splitting.(CVE-2026-63830)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nscsi: target: iscsi: Validate CHAP_R length before base64 decode\n\nchap_server_compute_hash() allocates client_digest as\nkzalloc(chap->digest_size) and then, for BASE64-encoded responses,\npasses chap_r directly to chap_base64_decode() without checking whether\nthe input length could produce more than digest_size bytes of output.\n\nchap_base64_decode() writes to the destination unconditionally as long\nas there is input to consume. With MAX_RESPONSE_LENGTH set to 128 and\nthe "0b" prefix stripped by extract_param(), up to 127 base64 characters\ncan reach the decoder. 127 characters decode to 95 bytes. For SHA-256\n(digest_size=32) this overflows client_digest by 63 bytes; for MD5\n(digest_size=16) the overflow is 79 bytes.\n\nThe length check at line 344 fires after the write has already happened.\n\nThe HEX branch in the same switch statement already validates the length\nup front. Apply the same approach to the BASE64 branch: strip trailing\nbase64 padding characters, then reject any input whose data length\nexceeds DIV_ROUND_UP(digest_size * 4, 3) before calling the decoder.\n\nStripping trailing '=' before the comparison handles both padded and\nunpadded encodings. chap_base64_decode() already returns early on '=',\nso the full original string is still passed to the decoder unchanged.\n\nThe mutual CHAP path decodes CHAP_C into initiatorchg_binhex, which is\nkzalloc(CHAP_CHALLENGE_STR_LEN). extract_param() caps initiatorchg at\nCHAP_CHALLENGE_STR_LEN characters, so at most CHAP_CHALLENGE_STR_LEN-1\nbase64 characters reach the decoder. The maximum decoded size,\nDIV_ROUND_UP((CHAP_CHALLENGE_STR_LEN-1) * 3, 4), is less than\nCHAP_CHALLENGE_STR_LEN, so no overflow is possible there. A comment is\nadded at the call site to document this.(CVE-2026-63886)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nscsi: target: iscsi: Bound iscsi_encode_text_output() appends to rsp_buf\n\niscsi_encode_text_output() concatenates "key=value\\0" records into\nlogin->rsp_buf, an 8192-byte kzalloc(MAX_KEY_VALUE_PAIRS) buffer\nallocated in iscsit_alloc_login_setup_buffer(). The three sprintf() call\nsites in this function (lines 1398, 1411, 1424 in v7.1-rc2) never check\nthe remaining buffer capacity:\n\n\t*length += sprintf(output_buf, "%s=%s", er->key, er->value);\n\t*length += 1;\n\toutput_buf = textbuf + *length;\n\nThe 8192-byte ceiling at iscsi_target_check_login_request() bounds the\n*input* Login PDU payload, but a single PDU can carry up to 2048 minimal\nfour-byte "a=b\\0" pairs, each unknown key expanding to a 16-byte\n"a=NotUnderstood\\0" output record via iscsi_add_notunderstood_response().\n2048 * 16 = 32 KiB of output into an 8 KiB buffer, producing a ~24 KiB\nheap overrun in the kmalloc-8k slab.\n\nThe fix introduces a static iscsi_encode_text_record() helper that uses\nsnprintf() with a per-call bounds check against the remaining buffer,\nand threads a u32 textbuf_size parameter through\niscsi_encode_text_output(). Both call sites in\niscsi_target_handle_csg_zero() (PHASE_SECURITY) and\niscsi_target_handle_csg_one() (PHASE_OPERATIONAL) pass\nMAX_KEY_VALUE_PAIRS. On overflow the encoder logs the condition, calls\niscsi_release_extra_responses() to drop queued records, and returns -1;\nboth caller sites now emit ISCSI_STATUS_CLS_INITIATOR_ERR /\nISCSI_LOGIN_STATUS_INIT_ERR via iscsit_tx_login_rsp() before returning,\nso the initiator sees an explicit failed-login response rather than a\nsilent connection drop. (Prior to this patch only the PHASE_OPERATIONAL\ncaller did that; the PHASE_SECURITY caller is converted to the same\nshape.)(CVE-2026-63887)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nscsi: target: iscsi: Fix CRC overread and double-free in iscsit_handle_text_cmd()\n\nTwo latent bugs in the Text-phase handler, both present since the\noriginal LIO integration in commit e48354ce078c ("iscsi-target: Add\niSCSI fabric support for target v4.1"):\n\n1) DataDigest CRC buffer overread (4 bytes past text_in).\n\n   text_in is kzalloc()'d at ALIGN(payload_length, 4).  rx_size is then\n   incremented by ISCSI_CRC_LEN to make room for the received DataDigest\n   in the iovec, but the same (now-bumped) rx_size is passed as the\n   buffer length to iscsit_crc_buf():\n\n       if (conn->conn_ops->DataDigest) {\n               ...\n               rx_size += ISCSI_CRC_LEN;\n       }\n       ...\n       if (conn->conn_ops->DataDigest) {\n               data_crc = iscsit_crc_buf(text_in, rx_size, 0, NULL);\n\n   iscsit_crc_buf() walks rx_size bytes of text_in with crc32c(), so\n   when DataDigest is negotiated it reads 4 bytes past the end of the\n   text_in allocation.  KASAN reproduces this directly on the unpatched\n   mainline tree as slab-out-of-bounds in crc32c() called from the Text\n   PDU path.  The OOB bytes feed crc32c() and are then compared against\n   the initiator-supplied checksum, so the value does not flow back to\n   the attacker, but the kernel does read past the buffer on every Text\n   PDU with DataDigest=CRC32C.\n\n   Fix by passing the actual padded payload length\n   (ALIGN(payload_length, 4)) that was used for the kzalloc().\n\n2) Stale cmd->text_in_ptr re-free (double-free) on ERL>0 bad DataDigest\n   drop.\n\n   On DataDigest mismatch with ErrorRecoveryLevel > 0 the handler\n   silently drops the PDU and lets the initiator plug the CmdSN gap:\n\n               kfree(text_in);\n               return 0;\n\n   cmd->text_in_ptr still points at the freed buffer.  The next Text\n   Request on the same ITT re-enters iscsit_setup_text_cmd(), which\n   unconditionally does\n\n       kfree(cmd->text_in_ptr);\n       cmd->text_in_ptr = NULL;\n\n   freeing the same pointer a second time.  Session teardown via\n   iscsit_release_cmd() has the same shape and hits the same double-free\n   if the connection is dropped before a second Text Request arrives.\n\n   On an unmodified mainline tree the bug-1 CRC overread fires first on\n   the initial valid Text Request and perturbs the subsequent state, so\n   #4 was isolated by building a kernel with only the bug-1 hunk of this\n   patch applied plus temporary printk() observability around the three\n   relevant kfree() sites.  The observability prints are not part of\n   this patch.  On that build, a three-PDU Text Request sequence after\n   login produces two back-to-back splats:\n\n       BUG: KASAN: double-free in iscsit_setup_text_cmd+0x??\n       BUG: KASAN: double-free in iscsit_release_cmd+0x??\n\n   showing the same pointer freed in the ERL>0 drop path and again in\n   iscsit_setup_text_cmd() (next Text Request on the same ITT) and once\n   more in iscsit_release_cmd() (session teardown).  On distro kernels\n   with CONFIG_SLAB_FREELIST_HARDENED=y (default) the double-free\n   becomes a remote kernel BUG(); on non-hardened kernels it corrupts\n   the slab freelist.\n\n   Fix by clearing cmd->text_in_ptr after the kfree() in the ERL>0 drop\n   path.  With both hunks applied #4 is directly observable on the stock\n   tree without observability printks; fixing bug-1 alone would mask #4\n   less, not more, so the hunks are submitted together.\n\nBoth fixes are one-liners.  The Text PDU state machine is unchanged and\nthe wire protocol is unaffected.(CVE-2026-63888)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nscsi: scsi_transport_fc: Widen FPIN pname walker counter to u32\n\nAn adjacent Fibre Channel fabric actor that can deliver an FPIN ELS\nframe to an lpfc or qla2xxx Linux initiator can trigger a non-return in\nthe generic FC transport. This is not a local userspace or IP network\npath; the attacker must be able to inject fabric traffic, for example as\na compromised switch or fabric controller, or as a same-zone N_Port on a\nfabric that permits source spoofing.\n\nThe Link-Integrity and Peer-Congestion FPIN walkers used a u8 loop\ncounter against the 32-bit on-wire pname_count field, and did not bound\npname_count by the descriptor body already validated by the TLV walker.\nA pname_count of 256 therefore wraps the counter and keeps the loop\ncondition true indefinitely.\n\nFactor the shared pname_list[] walk into one helper, widen the counter\nto u32, and clamp pname_count against the entries that fit in the\ndescriptor body before iterating.(CVE-2026-63889)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nthunderbolt: property: Cap recursion depth in __tb_property_parse_dir()\n\nA DIRECTORY entry's value field is used as the dir_offset for a\nrecursive call into __tb_property_parse_dir() with no depth counter.\nA crafted peer that chains DIRECTORY entries into a back-reference\nloop drives the parser until the kernel stack is exhausted and the\nguard page fires.  Any untrusted XDomain peer (cable, dock, in-line\ninspector, adjacent host) that reaches the PROPERTIES_REQUEST\ncontrol-plane exchange can trigger this without authentication.\n\nThread a depth counter through tb_property_parse() and\n__tb_property_parse_dir(), and reject blocks that exceed\nTB_PROPERTY_MAX_DEPTH = 8.  That is comfortably larger than any\nobserved legitimate XDomain layout.\n\nOperators who do not need XDomain host-to-host discovery can disable\nthe path entirely with thunderbolt.xdomain=0 on the kernel command\nline.(CVE-2026-63891)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nUSB: serial: mct_u232: fix memory corruption with small endpoint\n\nThe driver overrides the maximum transfer size for a specific device\nwhich only accepts 16 byte packets for its 32 byte bulk-out endpoint.\n\nMake sure to never increase the maximum transfer size to prevent slab\ncorruption should a malicious device report a smaller endpoint max\npacket size than expected.(CVE-2026-63898)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nUSB: serial: mxuport: fix memory corruption with small endpoint\n\nMake sure that the bulk-out endpoint max packet size is at least eight\nbytes to avoid user-controlled slab corruption should a malicious device\nreport a smaller size.(CVE-2026-63899)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nUSB: serial: digi_acceleport: fix memory corruption with small endpoints\n\nAdd the missing bulk-out buffer size sanity checks to avoid\nout-of-bounds memory accesses or slab corruption should a malicious\ndevice report smaller buffers than expected.(CVE-2026-63901)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nxfrm: esp: restore combined single-frag length gate\n\nThe ESP out-of-place fast path appends the trailer in esp_output_head()\nbefore esp_output_tail() allocates the destination page frag. The\nhead-side gate currently checks skb->data_len and tailen separately, but\nthe tail code allocates a single destination frag from the combined\npost-trailer skb->data_len.\n\nReject the page-frag fast path when the combined aligned length exceeds a\npage. Otherwise skb_page_frag_refill() may fall back to a single page while\nthe destination sg still spans the combined skb->data_len.\n\nRestore this combined-length page gate for both IPv4 and IPv6.(CVE-2026-63912)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nip6: vti: Use ip6_tnl.net in vti6_changelink().\n\nip netns add ns1\nip netns add ns2\nip -n ns1 link add vti6_test type vti6 remote ::1 local ::2 key 7\nip -n ns1 link set vti6_test netns ns2\nip -n ns2 link set vti6_test type vti6 remote ::3 local ::4 key 9\nip netns del ns2\nip netns del ns1\n[  132.495484] ------------[ cut here ]------------\n[  132.497609] kernel BUG at net/core/dev.c:12376!\n\nCommit 61220ab34948 ("vti6: Enable namespace changing") dropped\nNETIF_F_NETNS_LOCAL from vti6 devices. A vti6 tunnel can then\nmove through IFLA_NET_NS_FD. After the move dev_net(dev) points\nat the new netns while t->net stays at the creation netns.\n\nvti6_changelink() and vti6_update() still use dev_net(dev) and\ndev_net(t->dev). They unlink from one per netns hash and relink\ninto another. The creation netns is left with a stale entry.\ncleanup_net() of that netns later walks freed memory.\n\nReachable from an unprivileged user namespace (unshare --user\n--map-root-user --net). Cross tenant scope on container hosts.(CVE-2026-63917)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nxfrm: input: hold netns during deferred transport reinjection\n\nTransport-mode reinjection stores a struct net pointer in skb->cb and\nuses it later from xfrm_trans_reinject(). That pointer must stay valid\nuntil the deferred callback runs.\n\nTake a netns reference when queueing deferred reinjection work and drop\nit after the callback completes. Use maybe_get_net() so the queueing\npath does not revive a namespace that is already being torn down.\n\nThis keeps the existing workqueue design and fixes the netns lifetime\nhandling in one place for all users of xfrm_trans_queue_net().(CVE-2026-63919)\n\nIn the Linux kernel, ip6_datagram_recv_specific_ctl() builds IPV6_{HOPOPTS,DSTOPTS,RTHDR} cmsgs (and their IPV6_2292* legacy counterparts) by trusting the on-wire hdrlen byte (ptr[1]) when computing the put_cmsg() length. The length was validated only at parse time (ipv6_parse_hopopts(), etc.). An nftables payload-write expression can rewrite hdrlen after parsing and before the skb reaches recvmsg; the write itself is in-bounds but put_cmsg() then reads up to ((hdrlen+1) << 3) = 2040 bytes from an 8-byte header. nftables is reachable from an unprivileged user namespace, so this is an unprivileged slab-out-of-bounds read.(CVE-2026-63920)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nip6: vti: Use ip6_tnl.net in vti6_siocdevprivate().\n\nAfter patch 1/2 in this series, vti6_update() unlinks and relinks\nthe tunnel through t->net. vti6_siocdevprivate() still uses\ndev_net(dev) for the collision lookup. For a tunnel moved through\nIFLA_NET_NS_FD, dev_net(dev) is the new netns, not t->net.\n\nSIOCCHGTUNNEL on a migrated tunnel then runs:\n\n  net = dev_net(dev)                    /* migrated netns */\n  t   = vti6_locate(net, &p1, false)    /* misses target in t->net */\n  ...\n  t   = netdev_priv(dev)\n  vti6_update(t, &p1, false)            /* mutates t->net's hash */\n\nA caller in the migrated netns picks params that match a tunnel\nin the creation netns. The lookup in dev_net(dev) finds nothing.\nvti6_update() prepends the migrated tunnel at the head of the\ncreation netns hash bucket for those params. Later lookups in\nthe creation netns resolve to the migrated device. xfrm receive\ndelivers the matched packets through a device the caller controls.\n\nReachable from an unprivileged user namespace (unshare --user\n--map-root-user --net). Cross tenant scope on container hosts.\n\nSwitch the SIOCCHGTUNNEL path on a non fallback device to use\nt->net for the lookup. The lookup now matches the netns\nvti6_update() operates on.\n\nAlso add ns_capable(self->net->user_ns, CAP_NET_ADMIN) before\nthe lookup. The check at the top of the case is against\ndev_net(dev)->user_ns, which after migration is the attacker's\nnetns. A caller there can pick params absent from self->net,\nthe lookup returns NULL, t becomes self, and vti6_update()\ninserts the device into the creation netns hash. The new check\nrequires CAP_NET_ADMIN in the creation netns user_ns too.\n\nSIOCADDTUNNEL and SIOCCHGTUNNEL on the fallback device keep\ndev_net(dev), which equals init_net there.(CVE-2026-63921)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nipv6: exthdrs: refresh nh pointer after ipv6_hop_jumbo()\n\nipv6_hop_jumbo() calls pskb_trim_rcsum(), which can change skb pointers.\nLet's recompute nh pointer to make sure any change won't mess things up.(CVE-2026-63924)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nbpf: sockmap: fix tail fragment offset in bpf_msg_push_data\n\nWhen bpf_msg_push_data() inserts data in the middle of a scatterlist\nentry, it splits the original entry into a left fragment and a right\nfragment.\n\nThe right fragment offset is page-local, but the code advances it with\n`start`, which is the message-global insertion point. For inserts into a\nnon-first SG entry, this over-advances the offset and leaves the split\nlayout inconsistent.\n\nAdvance the right fragment offset by the fragment-local delta,\n`start - offset`, which matches the length removed from the front of the\noriginal entry.(CVE-2026-63926)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nUSB: serial: omninet: fix memory corruption with small endpoint\n\nMake sure that the bulk-out buffers are at least as large as the\nhardcoded transfer size to avoid user-controlled slab corruption should\na malicious device report a smaller endpoint max packet size than\nexpected.(CVE-2026-63928)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nBluetooth: hci_sync: fix UAF in hci_le_create_cis_sync\n\nhci_le_create_cis_sync() dereferences conn->conn_timeout after releasing\nboth rcu_read_lock() and hci_dev_lock(hdev).  The conn pointer was\nobtained from an RCU-protected iteration over hdev->conn_hash.list and\nis not valid once these locks are dropped.  A concurrent disconnect can\nfree the hci_conn between the unlock and the dereference, causing a\nuse-after-free read.\n\nThe cancellation mechanism in hci_conn_del() cannot prevent this because\nhci_le_create_cis_pending() queues hci_create_cis_sync with data=NULL:\n\n    hci_cmd_sync_queue(hdev, hci_create_cis_sync, NULL, NULL);\n\nWhile hci_conn_del() dequeues with data=conn:\n\n    hci_cmd_sync_dequeue(hdev, NULL, conn, NULL);\n\nSince NULL != conn, the lookup in _hci_cmd_sync_lookup_entry() never\nmatches, and the pending work item is not cancelled.\n\nFix this by saving conn->conn_timeout into a local variable while the\nlocks are still held, so the stale conn pointer is never dereferenced\nafter unlock.\n\nThis is the same class of bug as the one fixed by commit 035c25007c9e\n("Bluetooth: hci_sync: Fix UAF on le_read_features_complete") which\naddressed the identical pattern in a different function.\n\nThis vulnerability was identified using 0sec.ai, an open-source\nautomated security auditing platform (https://github.com/0sec-labs).(CVE-2026-63944)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nBluetooth: ISO: serialize iso_sock_clear_timer with socket lock\n\niso_sock_close() calls iso_sock_clear_timer() before acquiring\nlock_sock(sk).\n\niso_sock_clear_timer() reads iso_pi(sk)->conn twice without the\nsocket lock held:\n\n    if (!iso_pi(sk)->conn)\n        return;\n    cancel_delayed_work(&iso_pi(sk)->conn->timeout_work);\n\nConcurrently, iso_conn_del() executes under lock_sock(sk) and calls\niso_chan_del(), which sets iso_pi(sk)->conn to NULL and may result in\nthe final reference to the connection being dropped:\n\n    CPU0                         CPU1\n    ----                         ----\n    iso_sock_clear_timer()\n      if (conn != NULL) ...      lock_sock(sk)\n                                   iso_chan_del()\n                                   iso_pi(sk)->conn = NULL\n      cancel_delayed_work(conn)  /* NULL deref or UAF */\n\niso_pi(sk)->conn is not stable across the unlock window, causing a\nNULL pointer dereference or use-after-free.\n\nSerialize iso_sock_clear_timer() with the socket lock by moving it\ninside lock_sock()/release_sock(), matching the pattern used in\niso_conn_del() and all other call sites.(CVE-2026-63945)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nBluetooth: ISO: fix UAF in iso_recv_frame\n\niso_recv_frame reads conn->sk under iso_conn_lock but releases the lock\nbefore using sk, with no reference held. A concurrent iso_sock_kill()\ncan free sk in that window, causing use-after-free on sk->sk_state and\nsock_queue_rcv_skb().\n\nFix by replacing the bare pointer read with iso_sock_hold(conn), which\ncalls sock_hold() while the spinlock is held, atomically elevating the\nrefcount before the lock drops. Add a drop_put label so sock_put() is\ncalled on all exit paths where the hold succeeded.(CVE-2026-63946)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nmemfd: deny writeable mappings when implying SEAL_WRITE\n\nWhen SEAL_EXEC is added, SEAL_WRITE is implied to make W^X.  But the\nimplied seal is set after the check that makes sure the memfd can not have\nany writable mappings.  This means one can use SEAL_EXEC to apply\nSEAL_WRITE while having writeable mappings.\n\nThis breaks the contract that SEAL_WRITE provides and can be used by an\nattacker to pass a memfd that appears to be write sealed but can still be\nmodified arbitrarily.\n\nFix this by adding the implied seals before the call for\nmapping_deny_writable() is done.(CVE-2026-63952)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nUSB: serial: cypress_m8: fix memory corruption with small endpoint\n\nMake sure that the interrupt-out endpoint max packet size is at least\neight bytes to avoid user-controlled slab corruption or NULL-pointer\ndereference should a malicious device report a smaller size.(CVE-2026-63956)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nipv6: fix possible infinite loop in fib6_select_path()\n\nFound while auditing the same pattern Sashiko reported in\nrt6_fill_node() [1]. Apply the same fix as\ncommit f8d8ce1b515a ("ipv6: fix possible infinite loop in fib6_info_uses_dev()").\n\nWriters holding tb6_lock can list_del_rcu(&first->fib6_siblings)\nwithout waiting for RCU readers; first->fib6_siblings.next then\nstill points into the old ring and this softirq-side walker never\nreaches &first->fib6_siblings as its terminator. fib6_purge_rt()\nalways WRITE_ONCE()s first->fib6_nsiblings to 0 before\nlist_del_rcu(), so an inside-loop check is a reliable detach signal.\n\n[1] https://sashiko.dev/#/patchset/20260526020227.4857-1-jiayuan.chen%40linux.dev(CVE-2026-63968)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nsctp: fix race between sctp_wait_for_connect and peeloff\n\nsctp_wait_for_connect() drops and re-acquires the socket lock while\nwaiting for the association to reach ESTABLISHED state. During this\nwindow, another thread can peeloff the association to a new socket via\ngetsockopt(SCTP_SOCKOPT_PEELOFF), changing asoc->base.sk. After\nre-acquiring the old socket lock, sctp_wait_for_connect() returns\nsuccess without noticing the migration — the caller then accesses\nthe association under the wrong lock in sctp_datamsg_from_user().\n\nAdd the same sk != asoc->base.sk check that sctp_wait_for_sndbuf()\nalready has, returning an error if the association was migrated while\nwe slept.(CVE-2026-63971)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nBluetooth: hci_sync: Set HCI_CMD_DRAIN_WORKQUEUE during device close\n\nSince hci_dev_close_sync() can now be called during the reset path, we\nshould also set HCI_CMD_DRAIN_WORKQUEUE. This avoids queuing timeouts\nwhile the hdev workqueue is being drained.(CVE-2026-63974)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nBluetooth: L2CAP: Fix possible crash on l2cap_ecred_conn_rsp\n\nIf dcid is received for an already-assigned destination CID the spec\nrequires that both channels to be discarded, but calling l2cap_chan_del\nmay invalidate the tmp cursor created by list_for_each_entry_safe and\nin fact it is the wrong procedure as the chan->dcid may be assigned\npreviously it really needs to be disconnected.\n\nCalling l2cap_chan_clone directly may still lead to l2cap_chan_del so\ninstead schedule l2cap_chan_timeout with delay 0 to close the channel\nasynchronously.(CVE-2026-63975)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nBluetooth: l2cap: clear chan->ident on ECRED reconfiguration success\n\nl2cap_ecred_reconf_rsp() returns early on success without clearing\nchan->ident. Every other L2CAP response handler (l2cap_ecred_conn_rsp,\nl2cap_le_connect_rsp, l2cap_config_rsp) clears chan->ident after a\nsuccessful transaction to prevent the channel from matching subsequent\nresponses with the recycled ident value.\n\nA remote attacker that completed a reconfiguration as the peer can\nreplay a failure response with the stale ident, causing the kernel to\nmatch and destroy the already-established channel via\nl2cap_chan_del(chan, ECONNRESET).\n\nClear chan->ident for all matching channels on success, and harden the\nfailure path by using l2cap_chan_hold_unless_zero() consistent with\nother L2CAP handlers (l2cap_le_command_rej, __l2cap_get_chan_by_ident).(CVE-2026-63976)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nipv6: rpl: fix hdrlen overflow in ipv6_rpl_srh_decompress()\n\nipv6_rpl_srh_decompress() computes:\n\n    outhdr->hdrlen = (((n + 1) * sizeof(struct in6_addr)) >> 3);\n\nhdrlen is __u8. For n >= 127 the result exceeds 255 and silently\ntruncates. With n=127 (cmpri=15, cmpre=15, pad=0, hdrlen=16):\n\n    (128 * 16) >> 3 = 256, truncated to 0 as __u8\n\nThe caller in ipv6_rpl_srh_rcv() then places the compressed header\nat buf + ((ohdr->hdrlen + 1) << 3). With hdrlen=0 this is buf + 8,\nbut the decompressed region occupies buf[0..2055] (8-byte header\nplus 128 full addresses). The compressed header overlaps the\ndecompressed data, and ipv6_rpl_srh_compress() writes into this\noverlap, corrupting the routing header of the forwarded packet.\n\nThe existing guard at exthdrs.c:546 checks (n + 1) > 255, which\nprevents n+1 from overflowing unsigned char (the segments_left\nfield), but does not prevent the computed hdrlen from overflowing\n__u8. n=127 passes because 128 <= 255, yet hdrlen=256 does not\nfit.\n\nTighten the bound to (n + 1) > 127. This caps n at 126, giving\nhdrlen = (127 * 16) >> 3 = 254, which fits in __u8. The compressed\nheader then lands at buf + ((254 + 1) << 3) = buf + 2040, exactly\npast the decompressed region (buf[0..2039]). No overlap. 127\nsegments is well beyond any realistic RPL deployment.(CVE-2026-63984)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nethtool: eeprom: add more safeties to EEPROM Netlink fallback\n\nThe Netlink fallback path for reading module EEPROM\n(fallback_set_params()) validates that offset < eeprom_len,\nbut does not check that offset + length stays within eeprom_len.\nThe ioctl equivalent (ethtool_get_any_eeprom() in ioctl.c) has\nalways enforced both bounds:\n\n  if (eeprom.offset + eeprom.len > total_len)\n      return -EINVAL;\n\nThis could lead to surprises in both drivers and device FW.\nAdd the missing offset + length validation to fallback_set_params(),\nmirroring the ioctl.\n\nSimilarly - ethtool core in general, and ethtool_get_any_eeprom()\nin particular tries to zero-init all buffers passed to the drivers\nto avoid any extra work of zeroing things out. eeprom_fallback()\nuses a plain kmalloc(), change it to zalloc.(CVE-2026-63985)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ntunnels: do not assume transport header in iptunnel_pmtud_check_icmp()\n\nIn some cases, iptunnel_pmtud_check_icmp() can be called while\nskb transport header is not set.\n\nThis triggers an out-of-bound access, because\n(typeof(skb->transport_header))~0U is 65535.\n\nAccess the icmp header based on IPv4 network header,\nafter making sure icmp->type is present in skb linear part.\n\nNote that iptunnel_pmtud_check_icmpv6()) is fine.(CVE-2026-63992)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nvxlan: do not reuse cached ip_hdr() value after skb_tunnel_check_pmtu()\n\nskb_tunnel_check_pmtu() can change skb->head.\n\nReusing old_iph afer skb_tunnel_check_pmtu() can cause an UAF.\n\nUse instead ip_hdr(skb) as done in drivers/net/bareudp.c\nand drivers/net/geneve.c.\n\nFound by Sashiko.(CVE-2026-63993)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ntunnels: load network headers after skb_cow() in iptunnel_pmtud_build_icmp[v6]()\n\nSashiko found that iptunnel_pmtud_build_icmp() and\niptunnel_pmtud_build_icmpv6() were caching ip_hdr() and ipv6_hdr()\nbefore an skb_cow() call which can reallocate skb->head.\n\nFix this possible UAF by initializing the local variables\nafter the skb_cow() call.\n\nRemove skb_reset_network_header() calls which were not needed.(CVE-2026-63994)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nipv4: free net->ipv4.sysctl_local_reserved_ports after unregister_net_sysctl_table()\n\nipv4_sysctl_exit_net() is currently freeing net->ipv4.sysctl_local_reserved_ports\ntoo soon.\n\nOnly after unregister_net_sysctl_table() we can be sure no threads can possibly\nuse the sysctls, including /proc/sys/net/ipv4/ip_local_reserved_ports.(CVE-2026-64002)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nscsi: core: Run queues for all non-SDEV_DEL devices from scsi_run_host_queues\n\nWhile a SCSI host is in a recovery state, scsi_mq_requeue_cmd() will not\nset the requeue list for a requeued command to be kicked in the future.\nThe expectation is a call to scsi_run_host_queues() will kick all SCSI\ndevices once the recovery state is cleared.\n\nHowever, scsi_run_host_queues() uses shost_for_each_device() which uses\nscsi_device_get() and so will ignore devices in a partially removed\nstate like SDEV_CANCEL. But these devices may also have requeued\nrequests, leaving their requests stuck from not being kicked and causing\nthe removal process of the device to hang.\n\nscsi_run_host_queues() needs to run against more devices than the macro\nshost_for_each_device() allows. Instead of using the too limiting\nscsi_device_get() state checks, only ignore devices in SDEV_DEL state or\nwhen unable to acquire a reference. Attempt to run the queues for all\nother devices when scsi_run_host_queues() is called.(CVE-2026-64003)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nsecurity/keys: fix missed RCU read section on lookup\n\nNicholas Carlini reports that the keyring code calls assoc_array_find()\nin find_key_to_update() without holding the RCU read lock, while the\nassoc_array_gc() code really is designed around removing the node from\nthe tree and then freeing it after an RCU grace-period.\n\nThe regular key handling doesn't see this because holding the keyring\nsemaphore hides any lifetime issues, but the persistent key handling\nuses a different model.\n\nInstead of extending the keyring locking, just do the simple RCU locking\nthat the assoc_array was designed for.(CVE-2026-64015)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nbpf, skmsg: fix verdict sk_data_ready racing with ktls rx\n\nsk_psock_strp_data_ready() already checks tls_sw_has_ctx_rx() and\ndefers to psock->saved_data_ready when a TLS RX context is present,\navoiding a conflict with the TLS strparser's ownership of the receive\nqueue (commit e91de6afa81c, "bpf: Fix running sk_skb program types\nwith ktls").\n\nsk_psock_verdict_data_ready() has no equivalent guard.  When a socket\nis inserted into a sockmap (BPF_SK_SKB_VERDICT) before TLS RX is\nconfigured, tls_sw_strparser_arm() saves sk_psock_verdict_data_ready\nas rx_ctx->saved_data_ready.  On data arrival:\n\n  tls_data_ready -> tls_strp_data_ready -> tls_rx_msg_ready\n    -> saved_data_ready() = sk_psock_verdict_data_ready()\n      -> tcp_read_skb() drains sk_receive_queue via __skb_unlink()\n         without calling tcp_eat_skb(), so copied_seq is not advanced.\n\ntls_strp_msg_load() then finds tcp_inq() >= full_len (stale), calls\ntcp_recv_skb() on the now-empty queue, hits WARN_ON_ONCE(!first), and\nreturns with rx_ctx->strp.anchor.frag_list pointing at a psock-owned\n(potentially freed) skb.  tls_decrypt_sg() subsequently walks that\nfrag_list: use-after-free.\n\nApply the same fix as sk_psock_strp_data_ready(): if a TLS RX context\nis present, call psock->saved_data_ready (sock_def_readable) to wake\nrecv() waiters and return immediately, leaving the receive queue\nuntouched.  TLS retains sole ownership of the queue and decrypts the\nrecord normally through tls_sw_recvmsg().(CVE-2026-64025)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nbridge: mcast: Fix a possible use-after-free when removing a bridge port\n\nWhen per-VLAN multicast snooping is enabled, the bridge iterates over\nall the bridge ports, disables the per-port multicast context on each\nport and enables the per-{port, VLAN} multicast contexts instead. The\nreverse happens when per-VLAN multicast snooping is disabled.\n\nWhen global multicast snooping is enabled, the bridge iterates over all\nthe bridge ports and enables the per-port multicast context on each\nport. The reverse happens when multicast snooping is disabled.\n\nThe above scheme can result in a situation where both types of contexts\n(per-port and per-{port, VLAN}) are enabled on a single bridge port:\n\n # ip link add name br1 up type bridge mcast_snooping 1 mcast_querier 1 vlan_filtering 1\n # ip link add name dummy1 up master br1 type dummy\n # ip link set dev br1 type bridge mcast_vlan_snooping 1\n # ip link set dev br1 type bridge mcast_snooping 0\n # ip link set dev br1 type bridge mcast_snooping 1\n\nThis is not intended and it is a problem since the commit cited below.\nPrior to this commit, when removing a bridge port,\nbr_multicast_disable_port() would disable the per-port multicast context\nand the per-{port, VLAN} multicast contexts would get disabled when\nflushing VLANs.\n\nAfter this commit, br_multicast_disable_port() only disables the\nper-port multicast context if per-VLAN multicast snooping is disabled.\nIf both types of contexts were enabled on the port when it was removed,\nthe per-port multicast context would remain enabled when freeing the\nbridge port, leading to a use-after-free [1].\n\nFix by preventing the bridge from enabling / disabling the per-port\nmulticast contexts when toggling global multicast snooping if per-VLAN\nmulticast snooping is enabled.\n\n[1]\nODEBUG: free active (active state 0) object: ffff88810f8bda78 object type: timer_list hint: br_ip6_multicast_port_query_expired (net/bridge/br_multicast.c:1927)\nWARNING: lib/debugobjects.c:629 at debug_print_object+0x1b1/0x3e0, CPU#5: swapper/5/0\n[...]\nCall Trace:\n<IRQ>\n__debug_check_no_obj_freed (lib/debugobjects.c:1116)\nkfree (mm/slub.c:2620 mm/slub.c:6250 mm/slub.c:6565)\nkobject_cleanup (lib/kobject.c:689)\nrcu_do_batch (kernel/rcu/tree.c:2617)\nrcu_core (kernel/rcu/tree.c:2869)\nhandle_softirqs (kernel/softirq.c:622)\n__irq_exit_rcu (kernel/softirq.c:656 kernel/softirq.c:496 kernel/softirq.c:735)\nirq_exit_rcu (kernel/softirq.c:752)\nsysvec_apic_timer_interrupt (arch/x86/kernel/apic/apic.c:1061 (discriminator 47) arch/x86/kernel/apic/apic.c:1061 (discriminator 47))\n</IRQ>(CVE-2026-64032)\n\nIn the Linux kernel, the following vulnerability has been resolved: net: tls: prevent chain-after-chain in plain text SG. Sashiko points out that if end = 0 (start != 0) the current code will create a chain link to content type right after the wrap link. This would create a chain where the wrap link points directly to another chain link. The scatterlist API sg_next iterator does not recursively resolve consecutive chain links, meaning this is illegal input to crypto. The wrapping link is unnecessary if end = 0. TLS 1.3 can use the "wrapping slot" for its chaining if end = 0, which avoids the chain-after-chain.(CVE-2026-64046)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet: tls: fix off-by-one in sg_chain entry count for wrapped sk_msg ring\n\nWhen an sk_msg scatterlist ring wraps (sg.end < sg.start),\ntls_push_record() chains the tail portion of the ring to the head\nusing sg_chain(). An extra entry in the sg array is reserved for\nthis:\n\n  struct sk_msg_sg {\n        [...]\n        /* The extra two elements:\n         * 1) used for chaining the front and sections when the list becomes\n         *    partitioned (e.g. end < start). The crypto APIs require the\n         *    chaining;\n         * 2) to chain tailer SG entries after the message.\n         */\n        struct scatterlist              data[MAX_MSG_FRAGS + 2];\n\nThe current code uses MAX_SKB_FRAGS + 1 as the ring size:\n\n    sg_chain(&msg_pl->sg.data[msg_pl->sg.start],\n             MAX_SKB_FRAGS - msg_pl->sg.start + 1,\n             msg_pl->sg.data);\n\nThis places the chain pointer at\n\n  sg_chain(data[start], (MAX_SKB_FRAGS - msg_start + 1) .. =\n  &data[start] + (MAX_SKB_FRAGS - msg_start + 1) - 1 =\n  data[start + (MAX_SKB_FRAGS - start + 1) - 1] =\n  data[MAX_SKB_FRAGS]\n\ninstead of the true last entry. This is likely due to a "race" of\nthe commit under Fixes landing close to\ncommit 031097d9e079 ("bpf: sk_msg, zap ingress queue on psock down")\n\nConvert to ARRAY_SIZE and drop the data[start] / - start (as suggested\nby Sabrina).(CVE-2026-64047)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nirq_work: Fix use-after-free in irq_work_single() on PREEMPT_RT\n\nOn PREEMPT_RT, non-HARD irq_work runs in per-CPU kthreads via\nrun_irq_workd(), so irq_work_sync() uses rcuwait() to wait for BUSY==0.\n\nAfter irq_work_single() clears BUSY via atomic_cmpxchg(), it still\ndereferences @work for irq_work_is_hard() and rcuwait_wake_up().\n\nAn irq_work_sync() caller on another CPU that enters after BUSY is cleared\ncan observe BUSY==0 immediately, return, and free the work before those\naccesses complete — causing a use-after-free.\n\nFix this by wrapping run_irq_workd() in guard(rcu)() so that the entire\nirq_work_single() execution is within an RCU read-side critical\nsection. Then add synchronize_rcu() in irq_work_sync() after\nrcuwait_wait_event() to ensure the caller waits for the RCU grace period\nbefore returning, preventing premature frees.(CVE-2026-64073)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnetfilter: bridge: eb_tables: close module init race\n\nsashiko reports for unrelated patch:\n Does the core ebtables initialization in ebtables.c suffer from a similar race?\n Once nf_register_sockopt() completes, the sockopts are exposed globally.\n\nsockopt has to be registered last, just like in ip/ip6/arptables.(CVE-2026-64076)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnetfilter: ebtables: move to two-stage removal scheme\n\nLike previous patches for x_tables, follow same pattern in ebtables.\nWe can't reuse xt helpers: ebt_table struct layout is incompatible.\n\ntable->ops assignment is now done while still holding the ebt mutex\nto make sure we never expose partially-filled table struct.(CVE-2026-64077)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nbatman-adv: tt: fix negative tt_buff_len\n\nbatadv_orig_node::tt_buff_len was declared as s16, but the field is never\nintended to hold a negative value. When a value greater than 32767 is\nassigned, it wraps to a negative signed integer.\n\nIn batadv_send_other_tt_response(), tt_buff_len is temporarily widened to\ns32. The incorrectly negative s16 value propagates into the s32, causing\nbatadv_tt_prepare_tvlv_global_data() to allocate a full sized buffer but\npopulates only a small portion of it with the collected changeset. All\nremaining bits are kept uninitialized.\n\nUsing an u16 avoids this type confusion and ensures that no (negative) sign\nextension is performed in batadv_send_other_tt_response().(CVE-2026-64088)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nbatman-adv: tt: fix negative last_changeset_len\n\nbatadv_piv_tt::last_changeset_len len was declared as s16, but the field is\nnever intended to hold a negative value. When a value greater than 32767 is\nassigned, it wraps to a negative signed integer.\n\nIn batadv_send_my_tt_response(), last_changeset_len is temporarily widened\nto s32. The incorrectly negative s16 value propagates into the s32, causing\nbatadv_tt_prepare_tvlv_local_data() to allocate a full sized buffer but\npopulates only a small portion of it with the collected changeset. All\nremaining bits are kept uninitialized.\n\nUsing an u16 avoids this type confusion and ensures that no (negative) sign\nextension is performed in batadv_send_my_tt_response().(CVE-2026-64089)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nbatman-adv: bla: avoid double decrement of bla.num_requests\n\nThe bla.num_requests is increased when no request_sent was in progress. And\nit is decremented in various places (announcement was received, backbone is\npurged, periodic work). But the check if the request_sent is actually set\nto a specific state and the atomic_dec/_inc are not safe because they are\nnot atomic (TOCTOU) and multiple such code portions can run concurrently.\n\nAt the same time, it is necessary to modify request_sent (state) and\nbla.num_requests atomically. Otherwise batadv_bla_send_request() might set\nrequest_sent to 1 and is interrupted.  batadv_handle_announce() can then\nset request_sent back to 0 and decrement num_requests before\nbatadv_bla_send_request() incremented it.\n\nThe two operations must therefore be locked. And since state (request_sent)\nand wait_periods are only accessed inside this lock, they can be converted\nto simpler datatypes. And to avoid that the bla.num_requests is touched by\na parallel running context with a valid backbone_gw reference after\nbatadv_bla_purge_backbone_gw() ran, a third state "stopped" is required to\ncorrectly signal that a backbone_gw is in the state of being cleaned up.(CVE-2026-64095)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ndrm/amd/display: Validate GPIO pin LUT table size before iterating\n\n[Why&How]\nThe GPIO pin table parsers in get_gpio_i2c_info() and\nbios_parser_get_gpio_pin_info() derive an element count from the VBIOS\ntable_header.structuresize field, then iterate over gpio_pin[] entries.\nHowever, GET_IMAGE() only validates that the table header itself fits\nwithin the BIOS image. If the VBIOS reports a structuresize larger than\nthe actual mapped data, the loop reads past the end of the BIOS image,\ncausing an out-of-bounds read.\n\nFix this by calling bios_get_image() to validate that the full claimed\nstructuresize is accessible within the BIOS image before entering the\nloop in both functions.\n\n(cherry picked from commit ba5e95b43b773ae1bf1f66ee6b31eb774e65afe3)(CVE-2026-64097)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ndrm/virtio: use uninterruptible resv lock for plane updates\n\nvirtio_gpu_cursor_plane_update() and virtio_gpu_resource_flush() lock\nthe framebuffer BO's dma_resv via virtio_gpu_array_lock_resv() and\nignore its return value. The function can fail with -EINTR from\ndma_resv_lock_interruptible() (signal during lock wait) or with\n-ENOMEM from dma_resv_reserve_fences() (fence slot allocation),\nleaving the resv lock not held. The queue path then walks the object\narray and calls dma_resv_add_fence(), which requires the lock held;\nwith lockdep enabled this trips dma_resv_assert_held():\n\n  WARNING: drivers/dma-buf/dma-resv.c:296 at dma_resv_add_fence+0x71e/0x840\n  Call Trace:\n   virtio_gpu_array_add_fence\n   virtio_gpu_queue_ctrl_sgs\n   virtio_gpu_queue_fenced_ctrl_buffer\n   virtio_gpu_cursor_plane_update\n   drm_atomic_helper_commit_planes\n   drm_atomic_helper_commit_tail\n   commit_tail\n   drm_atomic_helper_commit\n   drm_atomic_commit\n   drm_atomic_helper_update_plane\n   __setplane_atomic\n   drm_mode_cursor_universal\n   drm_mode_cursor_common\n   drm_mode_cursor_ioctl\n   drm_ioctl\n   __x64_sys_ioctl\n\nBeyond the WARN, mutating the dma_resv fence list without the lock\nraces with concurrent readers/writers and can corrupt the list.\n\nBoth call sites run inside the .atomic_update plane callback, which\nDRM atomic helpers do not allow to fail (by the time it runs, the\ncommit has been signed off to userspace and there is no clean\nrollback path). Moving the lock acquisition to .prepare_fb was\nrejected because the broader lock scope deadlocks against other BO\nlocking paths in the same atomic commit.\n\nIntroduce virtio_gpu_lock_one_resv_uninterruptible() that uses\ndma_resv_lock() instead of dma_resv_lock_interruptible(). This\neliminates the -EINTR failure mode -- the realistic syzbot trigger\n-- without extending the lock hold across the commit. The helper\nlocks a single BO and rejects nents > 1 with -EINVAL; both fix\nsites lock exactly one BO.\n\nUse it from virtio_gpu_cursor_plane_update() and\nvirtio_gpu_resource_flush(); check the return value to handle the\nremaining -ENOMEM case from dma_resv_reserve_fences() by freeing\nthe objs and skipping the plane update for that frame. The\nframebuffer BOs touched here are not shared with other contexts\nand lock contention is expected to be brief, so the loss of\nsignal-interruptibility is acceptable.\n\nOther callers of virtio_gpu_array_lock_resv() (the ioctl paths)\ncontinue to use the interruptible variant.\n\nThe bug was reported by syzbot, triggered via fault injection\n(fail_nth) on the DRM_IOCTL_MODE_CURSOR path, which forces the\n-ENOMEM branch in dma_resv_reserve_fences().(CVE-2026-64098)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nKVM: arm64: vgic-its: Reject restored DTE with out-of-range num_eventid_bits\n\nUserspace can restore an ITS Device Table Entry whose Size field encodes\nmore EventID bits than the virtual ITS supports.  The live MAPD path\nrejects that state, but vgic_its_restore_dte() accepts it and stores the\nout-of-range value in dev->num_eventid_bits.\n\nReject restored DTEs with num_eventid_bits > VITS_TYPER_IDBITS before\nallocating the device.  This mirrors the MAPD check and prevents the\nrestored state from reaching vgic_its_restore_itt(), where the unchecked\nvalue can be converted into an oversized scan_its_table() range.(CVE-2026-64106)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\naf_unix: Fix UAF read of tail->len in unix_stream_data_wait()\n\nunix_stream_data_wait() does skb_peek_tail(&sk->sk_receive_queue) without\nholding any lock that prevents SKBs on that queue from being dequeued and\nfreed.\nThis has been the case since commit 79f632c71bea ("unix/stream: fix\npeeking with an offset larger than data in queue").\nThe first consequence of this is that the pointer comparison\n`tail != last` can be false even if `last` semantically refers to an\nalready-freed SKB while `tail` is a new SKB allocated at the same address;\nwhich can cause unix_stream_data_wait() to wrongly keep blocking after new\ndata has arrived, but only in a weird scenario where a peeking recv() and\na normal recv() on the same socket are racing, which is probably not a\nreal problem.\n\nBut since commit 2b514574f7e8 ("net: af_unix: implement splice for stream\naf_unix sockets"), `tail` is actually dereferenced, which can cause UAF in\nthe following race scenario (where test_setup() runs single-threaded,\nand afterwards, test_thread1() and test_thread2() run concurrently in\ntwo threads:\n```\nstatic int socks[2];\nvoid test_setup(void) {\n  socketpair(AF_UNIX, SOCK_STREAM, 0, socks);\n  send(socks[1], "A", 1, 0);\n  int peekoff = 1;\n  setsockopt(socks[0], SOL_SOCKET, SO_PEEK_OFF, &peekoff, sizeof(peekoff));\n}\nvoid test_thread1(void) {\n  char dummy;\n  recv(socks[0], &dummy, 1, MSG_PEEK);\n}\nvoid test_thread2(void) {\n  char dummy;\n  recv(socks[0], &dummy, 1, 0);\n  shutdown(socks[1], SHUT_WR);\n}\n```\n\nwhen racing like this:\n```\nthread1                       thread2\nunix_stream_read_generic\n  mutex_lock(&u->iolock)\n  skb_peek(&sk->sk_receive_queue)\n  skb_peek_next(skb, &sk->sk_receive_queue)\n  mutex_unlock(&u->iolock)\n                              unix_stream_read_generic\n                                unix_state_lock(sk)\n                                skb_peek(&sk->sk_receive_queue)\n                                unix_state_unlock(sk)\n  unix_stream_data_wait\n    unix_state_lock(sk)\n    tail = skb_peek_tail(&sk->sk_receive_queue)\n                                spin_lock(&sk->sk_receive_queue.lock)\n                                __skb_unlink(skb, &sk->sk_receive_queue)\n                                spin_unlock(&sk->sk_receive_queue.lock)\n                                consume_skb(skb) [frees the SKB]\n    `tail != last`: false\n    `tail`: true\n    `tail->len != last_len` ***UAF***\n```\n\nFix the UAF by removing the read of tail->len; checking tail->len would\nonly make sense if SKBs in the receive queue of a UNIX socket could grow,\nwhich can no longer happen.\n\nKuniyuki explained:\n\n> When commit 869e7c62486e ("net: af_unix: implement stream sendpage\n> support") added sendpage() support, data could be appended to the last\n> skb in the receiver's queue.\n>\n> That's why we needed to check if the length of the last skb was changed\n> while waiting for new data in unix_stream_data_wait().\n>\n> However, commit a0dbf5f818f9 ("af_unix: Support MSG_SPLICE_PAGES") and\n> commit 57d44a354a43 ("unix: Convert unix_stream_sendpage() to use\n> MSG_SPLICE_PAGES") refactored sendmsg(), and now data is always added\n> to a new skb.\n\nThat means this fix is not suitable for kernels before 6.5.(CVE-2026-64109)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nrbd: eliminate a race in lock_dwork draining on unmap\n\nGiven how rbd_lock_add_request() and rbd_img_exclusive_lock() are\nwritten, lock_dwork may be (re)queued more than it's actually needed:\nfor example in case a new I/O request comes in while we are in the\nmiddle of rbd_acquire_lock() on behalf of another I/O request.  This is\nexpected and with rbd_release_lock() preemptively canceling lock_dwork\nis benign under normal operation.\n\nA more problematic example is maybe_kick_acquire():\n\n    if (have_requests || delayed_work_pending(&rbd_dev->lock_dwork)) {\n            dout("%s rbd_dev %p kicking lock_dwork\\n", __func__, rbd_dev);\n            mod_delayed_work(rbd_dev->task_wq, &rbd_dev->lock_dwork, 0);\n    }\n\nIt's not unrealistic for lock_dwork to get canceled right after\ndelayed_work_pending() returns true and for mod_delayed_work() to\nrequeue it right there anyway.  This is a classic TOCTOU race.\n\nWhen it comes to unmapping the image, there is an implicit assumption\nof no self-initiated exclusive lock activity past the point of return\nfrom rbd_dev_image_unlock() which unlocks the lock if it happens to be\nheld.  This unlock is assumed to be final and lock_dwork (as well as\nall other exclusive lock tasks, really) isn't expected to get queued\nagain.  However, lock_dwork is canceled only in cancel_tasks_sync()\n(i.e. later in the unmap sequence) and on top of that the cancellation\ncan get in effect nullified by maybe_kick_acquire().  This may result\nin rbd_acquire_lock() executing after rbd_dev_device_release() and\nrbd_dev_image_release() run and free and/or reset a bunch of things.\nOne of the possible failure modes then is a violated\n\n    rbd_assert(rbd_image_format_valid(rbd_dev->image_format));\n\nin rbd_dev_header_info() which is called via rbd_dev_refresh() from\nrbd_post_acquire_action().\n\nRedo exclusive lock task draining to provide saner semantics and try\nto meet the assumptions around rbd_dev_image_unlock().(CVE-2026-64112)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nixgbevf: fix use-after-free in VEPA multicast source pruning\n\nixgbevf_clean_rx_irq() prunes frames whose source MAC matches the VF's\nown address (VEPA multicast workaround) by freeing the skb and\ncontinuing to the next descriptor:\n\n    dev_kfree_skb_irq(skb);\n    continue;\n\nThe skb pointer is declared outside the while loop and persists across\niterations.  Because the continue skips the "skb = NULL" reset at the\nbottom of the loop, the next iteration enters the "else if (skb)" path\nand calls ixgbevf_add_rx_frag() on the freed skb, dereferencing\nskb_shinfo(skb)->nr_frags - a use-after-free in NAPI softirq context.\n\nThe sibling driver iavf already handles this correctly by nulling the\npointer before continuing.  Apply the same pattern here.\n\nI do not have ixgbevf hardware; the bug was found by static analysis\n(scan_drop_continue_loops.py + semgrep drop_continue_in_loop, multi-tool\ncorroboration with the highest score in the scan).  The UAF was confirmed\nunder KASAN by loading a test module that reproduces the exact code\npattern (alloc skb, kfree_skb, then read skb_shinfo(skb)->nr_frags):\n\n  BUG: KASAN: slab-use-after-free in ixgbevf_uaf_test_init+0x100/0x1000\n  Read of size 8 at addr 000000006163ae78 by task insmod/30\n  freed 208-byte region [000000006163adc0, 000000006163ae90)\n\nQEMU emulates igb (82576) but not ixgbe (82599), and the igbvf VF\ndriver does not include the VEPA source pruning path, so a full\nend-to-end reproduction with emulated hardware was not possible.(CVE-2026-64113)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nipv4: raw: reject IP_HDRINCL packets with ihl < 5\n\nraw_send_hdrinc() validates that the caller-supplied IPv4 header\nfits within the message length:\n\n    iphlen = iph->ihl * 4;\n    err = -EINVAL;\n    if (iphlen > length)\n        goto error_free;\n\n    if (iphlen >= sizeof(*iph)) {\n        /* fix up saddr, tot_len, id, csum, transport_header */\n    }\n\nIt does not, however, reject ihl < 5.  For such a packet the\n"if (iphlen >= sizeof(*iph))" branch is skipped, leaving the\ncrafted iphdr untouched, but the packet is still handed to\n__ip_local_out() and onward.  Downstream consumers that read\niph->ihl assume a sane value: net/ipv4/ah4.c:ah_output() in\nparticular subtracts sizeof(struct iphdr) from top_iph->ihl * 4\nand passes the (signed-int-negative, then cast to size_t)\nresult to memcpy(), producing an OOB access of length close to\nSIZE_MAX and a host kernel panic.\n\nAn IPv4 header with ihl < 5 is malformed by definition (RFC 791:\n"Internet Header Length is the length of the internet header in\n32 bit words ... Note that the minimum value for a correct header\nis 5.").  The kernel should not be willing to inject such a\npacket into its own output path.\n\nReject "iphlen < sizeof(*iph)" alongside the existing\n"iphlen > length" check.  This matches the principle that locally\nconstructed packets that re-enter the IP stack must pass the same\nbasic sanity tests that a foreign packet would be subjected to.\n\nOnce this lands, the "if (iphlen >= sizeof(*iph))" wrapper around\nthe fixup branch becomes redundant; left in place to keep the\npatch minimal and backport-friendly.  A follow-up can unwrap it.\n\nNote that commit 86f4c90a1c5c ("ipv4, ipv6: ensure raw socket\nmessage is big enough to hold an IP header") ensures the message\nbuffer is large enough to hold an iphdr, but does not constrain\nthe self-reported iph->ihl.\n\nReachability: the malformed packet source is any caller with\nCAP_NET_RAW, including an unprivileged process in a user+net\nnamespace on a kernel with CONFIG_USER_NS=y.  The reproduced AH\ncrash also requires a matching xfrm AH policy on the outgoing\nroute; a container granted CAP_NET_ADMIN can install that state\nand policy in its netns.  Loopback bypasses xfrm_output, so the\ntrigger uses a real netdev.\n\nReproduced on UML + KASAN: kernel-mode fault at addr 0x0 with\nmemcpy_orig at the crash site.  Same shape reproduces inside a\nrootless Docker container with --cap-add NET_ADMIN on a stock\ndistro kernel.(CVE-2026-64114)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nqed: fix double free in qed_cxt_tables_alloc()\n\nIf one of the later PF or VF CID bitmap allocations fails,\nqed_cid_map_alloc() jumps to cid_map_fail and frees the previously\nallocated CID bitmaps before returning an error. qed_cxt_tables_alloc()\nthen calls qed_cxt_mngr_free(), which invokes qed_cid_map_free()\nagain.\n\nFix this by setting each CID bitmap pointer to NULL after bitmap_free()\nto avoid double free.\n\nThe bug was first flagged by an experimental analysis tool we are\ndeveloping for kernel memory-management bugs while analyzing\nv6.13-rc1. The tool is still under development and is not yet publicly\navailable. Manual inspection confirms that the bug is still\npresent in v7.1-rc3.\n\nRuntime reproduction was not attempted because exercising the failing\nallocation path requires device-specific setup.(CVE-2026-64118)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nBluetooth: MGMT: validate Add Extended Advertising Data length\n\nMGMT_OP_ADD_EXT_ADV_DATA is registered as a variable-length command,\nwith MGMT_ADD_EXT_ADV_DATA_SIZE as the fixed header size.  The handler\nthen uses cp->adv_data_len and cp->scan_rsp_len to validate and copy\ncp->data, but it never checks that those bytes are part of the mgmt\ncommand payload.\n\nA short command can therefore make add_ext_adv_data() pass an\nout-of-bounds pointer into tlv_data_is_valid().  If the bytes beyond\nthe command buffer are addressable, they can also be copied into the\nadvertising instance as scan response data, where the caller can read\nthem back via MGMT_OP_GET_ADV_INSTANCE.  The trigger requires\nCAP_NET_ADMIN in the initial user namespace; KASAN reports an 8-byte\nslab-out-of-bounds read.\n\nReject commands whose length does not match the fixed header plus both\nadvertising data lengths before parsing cp->data.(CVE-2026-64126)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nsmb: client: protect tc_count increment in smb2_find_smb_sess_tcon_unlocked()\n\nCommit 96c4af418586 ("cifs: Fix locking usage for tcon fields")\nrefactored cifs code to change cifs_tcp_ses_lock for tc_lock around\ntc_count changes.\n\nThere was missing lock around tc_count increment inside\nsmb2_find_smb_sess_tcon_unlocked().(CVE-2026-64136)\n\nIn the Linux kernel, an out-of-bounds read vulnerability exists in the i2c-stub driver. The I2C_SMBUS_I2C_BLOCK_DATA case in stub_xfer() function (drivers/i2c/i2c-stub.c) uses data->block[0] as the transfer length. The existing check only clamps it to avoid overrunning the chip->words[256] register array, but does not validate it against I2C_SMBUS_BLOCK_MAX (32), which is the limit of the union i2c_smbus_data.block buffer. A local user with access to /dev/i2c-* devices can issue an I2C_SMBUS ioctl with I2C_SMBUS_I2C_BLOCK_DATA and data->block[0] > 32, causing stub_xfer() to read or write past the end of the union i2c_smbus_data.block buffer, resulting in a stack out-of-bounds access. This vulnerability affects confidentiality, integrity, and availability.(CVE-2026-64191)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ndrm/amd/display: Validate payload length and link_index in dc_process_dmub_aux_transfer_async\n\n[Why&How]\ndc_process_dmub_aux_transfer_async() copies payload->length bytes into a\n16-byte stack buffer (dpaux.data[16]) guarded only by an ASSERT(), which\nis a no-op in release builds. If a caller ever passes length > 16 this\nresults in a stack buffer overflow via memcpy.\n\nAdditionally, link_index is used to dereference dc->links[] without\nbounds checking against dc->link_count, risking an out-of-bounds access.\n\nReplace the ASSERT with a hard runtime check that returns false when\npayload->length exceeds the destination buffer size, and add a bounds\ncheck for link_index before it is used.\n\n(cherry picked from commit ba4caa9fecdf7a38f98c878ad05a8a64148b6881)(CVE-2026-64219)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nocteontx2-pf: avoid double free of pool->stack on AQ init failure\n\notx2_pool_aq_init() frees pool->stack when mailbox sync or retry\nallocation fails, but leaves the pointer unchanged. Later,\notx2_sq_aura_pool_init() unwinds the partial setup through\notx2_aura_pool_free(), which frees pool->stack again. The CN20K-specific\ncn20k_pool_aq_init() implementation has the same bug in\nits corresponding error path.\n\nSet pool->stack to NULL immediately after the local free so the shared\ncleanup path does not free the same stack again while cleaning up\npartially initialized pool state.\n\nThe bug was first flagged by an experimental analysis tool we are\ndeveloping for kernel memory-management bugs while analyzing\nv6.13-rc1. The tool is still under development and is not yet publicly\navailable. Manual inspection confirms that the bug is still present in\nv7.1-rc3.\n\nRuntime validation was not performed because reproducing this path\nrequires OcteonTX2/CN20K hardware.(CVE-2026-64222)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nInput: elan_i2c - validate firmware size before use\n\nEnsure that the firmware file is large enough to contain the expected\nnumber of pages and the signature (which resides at the end of the\nfirmware blob) before accessing them to prevent potential out-of-bounds\nreads.(CVE-2026-64237)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nKVM: x86: hyper-v: Bound the bank index when querying sparse banks\n\nWhen checking if a VP ID is included in a sparse bank set, explicitly check\nthat the ID can actually be contained in a sparse bank (the TLFS allows for\na maximum of 64 banks of 64 vCPUs each).  When handling a paravirtual TLB\nflush for L2, the VP ID is copied verbatim from the enlightened VMCS,\nwithout any bounds check, i.e. isn't guaranteed to be under the limit of\n4096.\n\nFailure to check the bounds of the VP ID leads to an out-of-bounds read\nwhen testing the sparse bank, and super strictly speaking could lead to KVM\nperforming an unnecessary TLB flush for an L2 vCPU.\n\n  ==================================================================\n  BUG: KASAN: use-after-free in hv_is_vp_in_sparse_set+0x85/0x100 [kvm]\n  Read of size 8 at addr ffff88811ba5f598 by task hyperv_evmcs/2802\n\n  CPU: 12 UID: 1000 PID: 2802 Comm: hyperv_evmcs Not tainted 7.1.0-rc2 #7 PREEMPT\n  Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 0.0.0 02/06/2015\n  Call Trace:\n   <TASK>\n   dump_stack_lvl+0x51/0x60\n   print_report+0xcb/0x5d0\n   kasan_report+0xb4/0xe0\n   kasan_check_range+0x35/0x1b0\n   hv_is_vp_in_sparse_set+0x85/0x100 [kvm]\n   kvm_hv_flush_tlb+0xe9e/0x16c0 [kvm]\n   kvm_hv_hypercall+0xe6b/0x1e60 [kvm]\n   vmx_handle_exit+0x485/0x1b60 [kvm_intel]\n   kvm_arch_vcpu_ioctl_run+0x22e3/0x5070 [kvm]\n   kvm_vcpu_ioctl+0x5d0/0x10c0 [kvm]\n   __x64_sys_ioctl+0x129/0x1a0\n   do_syscall_64+0xb9/0xcf0\n   entry_SYSCALL_64_after_hwframe+0x4b/0x53\n  RIP: 0033:0x7f0e62d1a9bf\n   </TASK>\n\n  The buggy address belongs to the physical page:\n  page: refcount:0 mapcount:0 mapping:0000000000000000 index:0xffffffffffffffff pfn:0x11ba5f\n  flags: 0x4000000000000000(zone=1)\n  raw: 4000000000000000 0000000000000000 00000000ffffffff 0000000000000000\n  raw: ffffffffffffffff 0000000000000000 00000000ffffffff 0000000000000000\n  page dumped because: kasan: bad access detected\n\n  Memory state around the buggy address:\n   ffff88811ba5f480: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff\n   ffff88811ba5f500: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff\n  >ffff88811ba5f580: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff\n                              ^\n   ffff88811ba5f600: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff\n   ffff88811ba5f680: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff\n  ==================================================================\n  Disabling lock debugging due to kernel taint\n\nOpportunistically add a compile time assertion to ensure the maximum number\nof sparse banks exactly matches the number of possible bits in the passed\nin mask.\n\n[sean: add KASAN splat, drop comment, add assert, massage changelog](CVE-2026-64247)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nNFSv4: include MAY_WRITE in open permission mask for O_TRUNC\n\nPOSIX requires write permission to truncate a file, so an open() that\nspecifies O_TRUNC must be authorized for write access regardless of the\nO_ACCMODE access mode.\n\nnfs_open_permission_mask() builds the access mask passed to\nnfs_may_open(), which is the local authorization gate for OPENs the\nclient serves itself from a cached write delegation via the\ncan_open_delegated() path in nfs4_try_open_cached().  The mask is\nderived from O_ACCMODE alone, so an open(O_RDONLY | O_TRUNC) against a\nfile the caller cannot write requests only MAY_READ and passes the\nlocal check.  The OPEN is then satisfied locally and the truncation is\nissued to the server as a SETATTR(size=0) over the delegation stateid,\nwhich the server accepts under standard write-delegation semantics.\nPOSIX requires that this open fail with EACCES.\n\nInclude MAY_WRITE in the mask whenever O_TRUNC is set so the local\ncheck matches the access the server would have enforced.(CVE-2026-64298)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ntracing: Prevent out-of-bounds read in glob matching\n\nString event fields are not necessarily NUL-terminated, so the filter\npredicate functions (filter_pred_string(), filter_pred_strloc() and\nfilter_pred_strrelloc()) pass the field length to the regex match\ncallbacks, and the length-aware matchers honour it.\n\nregex_match_glob() was the exception: it ignored the length and called\nglob_match(), which scans the string until it hits a NUL byte. Some\nstring fields are not NUL-terminated. One example is the dynamic char\narray of the xfs_* namespace tracepoints, which is copied without a\ntrailing NUL. For such a field, glob matching reads past the end of\nthe event field, causing a KASAN slab-out-of-bounds read in\nglob_match(), reached via regex_match_glob() and filter_match_preds()\nfrom the xfs_lookup tracepoint.\n\nAdd a length-bounded glob_match_len() and use it from regex_match_glob()\nso glob matching always stops at the field boundary. The matching loop\nis factored into a shared helper so glob_match() keeps its behaviour.(CVE-2026-64299)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ncrypto: qat - validate RSA CRT component lengths\n\nThe generic RSA key parser (rsa_helper.c) bounds each CRT component (p,\nq, dp, dq, qinv) by the modulus size n_sz, but qat_rsa_setkey_crt()\nallocates half-size DMA buffers (key_sz / 2) and right-aligns each\ncomponent with:\n\n    memcpy(dst + half_key_sz - len, src, len)\n\nWhen a CRT component is larger than half_key_sz the subtraction\nunderflows and memcpy writes past the DMA buffer, causing memory\ncorruption.\n\nAdd a len > half_key_sz check next to the existing !len check for each\nof the five CRT components so the driver falls back to the non-CRT path\ninstead of writing out of bounds.(CVE-2026-64304)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ncrypto: qat - protect service table iterations with service_lock\n\nThe service_table list is protected by service_lock when entries are\nadded or removed (in adf_service_add() and adf_service_remove()), but\nseveral functions iterate over the list without holding this lock.\n\nA concurrent adf_service_register() or adf_service_unregister() call\ncould modify the list during traversal, leading to list corruption or\na use-after-free.\n\nFix this by holding service_lock across all list_for_each_entry()\niterations of service_table in adf_dev_init(), adf_dev_start(),\nadf_dev_stop(), adf_dev_shutdown(), adf_dev_restarting_notify(),\nadf_dev_restarted_notify(), and adf_error_notifier().\n\nThe lock ordering is safe: callers of the static helpers (adf_dev_up()\nand adf_dev_down()) acquire state_lock before service_lock, and no\nevent_hld callback or service_lock holder ever acquires state_lock in\nthe reverse order.(CVE-2026-64305)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ncrypto: drbg - Fix returning success on failure in CTR_DRBG\n\ndrbg_ctr_generate() sometimes returns success when it fails, leaving the\noutput buffer uninitialized.  Fix it.(CVE-2026-64306)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ncrypto: pcrypt - restore callback for non-parallel fallback\n\npcrypt installs pcrypt_aead_done() on the child AEAD request before\ntrying to submit it through padata.  If padata_do_parallel() returns\n-EBUSY, pcrypt falls back to calling the child AEAD directly.\n\nThat fallback must not keep the padata completion callback.  Otherwise\nan asynchronous completion runs pcrypt_aead_done() even though the\nrequest was never enrolled in padata.\n\nRestore the original request callback and callback data before calling\nthe child AEAD directly.  This keeps the fallback path aligned with a\ndirect AEAD request while leaving the parallel path unchanged.(CVE-2026-64312)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ncrypto: ecc - Fix carry overflow in vli multiplication\n\nThe carry flag calculation fails when r01.m_high is saturated\n(0xFFFFFFFFFFFFFFFF) and addition of lower bits overflows.\n\nThe condition (r01.m_high < product.m_high) doesn't handle the case\nwhere r01.m_high == product.m_high and an additional carry exists\nfrom lower-bit overflow.\n\nWhen commit 3c4b23901a0c ("crypto: ecdh - Add ECDH software support")\nintroduced crypto/ecc.c, it split the muladd() function in the\nmicro-ecc library into separate mul_64_64() and add_128_128() helpers.\nIt seems the check got lost in translation.\n\nAdd proper handling for this boundary by accounting for the carry\nfrom the lower addition.(CVE-2026-64313)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nisofs: bound Rock Ridge symlink components to the SL record\n\nget_symlink_chunk() and the SL handling in\nparse_rock_ridge_inode_internal() walk the variable-length components of\na Rock Ridge "SL" (symbolic link) record.  Each component is a two-byte\nheader (flags, len) followed by len bytes of text, so it occupies\nslp->len + 2 bytes.  Both loops read slp->len and advance to the next\ncomponent, and get_symlink_chunk() additionally does\nmemcpy(rpnt, slp->text, slp->len), but neither checks that the component\nlies within the SL record before dereferencing it.\n\nA crafted SL record whose component declares a len that runs past the\nrecord (rr->len) therefore triggers an out-of-bounds read of up to 255\nbytes.  When the record sits at the tail of its backing buffer - for\nexample a small kmalloc()ed continuation block reached through a CE\nrecord - the read crosses the allocation; get_symlink_chunk() then\ncopies the out-of-bounds bytes into the symlink body returned to user\nspace by readlink(), disclosing adjacent kernel memory.\n\nISO 9660 images are routinely mounted from untrusted removable media -\ndesktop environments auto-mount them (e.g. via udisks2) without\nCAP_SYS_ADMIN - so the record contents are attacker-controlled.\n\nReject any component that does not fit in the remaining record bytes\nbefore using it.  In get_symlink_chunk() return NULL, like the existing\noutput-buffer (plimit) checks, so a malformed record makes readlink()\nfail with -EIO rather than silently returning a truncated target; in\nparse_rock_ridge_inode_internal() stop the inode-size walk.(CVE-2026-64317)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnvmet-auth: validate reply message payload bounds against transfer length\n\nnvmet_auth_reply() accesses the variable-length rval[] array using\nattacker-controlled hl (hash length) and dhvlen (DH value length) fields\nwithout verifying they fit within the allocated buffer of tl bytes.\n\nA malicious NVMe-oF initiator can craft a DHCHAP_REPLY message with a\nsmall transfer length but large hl/dhvlen values, causing out-of-bounds\nheap reads when the target processes the DH public key (rval + 2*hl) or\nperforms the host response memcmp.\n\nWith DH authentication configured, the OOB pointer is passed directly to\nsg_init_one() and read by crypto_kpp_compute_shared_secret(), reaching\nup to 526 bytes past the buffer. This is exploitable pre-authentication.\n\nAdd bounds validation ensuring sizeof(*data) + 2*hl + dhvlen <= tl before\nany access to the variable-length fields.\n\nDiscovered by Atuin - Automated Vulnerability Discovery Engine.(CVE-2026-64319)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnvmet: fix pre-auth out-of-bounds heap read in Discovery Get Log Page\n\nnvmet_execute_disc_get_log_page() validates only the dword alignment\nof the host-supplied Log Page Offset (lpo).  The 64-bit offset is then\nadded to a small kzalloc'd buffer that holds the discovery log page\nand the result is passed straight to nvmet_copy_to_sgl(), which\nmemcpy()s data_len bytes out to the host with no source-side bound\ncheck:\n\n    u64 offset      = nvmet_get_log_page_offset(req->cmd);  /* 64-bit host */\n    size_t data_len = nvmet_get_log_page_len(req->cmd);     /* 32-bit host */\n    ...\n    if (offset & 0x3) { ... }                               /* only check */\n    ...\n    alloc_len = sizeof(*hdr) + entry_size * discovery_log_entries(req);\n    buffer = kzalloc(alloc_len, GFP_KERNEL);\n    ...\n    status = nvmet_copy_to_sgl(req, 0, buffer + offset, data_len);\n\nThe Discovery controller is unauthenticated -- nvmet_host_allowed()\nreturns true unconditionally for the discovery subsystem -- so the call\nis reachable pre-authentication by any TCP/RDMA/FC peer that can reach\nthe nvmet target.  With a discovery log page of ~1 KiB, an attacker\nrequesting up to 4 KiB starting at offset == alloc_len reads the next\nslab page out and gets its content returned over the fabric (an\nempirical run on a default nvmet-tcp loopback target leaked 81\ncanonical kernel pointers in one Get Log Page response).  Pointing the\noffset at unmapped kernel memory faults the in-kernel memcpy and\ncrashes (or panics, on panic_on_oops=1) the target host instead.\n\nThe attacker-controlled source-side offset pattern\n"nvmet_copy_to_sgl(req, 0, buffer + ATTACKER_OFFSET, ...)" is unique\nto nvmet_execute_disc_get_log_page in the entire nvmet codebase: every\nother Get Log Page handler in admin-cmd.c either ignores lpo (and\nsilently starts every response at offset 0) or tracks a local\ndestination offset with a fixed source pointer.\n\nValidate the host-supplied offset against the log page size, cap the\ncopy length to what is actually available, and zero-fill any remainder\nof the host transfer buffer.  The zero-fill matches the existing\nshort-response pattern in nvmet_execute_get_log_changed_ns()\n(admin-cmd.c) and prevents leaking transport SGL contents when the\nhost asks for more bytes than the log page contains.(CVE-2026-64320)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nudf: validate sparing table length as an entry count, not a byte count\n\nudf_load_sparable_map() accepts a sparing table when\n\n\tsizeof(*st) + le16_to_cpu(st->reallocationTableLen) > sb->s_blocksize\n\nis false, i.e. it treats reallocationTableLen as a number of BYTES that\nmust fit in the block.  But the table is walked as an array of 8-byte\nsparingEntry elements:\n\n\tfor (i = 0; i < le16_to_cpu(st->reallocationTableLen); i++) {\n\t\tstruct sparingEntry *entry = &st->mapEntry[i];\n\t\t... entry->origLocation ...\n\t}\n\nin udf_get_pblock_spar15() and udf_relocate_blocks().  A\nreallocationTableLen of N therefore passes the check whenever\nsizeof(*st) + N <= blocksize, yet the consumers index\nsizeof(*st) + N * sizeof(struct sparingEntry) bytes -- up to ~8x the\nblock.  On a crafted UDF image this is an out-of-bounds read in\nudf_get_pblock_spar15(); udf_relocate_blocks() additionally feeds the\nsame length to udf_update_tag(), whose crc_itu_t() reads far past the\nblock, and its memmove() through st->mapEntry[] is an out-of-bounds\nwrite.\n\nValidate reallocationTableLen as the entry count it is, with\nstruct_size().(CVE-2026-64322)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nudf: validate VAT header length against the VAT inode size\n\nudf_load_vat() takes the virtual partition's start offset straight from\nthe on-disk VAT 2.0 header without checking it against the VAT inode\nsize:\n\n\tmap->s_type_specific.s_virtual.s_start_offset =\n\t\tle16_to_cpu(vat20->lengthHeader);\n\tmap->s_type_specific.s_virtual.s_num_entries =\n\t\t(sbi->s_vat_inode->i_size -\n\t\t\tmap->s_type_specific.s_virtual.s_start_offset) >> 2;\n\nlengthHeader is a fully attacker-controlled 16-bit value.  If it exceeds\nthe VAT inode size, the s_num_entries subtraction underflows to a huge\ncount, which defeats the "block > s_num_entries" bound in\nudf_get_pblock_virt15(); and on the ICB-inline path that function reads\n\n\t((__le32 *)(iinfo->i_data + s_start_offset))[block]\n\nso a large s_start_offset indexes past the inode's in-ICB data.  Mounting\na crafted UDF image with a virtual (VAT) partition then triggers an\nout-of-bounds read.\n\nReject a VAT whose header length does not leave room for at least one\nentry within the VAT inode.(CVE-2026-64323)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nudf: validate free block extents against the partition length\n\nudf_free_blocks() checks the logical block number and count against the\npartition length, but drops the extent offset from that final bound.  A\ncrafted extent can pass the guard while logicalBlockNum + offset + count\npoints past the partition, which later indexes past the space bitmap\narray.\n\nA single ftruncate(2) on a file backed by such an extent reliably\npanics the kernel.  This is a local availability issue.  On desktop\nsystems where UDisks/polkit allows the active user to mount removable\nUDF media without CAP_SYS_ADMIN, an unprivileged local user can supply\nthe crafted filesystem and trigger the panic by truncating a writable\nfile on it.  Systems that require root or CAP_SYS_ADMIN to mount the\nimage have a higher prerequisite.\n\nNo confidentiality or integrity impact is claimed: the reproduced\nprimitive is an out-of-bounds read of a bitmap pointer slot followed by\na kernel panic.\n\nUse the already computed logicalBlockNum + offset + count value for the\npartition length check.  Also make load_block_bitmap() reject an\nout-of-range block group before indexing s_block_bitmap[], so corrupted\ncallers cannot walk past the flexible array.(CVE-2026-64324)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nbpf: Reject fragmented frames in devmap\n\nDevmap broadcast redirects clone the packet for all but the last\ndestination.\n\nFor native XDP, that clone path copies only the linear xdp_frame data,\nwhile fragmented frames keep skb_shared_info in tailroom outside the\nlinear area. Cloning such a frame leaves XDP_FLAGS_HAS_FRAGS set but\nwithout valid frag metadata, and the later free path can interpret\nuninitialized tail data as skb_shared_info, leading to an out-of-bounds\naccess during frame return.\n\nReject fragmented native XDP frames in dev_map_enqueue_clone().\n\nAdd the same restriction to the generic XDP clone path in\ndev_map_redirect_clone(). Generic XDP represents fragmented packets as\nnonlinear skbs, and rejecting them here keeps clone-based broadcast\nsupport aligned between native and generic XDP.(CVE-2026-64355)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nHID: multitouch: fix out-of-bounds bit access on mt_io_flags\n\nmt_io_flags is a single unsigned long, but mt_process_slot(),\nmt_release_pending_palms() and mt_release_contacts() use it as a\nper-slot bitmap indexed by the slot number. That slot number is only\nbounded by td->maxcontacts, which is taken from the device's\nContactCountMaximum feature report and can be up to 255, not by\nBITS_PER_LONG.\n\nAs a result, a multitouch device that advertises a large contact count\nmakes set_bit()/clear_bit() operate past the mt_io_flags word and\ncorrupt the adjacent members of struct mt_device. The sticky-fingers\nrelease timer is the easiest way to reach this. mt_release_contacts()\nruns\n\n\tfor (i = 0; i < mt->num_slots; i++)\n\t\tclear_bit(i, &td->mt_io_flags);\n\nwith num_slots == maxcontacts. For maxcontacts around 250 the loop\nclears the bits that overlap td->applications.next, zeroing that list\nhead, and the list_for_each_entry() that immediately follows then\ndereferences NULL. The kernel panics from timer (softirq) context. On a\nKASAN build this shows up as a general protection fault in\nmt_release_contacts() with a null-ptr-deref at offset 0x58, which is\noffsetof(struct mt_application, num_received).\n\nThe state is reachable from an untrusted USB or Bluetooth HID\nmultitouch device; no local privileges are required.\n\nStore the per-slot active state in a separately allocated bitmap sized\nfor maxcontacts, the same pattern already used for pending_palm_slots,\nand keep only MT_IO_FLAGS_RUNNING in mt_io_flags. The two\n"mt_io_flags & MT_IO_SLOTS_MASK" arming checks become\nbitmap_empty(td->active_slots, td->maxcontacts).\n\nMove MT_IO_FLAGS_RUNNING back to bit 0. It was bumped to bit 32 by the\nsame commit to leave the low byte for the slot bits; with the slot bits\ngone it fits in bit 0 again, which also keeps it within the unsigned\nlong on 32-bit.(CVE-2026-64364)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nsched/rt: Have RT_PUSH_IPI be default off for non PREEMPT_RT\n\nRT migration is done aggressively. When a CPU schedules out a high\npriority RT task for a lower priority task, it will look to see if there's\nany RT tasks that are waiting to run on another CPU that is of higher\npriority than the task this CPU is about to run. If it finds one, it will\npull that task over to the CPU and allow it to run there instead.\n\nNormally, this pulling is done by looking at the RT overloaded mask (rto)\nwhich contains all the CPUs in the scheduler domain with RT tasks that are\nwaiting to run due to a higher priority RT task currently running on their\nCPU. The CPU that is about to schedule a lower priority task will grab the\nrq lock of the overloaded CPU and move the RT task from that CPU's runqueue\nto the local one and schedule the higher priority RT task.\n\nThis caused issues when a lot of CPUs would schedule a lower priority task\nat the same time. They would all try to grab the same runqueue lock of\nthe CPU with the overloaded RT tasks. Only the first CPU that got in will\nget that task. All the others would wait until they got the runqueue lock\nand see there's nothing to pull and do nothing. On systems with lots of\nCPUs, this caused a large latency (up to 500us) which is beyond what\nPREEMPT_RT is to allow.\n\nThe solution to that was to create an RT_PUSH_IPI logic. When any CPU\nwanted to pull a task, instead of grabbing the runqueue lock of the\noverloaded CPU, it would start by sending an IPI to the overloaded CPU,\nand that IPI handler would have the CPU with the waiting RT task do a push\ninstead. Then that handler would send an IPI to the next CPU with\noverloaded RT tasks, and so on. Note, after the first CPU starts this\nprocess, if another CPU wanted to do a pull, it would see that the process\nhas already begun and would only increment a counter to have the IPIs\ncontinue again.\n\nThe RT_PUSH_IPI solved the latency problem with PREEMPT_RT but could cause\na new issue with non PREEMPT_RT. Namely, softirqs run in a threaded\ncontext on PREEMPT_RT but they can run in an interrupt context in non-RT.\n\nIf an IPI lands on a CPU that has just woken up multiple RT tasks and the\ncurrent CPU is running a non RT or a low priority RT task, instead of\ndoing a push, it would simply do a schedule on that CPU. But if a softirq\nwas also executing on this CPU, the schedule would need to wait until the\nsoftirq finished. Until then, the CPU would still be considered overloaded\nas there are RT tasks still waiting to run on it.\n\nA live lock occurred on a workload that was doing heavy networking traffic\non a large machine where the softirqs would run 500us out of 750us. And it\nwould also be waking up RT tasks, causing the RT pull logic to be\nconstantly executed.\n\nWhen a softirq triggered on a CPU with RT tasks queued but not running\nyet, and the other CPUs would see this CPU as being overloaded, they would\nsend an IPI over to it. The CPU would notice that the waiting RT tasks are\nof higher priority than the currently running task and simply schedule\nthat CPU instead. But because the softirq was executing, before it could\nschedule, it would receive another IPI to do the same. The amount of IPIs\nwould slow down the currently running softirq so much that before it could\nreturn back to task context, it would execute another softirq never\nallowing the CPU to schedule. This live locked that CPU.\n\nAs RT_PUSH_IPI was created to help PREEMPT_RT, make it default off if\nPREEMPT_RT is not enabled.(CVE-2026-64374)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nwriteback: fix race between cgroup_writeback_umount() and inode_switch_wbs()\n\nWhen a container exits, the following BUG_ON() is occasionally triggered:\n\n==================================================================\n VFS: Busy inodes after unmount of sdb (ext4)\n ------------[ cut here ]------------\n kernel BUG at fs/super.c:695!\n CPU: 3 PID: 6 Comm: containerd-shim Tainted: G OE K 6.6 #1\n pstate: 63400009 (nZCv daif +PAN -UAO +TCO +DIT -SSBS BTYPE=--)\n pc : generic_shutdown_super+0xf0/0x100\n lr : generic_shutdown_super+0xf0/0x100\n Call trace:\n  generic_shutdown_super+0xf0/0x100\n  kill_block_super+0x20/0x48\n  ext4_kill_sb+0x28/0x60\n  deactivate_locked_super+0x54/0x130\n  deactivate_super+0x84/0xa0\n  cleanup_mnt+0xa4/0x140\n  __cleanup_mnt+0x18/0x28\n  task_work_run+0x78/0xe0\n  do_notify_resume+0x204/0x240\n==================================================================\n\nThe root cause is a race between cgroup_writeback_umount() and\ninode_switch_wbs()/cleanup_offline_cgwb(). There is a window between\ninode_prepare_wbs_switch() returning true and the subsequent\nwb_queue_isw() call. Following is the process that triggers the issue:\n\n      CPU A (umount)           |          CPU B (writeback)\n~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~\n                                 inode_switch_wbs/cleanup_offline_cgwb\n                                  atomic_inc(&isw_nr_in_flight)\n                                  inode_prepare_wbs_switch\n                                   -> passes SB_ACTIVE check\n                                   __iget(inode)\n generic_shutdown_super\n  sb->s_flags &= ~SB_ACTIVE\n  cgroup_writeback_umount(sb)\n   smp_mb()\n   atomic_read(&isw_nr_in_flight)\n   rcu_barrier()\n    -> no pending RCU callbacks\n   flush_workqueue(isw_wq)\n    -> nothing queued, returns\n  evict_inodes(sb)\n   -> Inode skipped as isw still holds a ref.\n  sop->put_super(sb)\n   /* destroys percpu counters */\n  -> VFS: Busy inodes after unmount!\n                                  wb_queue_isw()\n                                   queue_work(isw_wq, ...)\n                                  /* later in work function */\n                                  inode_switch_wbs_work_fn\n                                   process_inode_switch_wbs\n                                    iput() -> evict\n                                     percpu_counter_dec() // UAF!\n\nFix this by extending the RCU read-side critical section in\ninode_switch_wbs() and cleanup_offline_cgwb() to cover from\ninode_prepare_wbs_switch() through wb_queue_isw().  Since there is\nno sleep in this window, rcu_read_lock() can be used.  Then add a\nsynchronize_rcu() in cgroup_writeback_umount() before the existing\nrcu_barrier(), so that all in-flight switchers that have passed the\nSB_ACTIVE check have completed queue_work() before flush_workqueue()\nis called.\n\nThe existing rcu_barrier() is intentionally retained so this fix can\nbe backported unchanged to stable kernels (5.10.y, 6.6.y, ...) that\nstill queue switches via queue_rcu_work(). It is a no-op on current\nmainline (since commit e1b849cfa6b6 ("writeback: Avoid contention on\nwb->list_lock when switching inodes")) and is removed in a follow-up\npatch.(CVE-2026-64378)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nsmb: client: mask server-provided mode to 07777 in modefromsid\n\nWhen modefromsid is active, parse_dacl() applies the server-provided\nsub_auth[2] value from the NFS mode SID to cf_mode without masking to\n07777. Apply the correct masking, same as in the read path.(CVE-2026-64379)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nsmb: client: harden POSIX SID length parsing\n\nposix_info_sid_size() reads sid[1] to obtain the subauthority count,\nbut its existing boundary check still accepts buffers with only one\nremaining byte. Require two bytes before reading sid[1] so all client\npaths that reuse the helper reject truncated POSIX SIDs safely.(CVE-2026-64380)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nsmb: client: fix double-free in SMB2_open() replay\n\nA response-bearing attempt can return a replayable error and free its\nresponse buffer. If SMB2_open_init() fails before the next send, cleanup\nretains the previous buffer type and frees that response again.\n\nReset response bookkeeping before each attempt to prevent the stale free.(CVE-2026-64382)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nsmb: client: fix double-free in SMB2_flush() replay\n\nSMB2_flush() keeps its response buffer bookkeeping across replay\nattempts. If a replayable flush response is received and the retry then\nfails before cifs_send_recv() stores a replacement response, flush_exit\nwill free the stale response pointer a second time.\n\nReinitialize resp_buftype and rsp_iov at the top of the replay loop so\ncleanup only acts on response state produced by the current attempt.\nThis fixes a double-free without changing replay handling for successful\nrequests.(CVE-2026-64383)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nsmb: client: fix change notify replay double-free\n\nA response-bearing attempt can return a replayable error and free its\nresponse buffer. If SMB2_notify_init() fails before the next send, cleanup\nretains the previous buffer type and frees that response again.\n\nReset response bookkeeping before each attempt to prevent the stale free.(CVE-2026-64384)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nsmb: client: fix double-free in SMB2_ioctl() replay\n\nA response-bearing attempt can return a replayable error and free its\nresponse buffer. If SMB2_ioctl_init() fails before the next send, cleanup\nretains the previous buffer type and frees that response again.\n\nReset response bookkeeping before each attempt to prevent the stale free.(CVE-2026-64385)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nsmb: client: fix query_info() replay double-free\n\nA response-bearing attempt can return a replayable error and free its\nresponse buffer. If SMB2_query_info_init() fails before the next send,\ncleanup retains the previous buffer type and frees that response again.\n\nReset response bookkeeping before each attempt to prevent the stale free.(CVE-2026-64386)\n\nIn the Linux kernel, an out-of-bounds read vulnerability exists in the SMB client. smb2_check_message() has a long-standing quirk that accepts a response whose calculated length is one byte larger than the bytes actually received ("server can return one byte more due to implied bcc[0]"). This was introduced to accommodate servers that omit the trailing bcc[0] overlap byte when no data area is present. However, the exemption is applied unconditionally, regardless of whether the command actually carries a data area (has_smb2_data_area[]). When a response with a data area is subject to the +1 exemption, the reported data can extend one byte beyond the bytes actually received, causing the subsequent decoder to read past the end of the receive buffer. This is reachable during NEGOTIATE and SESSION_SETUP, before the session is established. The resulting out-of-bounds reads are visible under KASAN when mounting against a non-conforming server, affecting both the SPNEGO/negTokenInit and the NTLMSSP challenge decoders.(CVE-2026-64448)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nhwrng: virtio: clamp device-reported used.len at copy_data()\n\nrandom_recv_done() stores the device-reported used.len directly into\nvi->data_avail.  copy_data() then indexes vi->data[] using\nvi->data_idx (advanced by previous copy_data() calls) and issues a\nmemcpy() without re-validating either value against the posted\nbuffer size sizeof(vi->data) (SMP_CACHE_BYTES bytes, typically 32\nor 64).\n\nA malicious or buggy virtio-rng backend can set used.len beyond\nsizeof(vi->data), steering the memcpy() past the end of the inline\narray into adjacent kmalloc-1k slab bytes.  hwrng_fillfn() mixes\nthose bytes into the guest RNG, and guest root can also observe\nthem directly via /dev/hwrng.\n\nConcrete impact is inside the guest:\n\n - Memory-safety / hardening: any virtio-rng backend that\n   over-reports used.len causes the driver to read past vi->data\n   into unrelated slab contents.  hwrng_fillfn() is a kernel thread\n   that runs as soon as the device is probed; no guest userspace\n   interaction is required to first-trigger the OOB.\n\n - Cross-boundary leak (confidential-compute threat model): a\n   malicious hypervisor cooperating with a malicious or compromised\n   guest root userspace can use /dev/hwrng as a leak channel for\n   guest-kernel heap data.  The host sets a large used.len, guest\n   root reads /dev/hwrng, and the returned bytes contain guest\n   kernel slab contents that were adjacent to vi->data.  In\n   practice, confidential-compute guests (SEV-SNP, TDX) usually\n   disable virtio-rng entirely, so this path is narrow, but the\n   fix is still worth carrying because the underlying\n   memory-safety bug contaminates the guest RNG on any host.\n\nKASAN confirms the OOB on a 7.1-rc4 guest whose virtio-rng backend\nhas been patched to report used.len = 0x10000:\n\n  BUG: KASAN: slab-out-of-bounds in virtio_read+0x394/0x5d0\n  Read of size 64 at addr ffff88800ae0ba20 by task hwrng/52\n  Call Trace:\n   __asan_memcpy+0x23/0x60\n   virtio_read+0x394/0x5d0\n   hwrng_fillfn+0xb2/0x470\n   kthread+0x2cc/0x3a0\n  Allocated by task 1:\n   probe_common+0xa5/0x660\n   virtio_dev_probe+0x549/0xbc0\n  The buggy address belongs to the object at ffff88800ae0b800\n   which belongs to the cache kmalloc-1k of size 1024\n  The buggy address is located 0 bytes to the right of\n   allocated 544-byte region [ffff88800ae0b800, ffff88800ae0ba20)\n\nSame class of bug as commit c04db81cd028 ("net/9p: Fix buffer\noverflow in USB transport layer"), which hardened\nusb9pfs_rx_complete() against unchecked device-reported length in\nthe USB 9p transport.\n\nWith the clamp at point of use and array_index_nospec() in place,\nthe same harness boots cleanly: copy_data() returns zero for the\nbogus report, the device-supplied bytes after data_idx are\ndiscarded, and the driver issues a fresh request.(CVE-2026-64456)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nALSA: hda/cs35l41: Fix firmware load work teardown\n\ncs35l41_hda creates ALSA controls whose private data points at the\ncs35l41_hda object. The firmware load control can also queue\nfw_load_work.\n\nThose controls are not removed on component unbind, and device remove\nonly cancels fw_load_work through cs35l41_remove_dsp(). That helper is\nskipped when halo_initialized is false. With firmware_autostart\ndisabled, a firmware load can be requested before the DSP has been\ninitialized. If the component or device is removed before the queued\nwork runs, the worker can run after teardown and dereference driver\nstate that is no longer valid.\n\nTrack the created controls and remove them on unbind so no new control\ncallback can reach the driver data or queue more work. Then cancel\nfw_load_work to drain any request that was already queued. Also cancel\nthe work unconditionally during device remove before runtime PM teardown.(CVE-2026-64481)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\niio: event: Fix event FIFO reset race\n\n`iio_event_getfd()` creates the event file descriptor with\n`anon_inode_getfd()`, which allocates a new fd, creates the anonymous\nfile and installs it in the process fd table before returning to the\ncaller.\n\nThe IIO code resets the event FIFO after `anon_inode_getfd()` has returned,\nbut before `IIO_GET_EVENT_FD_IOCTL` has copied the fd number to userspace.\nBut since fd tables are shared between threads, another thread can guess\nthe newly allocated fd number and issue a `read()` on it as soon as the fd\nhas been installed.\n\nThis means the `kfifo_to_user()` in `iio_event_chrdev_read()` can run in\nparallel with the `kfifo_reset_out()` in `iio_event_getfd()`.\n\nThe kfifo documentation says that `kfifo_reset_out()` is only safe when it\nis called from the reader thread and there is only one concurrent reader.\nOtherwise it is dangerous and must be handled in the same way as\n`kfifo_reset()`.\n\nIf that happens, `kfifo_to_user()` can advance the FIFO `out` index based\non state from before the reset, after the reset has already moved the `out`\nindex to the current `in` index. That can leave the FIFO with an `out`\nindex past the `in` index. A later `read()` can then see an underflowed\nFIFO length and copy more data than the event FIFO buffer contains. This\ncan result in an out-of-bounds read and leak adjacent kernel memory to\nuserspace.\n\nMove the FIFO reset before `anon_inode_getfd()`. At that point the event fd is\nmarked busy, but the new fd has not been installed yet, so userspace cannot\naccess it while the FIFO is reset.(CVE-2026-64496)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet: openvswitch: reject oversized nested action attrs\n\nOpen vSwitch stores generated flow actions as nlattrs, whose nla_len\nfield is u16. Commit a1e64addf3ff ("net: openvswitch: remove\nmisbehaving actions length check") allowed the total sw_flow_actions\nstream to grow beyond 64 KiB, which is valid, but also removed the last\nguard preventing a generated nested action attribute from exceeding\nU16_MAX.\n\nAn oversized generated container can thus be closed with a truncated\nnla_len. A later dump or teardown then walks a structurally different\nstream than the one that was validated. In particular, an oversized\nnested CLONE/CT action may cause subsequent bytes in the generated\nstream to be interpreted as independent actions.\n\nKeep the larger total-action-stream behavior, but make nested action\nclose reject generated containers that do not fit in nla_len, and return\nthe error through all callers. For recursive SAMPLE, CLONE, DEC_TTL, and\nCHECK_PKT_LEN builders, trim resource-owning action-list tails in reverse\nconstruction order before discarding failed wrappers, so resources copied\ninto the rejected tails are released before the wrappers are removed.\n\nMost failed outer wrappers are discarded by truncating actions_len after\nchild resources have been released. CHECK_PKT_LEN also trims its parent\nafter branch resources are gone. SET/TUNNEL close failures unwind their\nknown tun_dst ownership directly, and SET_TO_MASKED has no external\nownership and truncates on close failure.(CVE-2026-64531)\n\nIn the Linux kernel, the following vulnerability has been resolved:\\n\\nperf/core: Detach event groups during remove_on_exec\\n\\nperf_event_remove_on_exec() removes events by calling\\nperf_event_exit_event(). For top-level events, this removes the event from\\nthe context with DETACH_EXIT only.\\n\\nThis can leave inconsistent group state when a removed event is a group\\nleader and the group contains siblings without remove_on_exec. If the group\\nwas active, the surviving siblings can remain active and attached to the\\nremoved leader's sibling list, but are no longer represented by a valid\\ngroup leader on the PMU context active lists.\\n\\nA later close of the removed leader uses DETACH_GROUP and can promote the\\nstill-active siblings from this stale group state. The next schedule-in can\\nthen add an already-linked active_list entry again, corrupting the PMU\\ncontext active list.\\n\\nWith DEBUG_LIST enabled, this is caught as a list_add double-add in\\nmerge_sched_in().\\n\\nFix this by detaching group relationships when remove_on_exec removes an\\nevent. This preserves the existing task-exit and revoke behavior, while\\nensuring surviving siblings are ungrouped before the removed event leaves\\nthe context.(CVE-2026-64556)\n\nIn the Linux kernel, a use-after-free (UAF) vulnerability exists caused by a non-leader exec() race condition in posix-cpu-timers. When sys_timer_delete() observes the old leader, while de_thread() executes switch_leader() and releases the old leader, a race condition occurs. Specifically, posix_cpu_timer_del() in sys_timer_delete() obtains the old leader via pid_task(), while de_thread() is executing release_task(old_leader) and setting old_leader->sighand = NULL. When lock_task_sighand() returns NULL, sys_timer_delete() frees the posix timer object. However, if the timer was armed and enqueued in p->signal (a TGID targeted timer is inherited on exec()), run_posix_cpu_timers() or other timerqueue add/delete operations will access the freed object's timerqueue node, resulting in a use-after-free. This issue similarly affects posix_cpu_timer_set() and posix_cpu_timer_rearm(). The history of this vulnerability goes back to the early days of posix CPU timers implementation.(CVE-2026-64560)\n\nIn the Linux kernel, the following vulnerability has been resolved:\\n\\nKVM: x86: Check for invalid/obsolete root *after* making MMU pages available\\n\\nCheck for a \\"stale\\" page fault, i.e. for an invalid and/or obsolete root, after making MMU pages available for the shadow MMU. If reclaiming shadow pages zaps an in-use root, i.e. marks it invalid, then KVM will attempt to map memory into an invalid root. On its own, populating an invalid root is \\"fine\\", but because child shadow pages inherit their parent's role, any children created during the map/fetch will be created as invalid pages, thus violating KVM's invariant that invalid pages are never on the list of active MMU pages.\\n\\nNote, the underlying flaw has existed since KVM first started tracking invalid roots in 2008 (commit 2e53d63acba7, \\"KVM: MMU: ignore zapped root pagetables\\"), but the true badness only came along in 2020 (Linux 5.9) with the invariant that invalid shadow pages can't be on the list of active pages.\\n\\nNote #2, inheriting role.invalid when creating child shadow pages is also far from ideal; that flaw will be addressed separately.(CVE-2026-64561)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nsmb: client: fix double-free in SMB2_close() replay\n\nA response-bearing attempt can return a replayable error and free its\nresponse buffer. If SMB2_close_init() fails before the next send, cleanup\nretains the previous buffer type and frees that response again.\n\nReset response bookkeeping before each attempt to prevent the stale free.(CVE-2026-64597)\n\nIn the Linux kernel, the following vulnerability has been resolved: ipvs: reload ip header after head reallocation. __ip_vs_get_out_rt() calls skb_ensure_writable() which may reallocate skb->head, causing the previously obtained IP header pointer to become a dangling pointer, leading to a use-after-free vulnerability.(CVE-2026-68476)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nipvs: fix more places with wrong ipv6 transport offsets\n\nSashiko reports for more incorrect IPv6 transport offsets.\n\nThe app code for TCP was assuming IPv4 network header\neven after the ipvsh argument was provided. This can\ncause problems with apps over IPv6. As for the only\nofficial app in the kernel tree (FTP) this problem is\nharmless because we use Netfilter to mangle the FTP\nports and we do not adjust the TCP seq numbers.\n\nAlso, provide correct offset of the ICMPV6 header in\nip_vs_out_icmp_v6() for correct checksum checks when\nthe IPv6 packet has extension headers.(CVE-2026-68477)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nipvs: use parsed transport offset in SCTP state lookup\n\nset_sctp_state() reads the SCTP chunk header again in order to drive the\nIPVS SCTP state table. For IPv6 it computes the offset with\nsizeof(struct ipv6hdr), while the surrounding IPVS code uses iph.len from\nip_vs_fill_iph_skb(), where ipv6_find_hdr() has already skipped\nextension headers and found the real transport header.\n\nThis makes the state machine read from the wrong offset for IPv6 SCTP\npackets that carry extension headers. For example, an INIT packet with an\n8-byte destination options header can be scheduled correctly by\nsctp_conn_schedule(), but set_sctp_state() reads the first byte of the\nSCTP verification tag as a DATA chunk type. The connection then moves\nfrom NONE to ESTABLISHED instead of INIT1, gets the longer established\ntimeout, and updates the active/inactive destination counters\nincorrectly. This happens even though the SCTP handshake has not\ncompleted.\n\nUse the parsed transport offset passed down from ip_vs_set_state() for\nthe SCTP chunk-header lookup. For IPv4 and IPv6 packets without\nextension headers this preserves the existing offset.(CVE-2026-72021)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nieee802154: admin-gate legacy LLSEC dump operations\n\nIn net/ieee802154/netlink.c, the legacy IEEE802154_NL family ops table\nbuilds the LLSEC dump entries (LLSEC_LIST_KEY, LLSEC_LIST_DEV,\nLLSEC_LIST_DEVKEY, LLSEC_LIST_SECLEVEL) with IEEE802154_DUMP() which\nsets no .flags, so generic netlink runs them ungated. The modern\nnl802154 family admin-gates the equivalent reads via\nNL802154_CMD_GET_SEC_KEY and friends with .flags = GENL_ADMIN_PERM.\n\nAny local uid that can open AF_NETLINK / NETLINK_GENERIC can resolve\nthe "802.15.4 MAC" family and dump LLSEC_LIST_KEY on any wpan netdev\nthat has an LLSEC key installed; the dump handler writes the raw\n16-byte AES-128 key bytes (IEEE802154_ATTR_LLSEC_KEY_BYTES, copied\nverbatim from struct ieee802154_llsec_key.key) into the reply.\nRecovering the AES key compromises 802.15.4 LLSEC link confidentiality\nand authenticity, since LLSEC uses CCM* and the same key authenticates\nand encrypts frames.\n\nImpact: any local uid with no capabilities can read the raw 16-byte\nAES-128 LLSEC key from the kernel keytable on any wpan netdev that has\nan administrator-installed LLSEC key, by issuing an LLSEC_LIST_KEY\ndump on the legacy IEEE802154_NL generic-netlink family.\n\nIntroduce IEEE802154_DUMP_PRIV() mirroring IEEE802154_DUMP() but\nsetting .flags = GENL_ADMIN_PERM, and use it for the four LLSEC dump\nentries. LIST_PHY and LIST_IFACE retain IEEE802154_DUMP() because the\nmodern nl802154 family exposes their equivalents to unprivileged\nreaders by design (NL802154_CMD_GET_WPAN_PHY and\nNL802154_CMD_GET_INTERFACE carry "can be retrieved by unprivileged\nusers" annotations).(CVE-2026-72049)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet: ip6_gre: require CAP_NET_ADMIN in the device netns for changelink\n\nip6gre_changelink() and ip6erspan_changelink() operate on at most two\nnetns, dev_net(dev) and the tunnel link netns t->net. They differ once\nthe device is created in or moved to a netns other than the one the\nrequest runs in. The rtnl changelink path checks CAP_NET_ADMIN only\nagainst dev_net(dev), so a caller privileged there but not in t->net can\nrewrite a tunnel that lives in t->net.\n\nGate both ops on rtnl_dev_link_net_capable() at their top, before any\nattribute is parsed.(CVE-2026-72052)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet: ipip: require CAP_NET_ADMIN in the device netns for changelink\n\nipip_changelink() operates on at most two netns, dev_net(dev) and the\ntunnel link netns t->net. They differ once the device is created in or\nmoved to a netns other than the one the request runs in. The rtnl\nchangelink path checks CAP_NET_ADMIN only against dev_net(dev), so a\ncaller privileged there but not in t->net can rewrite a tunnel that\nlives in t->net.\n\nGate ipip_changelink() on rtnl_dev_link_net_capable() at its top,\nbefore any attribute is parsed.(CVE-2026-72053)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet: ip_vti: require CAP_NET_ADMIN in the device netns for changelink\n\nvti_changelink() operates on at most two netns, dev_net(dev) and the\ntunnel link netns t->net. They differ once the device is created in or\nmoved to a netns other than the one the request runs in. The rtnl\nchangelink path checks CAP_NET_ADMIN only against dev_net(dev), so a\ncaller privileged there but not in t->net can rewrite a tunnel that\nlives in t->net.\n\nGate vti_changelink() on rtnl_dev_link_net_capable() at its top,\nbefore any attribute is parsed.(CVE-2026-72054)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet: sit: require CAP_NET_ADMIN in the device netns for changelink\n\nipip6_changelink() operates on at most two netns, dev_net(dev) and the\ntunnel link netns t->net. They differ once the device is created in or\nmoved to a netns other than the one the request runs in. The rtnl\nchangelink path checks CAP_NET_ADMIN only against dev_net(dev), so a\ncaller privileged there but not in t->net can rewrite a tunnel that\nlives in t->net.\n\nGate ipip6_changelink() on rtnl_dev_link_net_capable() at its top,\nbefore any attribute is parsed. sit was the one tunnel type not covered\nby the recent series that added this check to the other changelink()\nhandlers.(CVE-2026-72061)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet/mlx5e: macsec: fix use-after-free of metadata_dst on RX SC delete\n\nWhen an offloaded MACsec RX SC is deleted, macsec_del_rxsc_ctx() freed\nthe per-SC metadata_dst with metadata_dst_free(), which kfree()s the\nobject unconditionally and ignores the dst reference count. The RX\ndatapath in mlx5e_macsec_offload_handle_rx_skb() looks up the SC under\nrcu_read_lock() via xa_load(), takes a reference with dst_hold() and\nattaches the dst to the skb with skb_dst_set(). A reader that already\nobtained the rx_sc pointer can race with the delete path and operate on\nfreed memory.\n\nFix the owner side by dropping the reference with dst_release() instead\nof freeing unconditionally, and convert the RX datapath to\ndst_hold_safe() so a reader racing the SC delete cannot attach a dst\nwhose last reference was just dropped; only attach it when a reference\nwas actually taken.\n\nmlx5e_macsec_add_rxsc() also published sc_xarray_element via xa_alloc()\nbefore rx_sc->md_dst was allocated and initialised, so a datapath reader\nthat looked the SC up by fs_id could observe rx_sc with md_dst still\nNULL or, on weakly-ordered architectures, a non-NULL md_dst pointer\nwhose contents were not yet visible. NULL-check the xa_load() result and\nmd_dst on the datapath, and reorder add_rxsc() so the xa_alloc() publish\nhappens only after md_dst is fully initialised; the xarray RCU publish\nthen pairs with the rcu_read_lock()/xa_load() in the datapath.\n\nNote: macsec_del_rxsc_ctx() also kfree()s rx_sc->sc_xarray_element\nwithout an RCU grace period while the same datapath reads it under\nrcu_read_lock(); that is a separate pre-existing issue left to a\nfollow-up patch.\n\nFound by 0sec automated security-research tooling (https://0sec.ai).(CVE-2026-72072)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ndm-log: fix a bitset_size overflow on 32bit machines\n\nCommit c20e36b7631d ("dm log: fix out-of-bounds write due to\nregion_count overflow") made sure that region_count could fit in an\nunsigned int. But the bitmap memory isn't allocated based on\nregion_count. It uses bitset_size (a size_t variable). The first step of\ncalculating bitset_size is to set it to region_count, rounded up to a\nmultiple of BITS_PER_LONG. If region_size is less than BITS_PER_LONG\nsmaller than UINT_MAX, it will get rounded up to 2^32. On a 32bit\narchitecture, this will make bitset_size wrap around to 0 and fail,\ndespite region_count being valid.\n\nSince bitset_size gets divided by 8, it can hold any valid region_count.\nIt just needs a special case to handle the rollover. If it is 0, the\nvalue rolled over, and bitset size should be set to the number of bytes\nneeded to hold 2^32 bits.(CVE-2026-72105)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nbpf,fork: wipe ->bpf_storage before bailouts that access it\n\nCurrently, copy_process() can bail out to free_task() before p->bpf_storage\nhas been initialized, with this call graph (shown here for the\n!CONFIG_MEMCG case):\n\ncopy_process\n  dup_task_struct\n    arch_dup_task_struct\n      [copies the entire task_struct, including ->bpf_storage member]\n  [RLIMIT_NPROC check fails]\n  delayed_free_task\n    free_task\n      bpf_task_storage_free\n        rcu_dereference(task->bpf_storage)\n        bpf_local_storage_destroy\n\nIn this case, the nascent task's ->bpf_storage member that\nbpf_local_storage_destroy() operates on is a plain copy of the parent's\n->bpf_storage pointer, not a real initialized pointer.\nThis leads to badness (kernel hangs, UAF).\n\nThis is reachable as long as the process calling fork() has been inserted\ninto a task storage map.(CVE-2026-72110)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnvmet-rdma: handle inline data with a nonzero offset\n\nnvmet_rdma_use_inline_sg() maps the host-controlled inline data offset\ninto the per-command inline scatterlist.  The bounds check admits any\noffset with off + len <= inline_data_size, but the mapping still assumes\nthe data begins in the first inline page:\n\n\tsg->offset = off;\n\tsg->length = min_t(int, len, PAGE_SIZE - off);\n\nWhen a port is configured with inline_data_size > PAGE_SIZE (settable up\nto max(SZ_16K, PAGE_SIZE)), an offset in (PAGE_SIZE, inline_data_size]\nmakes "PAGE_SIZE - off" underflow, so sg->length is set to ~4 GiB and\nthe block backend reads far past the first inline page.  num_pages(len)\nalso ignores the offset, so an in-bounds offset whose [off, off+len)\nspan crosses a page boundary under-counts the scatterlist.\n\nMap the offset properly: split it into a page index and an in-page\noffset, start the scatterlist at that page, and size the page count from\npage_off + len.  Because the request scatterlist may now start at\ninline_sg[page_idx] rather than inline_sg[0], generalize the inline-SGL\nidentity test in nvmet_rdma_release_rsp() to a range test; otherwise the\npersistent inline scatterlist is mistaken for an allocated one and\nnvmet_req_free_sgls() frees an inline page (and warns in\nfree_large_kmalloc()).(CVE-2026-72129)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ntpm: Make the TPM character devices non-seekable\n\nThe TPM character devices expose a sequential command/response\ninterface, but their open handlers leave FMODE_PREAD and FMODE_PWRITE\nenabled.\n\nAfter a command leaves a response pending, pread(fd, buf, 16, 0x1400)\npasses 0x1400 as *off to tpm_common_read(). The transfer length is\nbounded by response_length, but the offset is used unchecked when\nforming data_buffer + *off. A sufficiently large offset therefore causes\nan out-of-bounds heap read through copy_to_user() and, if the copy\nsucceeds, an out-of-bounds zero-write through the following memset().\n\nPositional I/O does not provide coherent semantics for this interface.\nAn arbitrary pread offset cannot represent how much of a response has\nbeen consumed sequentially. The write callback always stores a command\nat the start of data_buffer, while pwrite() does not update file->f_pos\nand can leave the sequential read cursor stale.\n\nCall nonseekable_open() from both open handlers. This removes\nFMODE_PREAD and FMODE_PWRITE, causing positional reads and writes to\nfail with -ESPIPE before reaching the TPM callbacks, and explicitly\nmarks the files non-seekable. Normal read() and write() continue to use\nthe existing sequential f_pos cursor, leaving the response state machine\nunchanged.\n\nTested on Linux 6.12 with KASAN and a swtpm TPM2 device:\n\n - sequential partial reads returned the complete response\n - pread() and preadv() with offset 0x1400 returned -ESPIPE\n - pwrite() and pwritev() with offset zero returned -ESPIPE\n - the pending response remained intact after the rejected operations\n - a subsequent normal command/response cycle completed normally\n - no KASAN report was produced.(CVE-2026-72135)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nxfrm: xfrm_interface: require CAP_NET_ADMIN in the device netns for changelink\n\nxfrmi_changelink() operates on at most two netns, dev_net(dev) and the\ninterface link netns xi->net. They differ once the device is created in\nor moved to a netns other than the one the request runs in. The rtnl\nchangelink path checks CAP_NET_ADMIN only against dev_net(dev), so a\ncaller privileged there but not in xi->net can rewrite an interface that\nlives in xi->net.\n\nGate xfrmi_changelink() on rtnl_dev_link_net_capable() at its top,\nbefore any attribute is parsed.(CVE-2026-72136)\n\nIn the Linux kernel, the following vulnerability has been resolved: net: thunderbolt: Fix frags[] overflow by bounding frame_count. tbnet_poll() assembles a multi-frame ThunderboltIP packet into one skb. The first frame goes into the skb linear area and every further frame is added as a page fragment. A packet of frame_count frames therefore ends up with frame_count - 1 fragments. tbnet_check_frame() only bounds the peer supplied frame_count to TBNET_RING_SIZE / 4 (64), which is far above MAX_SKB_FRAGS (17 by default). A peer that sends a packet of 19 or more small frames pushes nr_frags past MAX_SKB_FRAGS, so skb_add_rx_frag() writes past skb_shinfo()->frags[] and corrupts memory after the shared info.(CVE-2026-72157)\n\nIn the Linux kernel, the following vulnerability has been resolved: mm/mm_init: fix uninitialized struct pages for ZONE_DEVICE. If DAX memory is hotplugged into an unoccupied subsection of an early section, section_activate() reuses the unoptimized boot memmap. However, compound_nr_pages() still assumes that vmemmap optimization is in effect and initializes only the reduced number of struct pages. As a result, the remaining tail struct pages are left uninitialized, which can later lead to unexpected behavior or crashes. Fix this by treating early sections as unoptimized when calculating how many struct pages to initialize.(CVE-2026-72172)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nSUNRPC: Bound-check xdr_buf_to_bvec() stores before writing\n\nxdr_buf_to_bvec() writes a bio_vec into the caller's array before\ntesting whether that slot is in range, and the head branch performs\nthe store with no check at all. When the caller's budget is exactly\nused up, the next store lands one element past the end of the array.\nThe overflow label returns count - 1, which masks the surplus store\nbut cannot undo it.\n\nrq_bvec, the array passed by nfsd_vfs_write(), is allocated to\nexactly rq_maxpages entries with no slack. The OOB store can land in\nadjacent slab memory; the bv_len and bv_offset fields written there\nare derived from client-supplied RPC payload sizes.\n\nMove the in-range check ahead of the store in the head, page-loop,\nand tail branches. With the check at the top of each sequence, count\nis incremented only after a successful store, so the overflow label\ncan return count directly.(CVE-2026-72217)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nsunrpc: wait for in-flight TLS handshake callback when cancel loses race\n\nWhen wait_for_completion_interruptible_timeout() in\nsvc_tcp_handshake() returns 0 (timeout) or -ERESTARTSYS (signal) and\ntls_handshake_cancel() then returns false, handshake_complete() has\nwon the cancellation race: it has set HANDSHAKE_F_REQ_COMPLETED and\nis about to invoke svc_tcp_handshake_done(), but the callback's\nside effects on xpt_flags and on svsk->sk_handshake_done have not\nyet committed.\n\nThe current code reads xpt_flags immediately to decide whether the\nsession succeeded. Two races result.\n\nIf the callback has executed set_bit(XPT_TLS_SESSION) but not yet\nclear_bit(XPT_HANDSHAKE), svc_tcp_handshake() sees a session,\nenqueues the transport, and returns. svc_xprt_received() then\nclears XPT_BUSY, a worker thread picks the transport up, the\ndispatcher in svc_handle_xprt() observes XPT_HANDSHAKE still set,\nand xpo_handshake is invoked a second time. That svc_tcp_handshake()\ncalls init_completion(&svsk->sk_handshake_done) while the original\ncallback concurrently calls complete_all() on it, corrupting the\nembedded swait_queue.\n\nIf the callback has set HANDSHAKE_F_REQ_COMPLETED but not yet\nentered svc_tcp_handshake_done(), svc_tcp_handshake() reads\nXPT_TLS_SESSION as clear and tears the connection down even though\nthe handshake is about to succeed.\n\nWait for the callback to commit before inspecting xpt_flags. The\ncompletion is guaranteed to fire because handshake_complete()\ninvokes svc_tcp_handshake_done() unconditionally once it has set\nHANDSHAKE_F_REQ_COMPLETED.(CVE-2026-72221)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nsunrpc: pin svc_xprt across the asynchronous TLS handshake callback\n\nsvc_tcp_handshake() stores the raw svc_xprt pointer in\ntls_handshake_args.ta_data and submits the request through\ntls_server_hello_x509(). The handshake core takes only\nsock_hold(req->hr_sk); nothing references the embedding struct\nsvc_sock that svc_tcp_handshake_done() reaches via container_of().\n\nTwo close races leave the in-flight callback writing through a freed\nsvc_sock. svc_sock_free() calls tls_handshake_cancel() and discards\nits return value: a false return means handshake_complete() has\nalready set HANDSHAKE_F_REQ_COMPLETED but hp_done() may not have\nfinished, yet svc_sock_free() proceeds to kfree(svsk). The\ncancel-loser fall-through inside svc_tcp_handshake() itself produces\nthe same window: when wait_for_completion_interruptible_timeout()\nreturns <= 0 (timeout or signal) and tls_handshake_cancel() returns\nfalse, the function does not drain, returns, and svc_handle_xprt()\ncalls svc_xprt_received(), which clears XPT_BUSY and can drop the\nlast reference. A concurrent close then runs svc_sock_free() while\nsvc_tcp_handshake_done() is still updating xpt_flags and walking\nsvsk->sk_handshake_done.\n\nThe corruption surfaces as set_bit/clear_bit RMW into the freed\nxpt_flags slab slot and as complete_all() walking and writing the\nfreed wait_queue_head_t list embedded in sk_handshake_done -- a\nslab-corruption primitive, not a benign read. The path is reachable\non any TLS-enabled NFS server whenever a connection close overlaps\nthe tlshd downcall delivery window; the interruptible wait means\nsignal delivery suffices, not just SVC_HANDSHAKE_TO expiry.\n\nTake svc_xprt_get(xprt) immediately before tls_server_hello_x509()\nso the in-flight callback owns its own reference. Release it on the\ntwo edges where the callback is guaranteed not to fire -- submission\nfailure from tls_server_hello_x509() and a successful\ntls_handshake_cancel() -- and at the tail of\nsvc_tcp_handshake_done() after complete_all().\n\n[cel: rewrote commit message to describe the actual change](CVE-2026-72222)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nbatman-adv: retrieve ethhdr after potential skb realloc on RX\n\npskb_may_pull() in batadv_interface_rx() could reallocate the buffer behind\nthe skb. Variables which were pointing to the old buffer need to be\nreassigned to avoid an use-after-free.\n\nThis was done correctly for the VLAN header but missed for the ethernet\nheader which is later used for the TT and AP isolation handling.(CVE-2026-72235)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nKVM: Move kvm_io_bus_get_dev() locking responsibilities to callers\n\nkvm_io_bus_get_dev() returns a device that is only matched by the\naddress, and nothing else. This can cause a lifetime issue if\nthe matched device is not the expected type, as by the time\nthe caller can introspect the object, it might be gone (the srcu\nlock having been dropped).\n\nGiven that there is only a single user of this helper, the simplest\noption is to move the locking responsibility to the caller, which\ncan keep the srcu lock held for as long as it wants.\n\nNote that this aligns with other kvm_io_bus*() helpers, which\nalready require the srcu lock to be held by the callers.(CVE-2026-72282)\n\nIn the Linux kernel, the following vulnerability has been resolved: smb: client: fix overflow in passthrough ioctl bounds check. smb2_ioctl_query_info() validates the PASSTHRU_FSCTL response payload before copying it to userspace. The payload offset and length both come from 32-bit fields. The bounds check currently adds OutputOffset and qi.input_buffer_length directly, so the addition can wrap in 32-bit arithmetic before the result is compared against the response buffer length. A malicious server can use a large OutputOffset and a small OutputCount to make the wrapped sum pass the bounds check. The later copy_to_user() then reads from io_rsp + OutputOffset, outside the response buffer, leading to an out-of-bounds read.(CVE-2026-72310)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ndm era: fix NULL pointer dereference in metadata_open()\n\nmetadata_open() returns NULL when kzalloc_obj() fails, but the\ncaller era_ctr() only checks IS_ERR(md).  Since IS_ERR(NULL)\nreturns false, the NULL pointer is treated as a valid result\nand later assigned to era->md, leading to a NULL pointer\ndereference when the metadata is accessed.\n\nFix this by returning ERR_PTR(-ENOMEM) on allocation failure,\nconsistent with dm-cache-metadata.c, dm-thin-metadata.c, and\ndm-clone-metadata.c which all use ERR_PTR(-ENOMEM) for the\nsame pattern.(CVE-2026-72316)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nSUNRPC: pin upper rpc_clnt across the TLS connect_worker\n\nThe TLS connect path has a use-after-free: nothing pins the\nupper rpc_clnt across the delayed connect_worker. xs_connect()\nstores task->tk_client in sock_xprt::clnt as a raw pointer\nand queues the worker; for TLS-secured transports that worker\nis xs_tcp_tls_setup_socket(), which reads several fields out\nof the saved pointer (cl_timeout, cl_program, cl_prog,\ncl_vers, cl_cred, cl_stats) to construct the args for the\ninner handshake rpc_clnt.\n\nThe xprt does not reference the rpc_clnt; the rpc_clnt\nreferences the xprt. xs_destroy() does cancel the\nconnect_worker, but it runs only when the xprt's refcount\ndrops to zero, which cannot happen until the rpc_clnt\nreleases its cl_xprt reference in rpc_free_client_work().\nWhen a TLS handshake fails fatally (for example, an mTLS\nmount whose client cert does not match the server), the\nconnecting task is woken with -EACCES and exits, the mount\ncaller invokes rpc_shutdown_client(), and the upper rpc_clnt\nis freed before the queued connect_worker fires.\nxs_tcp_tls_setup_socket() then dereferences the freed clnt,\nproducing the refcount_t underflow Michael Nemanov reported.\n\nTake a reference on the upper rpc_clnt in xs_connect() for\nTLS transports via a new rpc_hold_client() helper, and drop\nit in the connect_worker's exit path with rpc_release_client().\nThe xprt_lock_connect() / xprt_unlock_connect() pairing\nalready serialises xs_connect() with xs_tcp_tls_setup_socket(),\nso the take and release are balanced one-for-one.\n\nThe non-TLS connect worker (xs_tcp_setup_socket) never reads\nsock_xprt::clnt, so leave that path alone and avoid the\nclnt-holds-xprt-holds-clnt cycle that would otherwise prevent\nxprt destruction.(CVE-2026-72317)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ncifs: validate DFS referral string offsets\n\nparse_dfs_referrals() validates that the response header and referral\narray fit in the received buffer, but each referral also contains string\noffsets supplied by the server.\n\nThose offsets are used to compute the DfsPath and NetworkAddress string\npointers without checking whether they still point inside the response\nbuffer. A malformed referral can therefore make the computed pointer\nexceed the end of the buffer. The resulting negative max_len is then\npassed to cifs_strndup_from_utf16(), and the non-Unicode path forwards it\nto kstrndup() as a size_t, allowing strnlen() to read out of bounds.\n\nValidate each string offset before deriving the string pointer.(CVE-2026-72318)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nipvs: ensure inner headers in ICMP errors are in headroom\n\nSashiko points out that after stripping the outer headers\nwith pskb_pull() we should ensure the inner IP headers\nin ICMP errors from tunnels are present in the skb headroom\nfor functions like ipv4_update_pmtu(), icmp_send() and\nIP_VS_DBG().\n\nAlso, add more checks for the length of the inner headers.(CVE-2026-72319)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet/tls: Consume empty data records in tls_sw_read_sock()\n\nA peer may send a zero-length TLS application_data record; TLS 1.3\nexplicitly permits these as a traffic-analysis countermeasure (RFC\n8446, Section 5.1). After decryption such a record has full_len ==\n0. tls_sw_read_sock() hands it to the read_actor, which has no\npayload to consume and returns zero. The loop treats a zero return\nas backpressure (used <= 0), requeues the skb at the head of\nrx_list, and stops. rx_list is serviced head-first on the next\ncall, so the empty record is dequeued, fails the same way, and is\nrequeued again; every later record on the connection is blocked\nbehind it.\n\ntls_sw_recvmsg() does not stall on this: a zero-length data record\ncopies nothing and falls through to consume_skb(). Mirror that in\nthe read_sock() path by recognizing an empty data record before\nthe actor runs, consuming it, and continuing.(CVE-2026-72330)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nqede: fix off-by-one in BD ring consumption on build_skb failure\n\nqede_rx_build_skb() and qede_tpa_rx_build_skb() do not check for a\nNULL return from qede_build_skb(). When it returns NULL under memory\npressure, the functions still consume a BD from the ring before\nreturning NULL. The callers then recycle additional BDs, resulting in\none extra BD being consumed (off-by-one). This desynchronizes the BD\nring, which can corrupt DMA page reference counts and lead to SLUB\nfreelist corruption.\n\nCommit 4e910dbe3650 ("qede: confirm skb is allocated before using")\nadded a NULL check inside qede_build_skb() to prevent a NULL pointer\ndereference, but did not address the missing NULL checks in the\ncallers, making this off-by-one reachable.\n\nFix this by adding NULL checks for the return value of\nqede_build_skb() in both qede_rx_build_skb() and\nqede_tpa_rx_build_skb(), returning NULL immediately before any BD ring\nmanipulation.(CVE-2026-72339)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet/mlx5e: Fix HV VHCA stats agent registration race\n\nmlx5e_hv_vhca_stats_create() registers the stats agent through\nmlx5_hv_vhca_agent_create(). The helper publishes the agent in\nhv_vhca->agents[type] under agents_lock and immediately schedules an\nasynchronous control invalidation on the HV VHCA workqueue before\nreturning to mlx5e.\n\nThe asynchronous invalidation invokes the control agent's invalidate\ncallback, which reads the hypervisor control block and forwards the\ncommand to mlx5e_hv_vhca_stats_control(). That callback may either:\n\n  - call cancel_delayed_work_sync(&priv->stats_agent.work), or\n  - call queue_delayed_work(priv->wq, &sagent->work, sagent->delay).\n\nHowever, the delayed_work and priv->stats_agent.agent are only\ninitialized after mlx5_hv_vhca_agent_create() returns to mlx5e:\n\n    agent = mlx5_hv_vhca_agent_create(...);   /* publish + invalidate */\n    ...\n    priv->stats_agent.agent = agent;          /* too late */\n    INIT_DELAYED_WORK(&priv->stats_agent.work, ...); /* too late */\n\nIf the asynchronous control path runs before the two assignments\nabove, it can:\n\n  - Operate on an uninitialized delayed_work whose timer.function is\n    NULL. queue_delayed_work() calls add_timer() unconditionally, so\n    when the timer expires the timer softirq invokes a NULL function\n    pointer.\n  - Re-initialize the timer later through INIT_DELAYED_WORK() while\n    the timer is already enqueued in the timer wheel, corrupting the\n    hlist (entry.pprev cleared while the previous bucket node still\n    points at this entry).\n  - When the worker eventually runs, mlx5e_hv_vhca_stats_work() reads\n    sagent->agent (NULL) and dereferences it inside\n    mlx5_hv_vhca_agent_write().\n\nFix this by:\n\n  - Initializing priv->stats_agent.work before invoking\n    mlx5_hv_vhca_agent_create(), so the work is always in a valid\n    state when the control callback observes it.\n  - Adding a struct mlx5_hv_vhca_agent **ctx_update out-parameter\n    to mlx5_hv_vhca_agent_create(). The helper writes the agent\n    pointer to *ctx_update before publishing into hv_vhca->agents[]\n    and triggering the agents_update flow, so any callback\n    subsequently invoked from that flow already sees a valid\n    priv->stats_agent.agent. This avoids having the control\n    callback participate in agent initialization.\n\nWhile at it, access priv->stats_agent.agent with\nREAD_ONCE()/WRITE_ONCE() for the cross-CPU access with the worker, and\nclear priv->stats_agent.buf on the agent_create() failure path.(CVE-2026-72342)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nseg6: validate SRH length before reading fixed fields\n\nseg6_validate_srh() reads fixed SRH fields such as srh->type and\nsrh->hdrlen before checking that the supplied length covers the fixed\nstruct ipv6_sr_hdr fields.\n\nThe BPF SEG6 encap path reaches this with a BPF program-supplied pointer\nand length: bpf_lwt_push_encap() and the SEG6 local BPF END_B6 and\nEND_B6_ENCAP actions call bpf_push_seg6_encap(), which forwards the\nlength to seg6_validate_srh() with no minimum-size guard.  A 2-byte SEG6\nencap header can therefore make the validator read srh->type at offset 2\nbeyond the caller-supplied buffer.\n\nReject lengths shorter than the fixed SRH at the top of\nseg6_validate_srh(), before any field is read.  This fixes the BPF helper\npath and keeps the common validator robust.(CVE-2026-72400)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nice: fix FDIR CTRL VSI resource leak in ice_reset_all_vfs()\n\nResetting all VFs causes resource leak on VFs with FDIR filters\nenabled as CTRL VSIs are only invalidated and not freed. Fix by using\nice_vf_ctrl_vsi_release() instead of ice_vf_ctrl_invalidate_vsi() which\naligns behavior with the ice_reset_vf() function.\n\nReproduction:\n  echo 1 > /sys/class/net/$pf/device/sriov_numvfs\n  ethtool -N $vf flow-type ether proto 0x9000 action 0\n  echo 1 > /sys/class/net/$pf/device/reset(CVE-2026-72425)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nxfrm: validate selector family and prefixlen during match\n\nsyzbot reported a shift-out-of-bounds in xfrm_selector_match()\ndue to AF_UNSPEC selector with large prefixlen (e.g. 128) matched\nagainst IPv4 flow (when XFRM_STATE_AF_UNSPEC is set).\n\nFix this by:\n\n- Rejecting mismatched families in xfrm_selector_match.\n- Returning false in addr4_match if prefixlen > 32.\n- Returning false in addr_match if prefixlen > 128 (prevents overflow).(CVE-2026-72450)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\napparmor: aa_label_alloc use aa_label_free on alloc failure\n\naa_label_alloc() allocates a secid before allocating or taking the label\nproxy. If the later proxy step fails, the error path only freed the label\nmemory, leaking any resources initialized by aa_label_init().\n\nUse aa_label_free() on the failure path so partially initialized labels\nrelease their secid and other label resources before the backing memory is\nfreed.(CVE-2026-72459)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\napparmor: check label build before no_new_privs test\n\naa_change_profile() builds a replacement label with\nfn_label_build_in_scope() before the no_new_privs subset check. The build\nhelper can fail and return NULL or an ERR_PTR, but the result was passed\nto aa_label_is_unconfined_subset() before the existing IS_ERR_OR_NULL()\ncheck.\n\nReuse the existing target-label build failure handling immediately after\nthe build. This preserves the current audit handling while preventing the\nsubset helper from dereferencing an invalid label.(CVE-2026-72460)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nxprtrdma: Repost Receive buffers for malformed replies\n\nrpcrdma_wc_receive() decrements the transport's Receive count for\nevery completion before it dispatches a successful Receive to\nrpcrdma_reply_handler(). The handler must post a replacement\nReceive WR before returning unless ownership of the rep has moved\nelsewhere, as on the backchannel path.\n\nCommit 2ae50ad68cd7 ("xprtrdma: Close window between waking RPC\nsenders and posting Receives") moved the Receive refill out of\nrpcrdma_wc_receive(), where it had run ahead of every reply, into\nrpcrdma_reply_handler() so that the responder's credit grant could\nbe parsed before reposting. The bad-version and short-reply exits\nnever reach that refill: they recycle the rep and return without\ncalling rpcrdma_post_recvs().\n\nA remote peer can therefore drain the client's posted Receive\nqueue by sending a sustained stream of replies that are shorter\nthan the fixed transport header or that carry an unrecognized\nRPC/RDMA version. Each such reply consumes one posted Receive\nwithout replacing it. Once the queue empties, the peer's next\nSend finds no posted Receive and the transport stalls until\nreconnect.\n\nRoute both malformed-reply exits through the shared repost tail\nafter recycling the rep, refilling against buf->rb_credits, the\nmost recent accepted credit grant. Neither exit updates the\ncongestion window, so RPCs admitted under the previous grant\nremain in flight awaiting replies. A smaller refill target would\nlet a stream of malformed replies ratchet the posted Receive count\ndown to the batch floor while the congestion window still admits\nrb_credits RPCs; a burst of valid replies to those RPCs could then\noverrun the posted Receives, and because the client connects with\nrnr_retry_count of zero, a single RNR NAK terminates the\nconnection. Refilling against rb_credits also restores the target\nthat applied to malformed replies before commit 2ae50ad68cd7\n("xprtrdma: Close window between waking RPC senders and posting\nReceives") when rpcrdma_post_recvs() computed it from rb_credits\ninternally. rb_credits is at least one from connection\nestablishment onward, so the repost path always keeps Receives\nposted.(CVE-2026-72464)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nxprtrdma: Sanitize the reply credit grant after parsing\n\nThe out_norqst exit in rpcrdma_reply_handler() branches away before\nthe credit clamp, so a reply that matches no pending request reaches\nout_post carrying the raw credit value parsed from the wire.\nrpcrdma_post_recvs() does not bound its @needed argument: the refill\nloop allocates and chains Receive WRs until the count is satisfied or\nallocation fails. A peer that sends a well-formed reply carrying an\nunknown XID and an inflated credit grant therefore drives rep\nallocation and Receive posting past re_max_requests on every such\nreply.\n\nMove the clamp to immediately after the credit field is parsed,\nahead of the first branch that can reach out_post, so every later\nconsumer sees a sanitized value. The cwnd update stays on the\nmatched-request path.(CVE-2026-72465)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nxprtrdma: Fix bcall rep leak and unbounded peek\n\nrpcrdma_is_bcall() decodes a reply's first words to decide whether\nthe frame is a backchannel call. Two issues in that decode path\nlet a short or malformed reply leak the receive buffer and drain\nthe Receive queue.\n\nFirst, the speculative peek\n\n    p = xdr_inline_decode(xdr, 0);\n    /* five p++ reads follow */\n\nasks xdr_inline_decode() for zero bytes, which returns xdr->p\nwithout consulting xdr->end. The five subsequent __be32 reads can\nthen walk up to 20 bytes past the wire payload into stale regbuf\ncontents and misclassify the reply as a backchannel call.\n\nSecond, after the post-peek\n\n    p = xdr_inline_decode(xdr, 3 * sizeof(*p));\n    if (unlikely(!p))\n            return true;\n\nthe short-header arm returns true without calling\nrpcrdma_bc_receive_call(). The contract with the caller is that a\ntrue return transfers ownership of rep to the backchannel path:\n\n    rpcrdma_reply_handler()\n      if (rpcrdma_is_bcall(r_xprt, rep))\n              return;        /* bare return, skips out_post */\n      ...\n    out_post:\n      rpcrdma_post_recvs(r_xprt, credits + ...);\n\nBecause rpcrdma_bc_receive_call() never ran, no one took rep, but\nrpcrdma_reply_handler still bare-returns past rpcrdma_rep_put()\nand rpcrdma_post_recvs(). The rep, with its persistently\nDMA-mapped receive buffer, is orphaned on rb_all_reps and freed\nonly at transport teardown. This completion reposts nothing, so\nits slot is reclaimed only when a later forward-channel reply\nreaches out_post and rpcrdma_post_recvs() allocates a fresh rep to\nbackfill; absent that traffic the Receive queue drains and the\npeer's Sends draw RNR NAKs.\n\nFix by consulting xdr->end after the zero-length peek so the five\n__be32 reads cannot run unless 20 bytes of wire payload remain. A\nbyte-precise comparison against xdr->end is required because a\nnon-4-aligned receive rounds the stream's word count up past the\ntrue payload. Also return false from the short-header arm so the\nreply falls through the normal out_norqst cleanup chain\n(rpcrdma_rep_put() plus rpcrdma_post_recvs()).(CVE-2026-72466)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nxprtrdma: Decouple req recycling from RPC completion\n\nrl_kref formerly served two distinct lifetimes through a single\nrefcount: it gated when a Reply could wake its RPC task, and it\ngated when an rpcrdma_req could return to its free pool. The\nmarshal path took the Send-side reference only when SGEs needed\nDMA-unmap (sc_unmap_count > 0), which made a Send carrying only\npre-registered buffers an exception: the Reply handler dropped\nrl_kref from 1 to 0 and freed the req while the HCA might still\nbe DMA-reading from its send buffer.\n\nGive rl_kref a narrower job. The RPC layer takes one reference\nwhen slot allocation hands a req out. rpcrdma_prepare_send_sges()\ntakes a Send-side reference unconditionally after WR preparation\nsucceeds. xprt_rdma_free_slot() and xprt_rdma_bc_free_rqst() drop\nthe RPC-layer reference; rpcrdma_sendctx_unmap() drops the\nSend-side reference. The req returns to its free pool only after\nboth owners have signed off.\n\nThe existing kref_init(&req->rl_kref) call in\nrpcrdma_prepare_send_sges() is removed. Initialization moves to\nthe slot-allocation paths (xprt_rdma_alloc_slot and\nrpcrdma_bc_rqst_get), and the release callback re-arms rl_kref\nbefore the req returns to a free pool. A re-init in the marshal\npath would discard the RPC-layer reference that already exists\non entry.\n\nThree invariants follow:\n\n  - Any rpcrdma_req held by an rpc_rqst has rl_kref >= 1.\n    xprt_rdma_alloc_slot(), rpcrdma_bc_rqst_get(), and the\n    backlog-wake branch in xprt_rdma_alloc_slot() each kref_init\n    rl_kref before publishing the req. Without this invariant,\n    an RPC task that aborts between slot allocation and marshal\n    (gss_refresh failure or signal during call_connect, for\n    example) would drive xprt_release() ->\n    xprt_rdma_free_slot() -> kref_put against a refcount of\n    zero, saturating refcount_t and stranding the slot.\n\n  - The Send-side reference is taken only after WR prep\n    succeeds. A mapping failure in rpcrdma_prepare_send_sges()\n    runs rpcrdma_sendctx_cancel(), which DMA-unmaps the sendctx\n    and clears sc_req without touching rl_kref. The sendctx\n    ring walks in rpcrdma_sendctx_put_locked() and\n    rpcrdma_sendctxs_destroy() skip entries with sc_req == NULL,\n    so a burst of -EIO marshal failures cannot hold reqs off\n    rb_send_bufs.\n\n  - The release callback re-arms rl_kref so the next consumer\n    enters with the invariant satisfied.\n\nReplies now complete the RPC directly. rpcrdma_reply_handler()\ncalls rpcrdma_complete_rqst() in place of kref_put on the\nnon-LocalInv branch. The LocalInv branch already completes the\nRPC from frwr_unmap_async() and is unaffected.\n\nBecause Send-side references can now outlive RPC completion,\nconnection teardown drains sendctx entries whose unsignaled\nSends never had a later signaled completion to walk the ring.\nrpcrdma_sendctxs_destroy() walks the active range and runs\nrpcrdma_sendctx_unmap() on each entry with a non-NULL sc_req\nbefore the request buffers are reset, and is moved ahead of\nrpcrdma_reqs_reset() in rpcrdma_xprt_disconnect() so the reqs\nare still in their pre-reset state when the Send-side refs are\nreleased.\n\nThe drain creates a teardown-ordering hazard on the backchannel\npath. With the new lifetime, releasing a bc_prealloc req from\nrpcrdma_req_release() re-adds it to bc_pa_list. The disconnect\nin xprt_rdma_destroy() runs after xprt_destroy_backchannel() has\nalready emptied bc_pa_list, so the drained reqs would otherwise\nleak. xprt_rdma_destroy() now runs xprt_rdma_bc_destroy(xprt, 0)\na second time after the disconnect to reclaim them.(CVE-2026-72473)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nfs/ntfs3: add bounds check to run_get_highest_vcn()\n\nrun_get_highest_vcn() parses a packed NTFS mapping-pairs buffer without\nany length bound, relying solely on a 0x00 terminator to stop.  A\ncrafted $LogFile UpdateMappingPairs record whose embedded attribute\ncontains mapping-pairs runs without a terminator causes the function to\nread past the slab allocation, triggering a KASAN slab-out-of-bounds\nread on mount.\n\nThe sibling function run_unpack() received an analogous bounds-check in\ncommit b62567bca474 ("ntfs3: add buffer boundary checks to run_unpack()"),\nbut run_get_highest_vcn() was missed.\n\nTake a run_buf_size parameter and reject any run header whose payload\nwould extend past the buffer end, mirroring the pattern used by\nrun_unpack().  The caller in fslog.c passes the remaining attribute\nbytes after the mapping-pairs offset.\n\nKASAN report (on mainline v7.1 merge window HEAD):\n\n  BUG: KASAN: slab-out-of-bounds in run_get_highest_vcn+0x3c0/0x410\n  Read of size 1 at addr ffff88800e2d5400 by task mount/72\n  Call Trace:\n   run_get_highest_vcn+0x3c0/0x410\n   do_action.isra.0+0x3ba8/0x7b50\n   log_replay+0x9ddd/0x10200\n   ntfs_loadlog_and_replay+0x4ad/0x610\n   ntfs_fill_super+0x214a/0x4540(CVE-2026-72478)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nbpf: Guard __get_user acesss with access_ok for uprobe_multi data\n\nAs reported by sashiko [1] we need to use access_ok to check the user\nspace data bounds before we use __get-user to get it.\n\n[1] https://lore.kernel.org/bpf/(CVE-2026-74258)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\npower: supply: core: fix supplied_from allocations\n\nIf dts property power-supplies has multiple values, then accessing to\npsy->supplied_from[i-1] in __power_supply_populate_supplied_from will\noverrun supplied_from array.(CVE-2026-74271)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ntipc: require net admin for TIPCv2 netlink mutators\n\nTIPCv2 registers mutating generic-netlink operations without admin\npermission flags. Generic netlink only checks CAP_NET_ADMIN when an\noperation sets GENL_ADMIN_PERM or GENL_UNS_ADMIN_PERM, so a local\nunprivileged process can currently change TIPC state through commands\nsuch as TIPC_NL_NET_SET, TIPC_NL_KEY_SET, TIPC_NL_KEY_FLUSH, and\nbearer enable/disable.\n\nThe legacy TIPC netlink API already checks netlink_net_capable(...,\nCAP_NET_ADMIN) for administrative commands. Give the TIPCv2 mutators\nthe equivalent generic-netlink gate. Use GENL_UNS_ADMIN_PERM, which\nmaps to the same namespace-aware CAP_NET_ADMIN check that\nnetlink_net_capable() performs, so the behaviour matches the legacy\npath and keeps working for CAP_NET_ADMIN holders in a non-initial user\nnamespace (containers).\n\nA QEMU/KASAN repro run as uid/gid 65534 with zero effective\ncapabilities previously succeeded in changing the network id and node\nidentity, setting and flushing key material, and enabling/disabling a\nUDP bearer. With this patch applied the same operations fail with\n-EPERM.(CVE-2026-74283)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nsctp: validate embedded address parameter length\n\nsctp_verify_asconf() and sctp_verify_param() only validate ADD_IP, DEL_IP,\nand SET_PRIMARY parameters against a fixed minimum size of sizeof(struct\nsctp_addip_param) + sizeof(struct sctp_paramhdr). This ensures the outer\nparameter is large enough to contain an embedded address parameter header,\nbut does not verify that the embedded address parameter's declared length\nfits within the bounds of the outer parameter.\n\nLater, sctp_process_param() and sctp_process_asconf_param() extract the\nembedded address parameter and pass it to af->from_addr_param(), which uses\nthe address parameter length to parse the variable-length address payload.\nA malformed peer can therefore advertise an embedded address parameter\nlength that exceeds the remaining bytes in the enclosing parameter.\n\nValidate that addr_param->p.length does not exceed the space available\nafter the sctp_addip_param header before processing the embedded address\nparameter. Reject malformed parameters when the embedded address length\nextends beyond the enclosing parameter bounds.\n\nThis prevents out-of-bounds reads when parsing malformed parameters carried\nin INIT or ASCONF processing paths.(CVE-2026-74287)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nbpf: Tighten cgroup storage cookie checks for prog arrays\n\nThe fix in commit abad3d0bad72 ("bpf: Fix oob access in cgroup local\nstorage") is still incomplete. The prog-array compatibility check\ntreats a program with no cgroup storage as compatible with any stored\nstorage cookie. This allows a storage-less program to bridge a tail\ncall chain between an entry program and a storage-using callee even\nthough cgroup local storage at runtime still follows the caller's\ncontext, that is, A -> B(no storage) -> C(storage) path.\n\nRequiring exact cookie equality would break the legitimate case of a\nstorage-less leaf program being tail called from a storage-using one.\nInstead, only accept a zero storage cookie if the program cannot\nperform tail calls itself. This keeps A -> B(no storage) working\nwhile rejecting the A -> B(no storage) -> C(storage) bridge.(CVE-2026-74305)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nbpf: Reject sleepable BPF_LSM_CGROUP programs at load time\n\nThe cgroup shim runs under rcu_read_lock_dont_migrate(), so we should\nnot attach any sleepable BPF programs there. Add support to the verifier\nto explicitly reject attempts to load sleepable BPF programs destined\nfor LSM cgroup attachment.\n\nWithout this, we get the following splat from a BPF_LSM_CGROUP\nprogram marked BPF_F_SLEEPABLE attached to file_open when it calls\nbpf_get_dentry_xattr():\n\n  BUG: sleeping function called from invalid context at kernel/locking/rwsem.c:1567\n  in_atomic(): 0, irqs_disabled(): 0, non_block: 0, pid: 34317, name: load\n  preempt_count: 0, expected: 0\n  RCU nest depth: 2, expected: 0\n  Call Trace:\n   down_read+0x76/0x480\n   ext4_xattr_get+0x11f/0x700\n   __vfs_getxattr+0xf0/0x150\n   bpf_get_dentry_xattr+0xbb/0xf0\n   bpf_prog_e76a298dac9218c6_test_open+0x6a/0x85\n   __cgroup_bpf_run_lsm_current+0x326/0x840\n   bpf_trampoline_6442534646+0x62/0x14d\n   security_file_open+0x34/0x60\n   do_dentry_open+0x340/0x1260\n   vfs_open+0x7a/0x440\n   path_openat+0x1bac/0x30a0\n\nlibbpf provides a .s named section variant for every sleepable\nprogram type except lsm_cgroup, reflecting that per-cgroup LSM programs\nare intended to only run in a non-sleepable context.\n\nThe above splat was obtained by bypassing libbpf by using bpf(2)\ndirectly.(CVE-2026-74338)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nbpf: Clear rb node linkage when freeing bpf_rb_root\n\nbpf_rb_root_free() detaches the root by copying the current rb_root_cached\nand then replacing the live root with RB_ROOT_CACHED. It then walks the\ncopied root and drops each object contained in the tree.\n\nThis leaves the rb node state intact while dropping the object. If the\nobject is refcounted and survives the drop, its bpf_rb_node_kern still\ncontains an owner pointer to the freed root and stale rb tree linkage. If\na later bpf_rb_root allocation reuses the same address, bpf_rbtree_remove()\ncan incorrectly pass the owner check and call rb_erase_cached() on a node\nwhose rb pointers belong to the old tree.\n\nMirror the list draining behavior by marking nodes as busy while the root\nis being detached, then clear the rb node and release the owner before\ndropping the containing object. This makes surviving nodes unowned and\nsafe to reject from remove or accept for a later add.(CVE-2026-74344)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nbpf: fix UAF by restoring RCU-delayed inode freeing in bpffs\n\ncommit 4f375ade6aa9 ("bpf: Avoid RCU context warning when unpinning\nhtab with internal structs") moved inode cleanup from ->free_inode()\ninto ->destroy_inode() to avoid sleeping in RCU context when calling\nbpf_any_put(). However this removed the RCU delay on freeing the\ninode itself and the cached symlink body (i_link), both of which\ncan be accessed by RCU pathwalk (pick_link, may_lookup etc.).\n\nThis causes a use-after-free when a concurrent unlinkat() drops the\nlast inode reference and destroy_inode() frees the inode immediately,\nwhile another task is still walking the path in RCU mode and reads\ninode->i_opflags (offset +2) inside current_time() -> is_mgtime().\n\nKASAN reports:\n  BUG: KASAN: slab-use-after-free in is_mgtime include/linux/fs.h:2313\n  Read of size 2 at addr ffff8880407e4282 (offset +2 = i_opflags)\n\nThe rules (per Al Viro):\n  ->destroy_inode()  called immediately, can sleep, use for blocking\n                     cleanup e.g. bpf_any_put()\n  ->free_inode()     called after RCU grace period, use for freeing\n                     inode and anything RCU-accessible e.g. i_link\n\nFix: split the two concerns properly:\n  - keep bpf_any_put() in bpf_destroy_inode() since it is blocking\n    and needs to run promptly\n  - introduce bpf_free_inode() to handle kfree(i_link) and\n    free_inode_nonrcu() with proper RCU delay, preventing the UAF(CVE-2026-74363)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nRDMA/rxe: Copy WQE to local buffer in non-SRQ receive path\n\nFor non-SRQ QPs, the responder reads WQE fields directly from the\nshared queue buffer mapped into userspace. This allows a malicious\nuser to modify fields like num_sge or sge entries while the kernel\nis processing the WQE, leading to out-of-bounds reads in\nrxe_resp_check_length() and copy_data().\n\nIntroduce get_recv_wqe() that validates num_sge and copies the WQE\nto a kernel-local buffer before processing, matching the approach\nalready used for SRQ WQEs in get_srq_wqe(). The srq_wqe buffer is\nreused since SRQ and non-SRQ paths are mutually exclusive per QP.(CVE-2026-74377)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nRDMA/rxe: Fix TOCTOU heap overflow in get_srq_wqe\n\nget_srq_wqe() reads wqe->dma.num_sge from the shared receive queue\nbuffer, which is mapped into userspace. It validates num_sge against\nmax_sge, but then re-reads the same field to calculate the memcpy\nsize. A concurrent userspace thread can modify num_sge between\nvalidation and use, causing a heap buffer overflow when copying the\nWQE into qp->resp.srq_wqe.\n\nRead num_sge into a local variable and use it for both the bounds\ncheck and the size calculation.(CVE-2026-74378)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nRDMA/srpt: fix integer overflow in immediate data length check\n\nimm_buf->len is a user-controlled uint32_t received from the network.\nAdding it to imm_data_offset without overflow checking allows a\nmalicious initiator to send len=0xFFFFFFFF, causing req_size to wrap\naround to a small value, bypassing the bounds check, and subsequently\npassing a ~4GB length to sg_init_one().\n\nUse check_add_overflow() to detect wrapping before the comparison.(CVE-2026-74394)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nIB/mlx5: Fix transport-domain rollback and initialize lb mutex earlier\n\nmlx5_ib_alloc_transport_domain() allocates a transport domain and then\nmay fail in mlx5_ib_enable_lb(). In that case, the allocated TD is leaked.\n\nFix this by deallocating the TD when mlx5_ib_enable_lb() returns an\nerror. Also return 0 explicitly in the no-loopback-capability success\nbranch, and move dev->lb.mutex initialization to mlx5_ib_stage_init_init().(CVE-2026-74397)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nipv6: addrconf: bail out of dad_failure when state is no longer POSTDAD\n\naddrconf_dad_failure() transitions ifp->state from DAD to POSTDAD\nvia addrconf_dad_end(), which drops ifp->lock on return.  The lock\nis re-acquired after net_info_ratelimited().  A concurrent\nipv6_del_addr() can take the lock in that window, set ifp->state\nto DEAD and run list_del_rcu(&ifp->if_list).\n\naddrconf_dad_failure() then overwrites DEAD with ERRDAD at errdad:\nand schedules a new dad_work.  The work calls ipv6_del_addr()\nagain, hitting the already-poisoned list entry:\n\n  general protection fault: 0000 [#1] SMP NOPTI\n  CPU: 4 PID: 217 Comm: kworker/4:1\n  Workqueue: ipv6_addrconf addrconf_dad_work\n  RIP: 0010:ipv6_del_addr+0xe9/0x280\n  RAX: dead000000000122\n  Call Trace:\n   addrconf_dad_stop+0x113/0x140\n   addrconf_dad_work+0x28c/0x430\n   process_one_work+0x1eb/0x3b0\n   worker_thread+0x4d/0x400\n   kthread+0x104/0x140\n   ret_from_fork+0x35/0x40\n\nFold the addrconf_dad_end() logic into addrconf_dad_failure() under\na single ifp->lock critical section.  The STABLE_PRIVACY branch\ntemporarily drops ifp->lock around address regeneration, so at\nlock_errdad: verify the state is still POSTDAD before transitioning\nto ERRDAD; bail out otherwise to avoid overwriting a state set by\nanother path while the lock was released.(CVE-2026-74398)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nvxlan: Fix potential null-ptr-deref in vxlan_gro_prepare_receive().\n\nudp_tunnel_sock_release() could set sk->sk_user_data to NULL\nwhile vxlan_gro_prepare_receive() is running.\n\nLet's check if rcu_dereference_sk_user_data() is NULL after\nskb_gro_remcsum_init().(CVE-2026-74406)","modified":"2026-09-05T15:16:48.225761008Z","published":"2026-09-05T15:04:08Z","upstream":["CVE-2025-71112","CVE-2025-71123","CVE-2026-23243","CVE-2026-23244","CVE-2026-23253","CVE-2026-23268","CVE-2026-23271","CVE-2026-23317","CVE-2026-23319","CVE-2026-23359","CVE-2026-23383","CVE-2026-23388","CVE-2026-43078","CVE-2026-46028","CVE-2026-52980","CVE-2026-53055","CVE-2026-53246","CVE-2026-53384","CVE-2026-63800","CVE-2026-63830","CVE-2026-63886","CVE-2026-63887","CVE-2026-63888","CVE-2026-63889","CVE-2026-63891","CVE-2026-63898","CVE-2026-63899","CVE-2026-63901","CVE-2026-63912","CVE-2026-63917","CVE-2026-63919","CVE-2026-63920","CVE-2026-63921","CVE-2026-63924","CVE-2026-63926","CVE-2026-63928","CVE-2026-63944","CVE-2026-63945","CVE-2026-63946","CVE-2026-63952","CVE-2026-63956","CVE-2026-63968","CVE-2026-63971","CVE-2026-63974","CVE-2026-63975","CVE-2026-63976","CVE-2026-63984","CVE-2026-63985","CVE-2026-63992","CVE-2026-63993","CVE-2026-63994","CVE-2026-64002","CVE-2026-64003","CVE-2026-64015","CVE-2026-64025","CVE-2026-64032","CVE-2026-64046","CVE-2026-64047","CVE-2026-64073","CVE-2026-64076","CVE-2026-64077","CVE-2026-64088","CVE-2026-64089","CVE-2026-64095","CVE-2026-64097","CVE-2026-64098","CVE-2026-64106","CVE-2026-64109","CVE-2026-64112","CVE-2026-64113","CVE-2026-64114","CVE-2026-64118","CVE-2026-64126","CVE-2026-64136","CVE-2026-64191","CVE-2026-64219","CVE-2026-64222","CVE-2026-64237","CVE-2026-64247","CVE-2026-64298","CVE-2026-64299","CVE-2026-64304","CVE-2026-64305","CVE-2026-64306","CVE-2026-64312","CVE-2026-64313","CVE-2026-64317","CVE-2026-64319","CVE-2026-64320","CVE-2026-64322","CVE-2026-64323","CVE-2026-64324","CVE-2026-64355","CVE-2026-64364","CVE-2026-64374","CVE-2026-64378","CVE-2026-64379","CVE-2026-64380","CVE-2026-64382","CVE-2026-64383","CVE-2026-64384","CVE-2026-64385","CVE-2026-64386","CVE-2026-64448","CVE-2026-64456","CVE-2026-64481","CVE-2026-64496","CVE-2026-64531","CVE-2026-64556","CVE-2026-64560","CVE-2026-64561","CVE-2026-64597","CVE-2026-68476","CVE-2026-68477","CVE-2026-72021","CVE-2026-72049","CVE-2026-72052","CVE-2026-72053","CVE-2026-72054","CVE-2026-72061","CVE-2026-72072","CVE-2026-72105","CVE-2026-72110","CVE-2026-72129","CVE-2026-72135","CVE-2026-72136","CVE-2026-72157","CVE-2026-72172","CVE-2026-72217","CVE-2026-72221","CVE-2026-72222","CVE-2026-72235","CVE-2026-72282","CVE-2026-72310","CVE-2026-72316","CVE-2026-72317","CVE-2026-72318","CVE-2026-72319","CVE-2026-72330","CVE-2026-72339","CVE-2026-72342","CVE-2026-72400","CVE-2026-72425","CVE-2026-72450","CVE-2026-72459","CVE-2026-72460","CVE-2026-72464","CVE-2026-72465","CVE-2026-72466","CVE-2026-72473","CVE-2026-72478","CVE-2026-74258","CVE-2026-74271","CVE-2026-74283","CVE-2026-74287","CVE-2026-74305","CVE-2026-74338","CVE-2026-74344","CVE-2026-74363","CVE-2026-74377","CVE-2026-74378","CVE-2026-74394","CVE-2026-74397","CVE-2026-74398","CVE-2026-74406"],"database_specific":{"severity":"Critical"},"references":[{"type":"ADVISORY","url":"https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2026-3704"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-71112"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-71123"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-23243"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-23244"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-23253"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-23268"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-23271"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-23317"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-23319"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-23359"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-23383"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-23388"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-43078"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-46028"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-52980"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-53055"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-53246"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-53384"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-63800"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-63830"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-63886"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-63887"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-63888"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-63889"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-63891"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-63898"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-63899"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-63901"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-63912"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-63917"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-63919"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-63920"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-63921"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-63924"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-63926"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-63928"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-63944"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-63945"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-63946"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-63952"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-63956"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-63968"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-63971"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-63974"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-63975"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-63976"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-63984"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-63985"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-63992"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-63993"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-63994"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-64002"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-64003"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-64015"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-64025"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-64032"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-64046"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-64047"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-64073"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-64076"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-64077"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-64088"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-64089"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-64095"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-64097"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-64098"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-64106"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-64109"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-64112"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-64113"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-64114"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-64118"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-64126"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-64136"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-64191"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-64219"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-64222"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-64237"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-64247"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-64298"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-64299"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-64304"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-64305"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-64306"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-64312"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-64313"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-64317"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-64319"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-64320"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-64322"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-64323"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-64324"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-64355"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-64364"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-64374"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-64378"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-64379"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-64380"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-64382"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-64383"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-64384"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-64385"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-64386"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-64448"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-64456"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-64481"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-64496"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-64531"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-64556"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-64560"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-64561"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-64597"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-68476"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-68477"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-72021"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-72049"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-72052"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-72053"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-72054"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-72061"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-72072"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-72105"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-72110"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-72129"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-72135"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-72136"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-72157"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-72172"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-72217"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-72221"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-72222"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-72235"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-72282"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-72310"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-72316"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-72317"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-72318"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-72319"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-72330"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-72339"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-72342"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-72400"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-72425"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-72450"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-72459"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-72460"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-72464"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-72465"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-72466"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-72473"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-72478"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-74258"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-74271"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-74283"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-74287"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-74305"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-74338"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-74344"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-74363"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-74377"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-74378"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-74394"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-74397"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-74398"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-74406"}],"affected":[{"package":{"name":"kernel","ecosystem":"openEuler:24.03-LTS-SP3","purl":"pkg:rpm/openEuler/kernel&distro=openEuler-24.03-LTS-SP3"},"ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"6.6.0-145.3.29.160.oe2403sp3"}]}],"ecosystem_specific":{"aarch64":["bpftool-6.6.0-145.3.29.160.oe2403sp3.aarch64.rpm","bpftool-debuginfo-6.6.0-145.3.29.160.oe2403sp3.aarch64.rpm","kernel-6.6.0-145.3.29.160.oe2403sp3.aarch64.rpm","kernel-debuginfo-6.6.0-145.3.29.160.oe2403sp3.aarch64.rpm","kernel-debugsource-6.6.0-145.3.29.160.oe2403sp3.aarch64.rpm","kernel-devel-6.6.0-145.3.29.160.oe2403sp3.aarch64.rpm","kernel-extra-modules-6.6.0-145.3.29.160.oe2403sp3.aarch64.rpm","kernel-headers-6.6.0-145.3.29.160.oe2403sp3.aarch64.rpm","kernel-source-6.6.0-145.3.29.160.oe2403sp3.aarch64.rpm","kernel-tools-6.6.0-145.3.29.160.oe2403sp3.aarch64.rpm","kernel-tools-debuginfo-6.6.0-145.3.29.160.oe2403sp3.aarch64.rpm","kernel-tools-devel-6.6.0-145.3.29.160.oe2403sp3.aarch64.rpm","perf-6.6.0-145.3.29.160.oe2403sp3.aarch64.rpm","perf-debuginfo-6.6.0-145.3.29.160.oe2403sp3.aarch64.rpm","python3-perf-6.6.0-145.3.29.160.oe2403sp3.aarch64.rpm","python3-perf-debuginfo-6.6.0-145.3.29.160.oe2403sp3.aarch64.rpm"],"src":["kernel-6.6.0-145.3.29.160.oe2403sp3.src.rpm"],"x86_64":["bpftool-6.6.0-145.3.29.160.oe2403sp3.x86_64.rpm","bpftool-debuginfo-6.6.0-145.3.29.160.oe2403sp3.x86_64.rpm","kernel-6.6.0-145.3.29.160.oe2403sp3.x86_64.rpm","kernel-debuginfo-6.6.0-145.3.29.160.oe2403sp3.x86_64.rpm","kernel-debugsource-6.6.0-145.3.29.160.oe2403sp3.x86_64.rpm","kernel-devel-6.6.0-145.3.29.160.oe2403sp3.x86_64.rpm","kernel-extra-modules-6.6.0-145.3.29.160.oe2403sp3.x86_64.rpm","kernel-headers-6.6.0-145.3.29.160.oe2403sp3.x86_64.rpm","kernel-source-6.6.0-145.3.29.160.oe2403sp3.x86_64.rpm","kernel-tools-6.6.0-145.3.29.160.oe2403sp3.x86_64.rpm","kernel-tools-debuginfo-6.6.0-145.3.29.160.oe2403sp3.x86_64.rpm","kernel-tools-devel-6.6.0-145.3.29.160.oe2403sp3.x86_64.rpm","perf-6.6.0-145.3.29.160.oe2403sp3.x86_64.rpm","perf-debuginfo-6.6.0-145.3.29.160.oe2403sp3.x86_64.rpm","python3-perf-6.6.0-145.3.29.160.oe2403sp3.x86_64.rpm","python3-perf-debuginfo-6.6.0-145.3.29.160.oe2403sp3.x86_64.rpm"]},"database_specific":{"source":"https://repo.openeuler.org/security/data/osv/OESA-2026-3704.json"}}],"schema_version":"1.9.0","severity":[{"type":"CVSS_V3","score":"CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H"}]}