{"id":"OESA-2026-2675","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\ndrm/i915/gt: Fix timeline left held on VMA alloc error\n\nThe following error has been reported sporadically by CI when a test\nunbinds the i915 driver on a ring submission platform:\n\n<4> [239.330153] ------------[ cut here ]------------\n<4> [239.330166] i915 0000:00:02.0: [drm] drm_WARN_ON(dev_priv->mm.shrink_count)\n<4> [239.330196] WARNING: CPU: 1 PID: 18570 at drivers/gpu/drm/i915/i915_gem.c:1309 i915_gem_cleanup_early+0x13e/0x150 [i915]\n...\n<4> [239.330640] RIP: 0010:i915_gem_cleanup_early+0x13e/0x150 [i915]\n...\n<4> [239.330942] Call Trace:\n<4> [239.330944]  <TASK>\n<4> [239.330949]  i915_driver_late_release+0x2b/0xa0 [i915]\n<4> [239.331202]  i915_driver_release+0x86/0xa0 [i915]\n<4> [239.331482]  devm_drm_dev_init_release+0x61/0x90\n<4> [239.331494]  devm_action_release+0x15/0x30\n<4> [239.331504]  release_nodes+0x3d/0x120\n<4> [239.331517]  devres_release_all+0x96/0xd0\n<4> [239.331533]  device_unbind_cleanup+0x12/0x80\n<4> [239.331543]  device_release_driver_internal+0x23a/0x280\n<4> [239.331550]  ? bus_find_device+0xa5/0xe0\n<4> [239.331563]  device_driver_detach+0x14/0x20\n...\n<4> [357.719679] ---[ end trace 0000000000000000 ]---\n\nIf the test also unloads the i915 module then that's followed with:\n\n<3> [357.787478] =============================================================================\n<3> [357.788006] BUG i915_vma (Tainted: G     U  W        N ): Objects remaining on __kmem_cache_shutdown()\n<3> [357.788031] -----------------------------------------------------------------------------\n<3> [357.788204] Object 0xffff888109e7f480 @offset=29824\n<3> [357.788670] Allocated in i915_vma_instance+0xee/0xc10 [i915] age=292729 cpu=4 pid=2244\n<4> [357.788994]  i915_vma_instance+0xee/0xc10 [i915]\n<4> [357.789290]  init_status_page+0x7b/0x420 [i915]\n<4> [357.789532]  intel_engines_init+0x1d8/0x980 [i915]\n<4> [357.789772]  intel_gt_init+0x175/0x450 [i915]\n<4> [357.790014]  i915_gem_init+0x113/0x340 [i915]\n<4> [357.790281]  i915_driver_probe+0x847/0xed0 [i915]\n<4> [357.790504]  i915_pci_probe+0xe6/0x220 [i915]\n...\n\nCloser analysis of CI results history has revealed a dependency of the\nerror on a few IGT tests, namely:\n- igt@api_intel_allocator@fork-simple-stress-signal,\n- igt@api_intel_allocator@two-level-inception-interruptible,\n- igt@gem_linear_blits@interruptible,\n- igt@prime_mmap_coherency@ioctl-errors,\nwhich invisibly trigger the issue, then exhibited with first driver unbind\nattempt.\n\nAll of the above tests perform actions which are actively interrupted with\nsignals.  Further debugging has allowed to narrow that scope down to\nDRM_IOCTL_I915_GEM_EXECBUFFER2, and ring_context_alloc(), specific to ring\nsubmission, in particular.\n\nIf successful then that function, or its execlists or GuC submission\nequivalent, is supposed to be called only once per GEM context engine,\nfollowed by raise of a flag that prevents the function from being called\nagain.  The function is expected to unwind its internal errors itself, so\nit may be safely called once more after it returns an error.\n\nIn case of ring submission, the function first gets a reference to the\nengine's legacy timeline and then allocates a VMA.  If the VMA allocation\nfails, e.g. when i915_vma_instance() called from inside is interrupted\nwith a signal, then ring_context_alloc() fails, leaving the timeline held\nreferenced.  On next I915_GEM_EXECBUFFER2 IOCTL, another reference to the\ntimeline is got, and only that last one is put on successful completion.\nAs a consequence, the legacy timeline, with its underlying engine status\npage's VMA object, is still held and not released on driver unbind.\n\nGet the legacy timeline only after successful allocation of the context\nengine's VMA.\n\nv2: Add a note on other submission methods (Krzysztof Karas):\n    Both execlists and GuC submission use lrc_alloc() which seems free\n    from a similar issue.\n\n(cherry picked from commit cc43422b3cc79eacff4c5a8ba0d224688ca9dd4f)(CVE-2025-38389)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nima: don't clear IMA_DIGSIG flag when setting or removing non-IMA xattr\n\nCurrently when both IMA and EVM are in fix mode, the IMA signature will\nbe reset to IMA hash if a program first stores IMA signature in\nsecurity.ima and then writes/removes some other security xattr for the\nfile.\n\nFor example, on Fedora, after booting the kernel with "ima_appraise=fix\nevm=fix ima_policy=appraise_tcb" and installing rpm-plugin-ima,\ninstalling/reinstalling a package will not make good reference IMA\nsignature generated. Instead IMA hash is generated,\n\n    # getfattr -m - -d -e hex /usr/bin/bash\n    # file: usr/bin/bash\n    security.ima=0x0404...\n\nThis happens because when setting security.selinux, the IMA_DIGSIG flag\nthat had been set early was cleared. As a result, IMA hash is generated\nwhen the file is closed.\n\nSimilarly, IMA signature can be cleared on file close after removing\nsecurity xattr like security.evm or setting/removing ACL.\n\nPrevent replacing the IMA file signature with a file hash, by preventing\nthe IMA_DIGSIG flag from being reset.\n\nHere's a minimal C reproducer which sets security.selinux as the last\nstep which can also replaced by removing security.evm or setting ACL,\n\n    #include <stdio.h>\n    #include <sys/xattr.h>\n    #include <fcntl.h>\n    #include <unistd.h>\n    #include <string.h>\n    #include <stdlib.h>\n\n    int main() {\n        const char* file_path = "/usr/sbin/test_binary";\n        const char* hex_string = "030204d33204490066306402304";\n        int length = strlen(hex_string);\n        char* ima_attr_value;\n        int fd;\n\n        fd = open(file_path, O_WRONLY|O_CREAT|O_EXCL, 0644);\n        if (fd == -1) {\n            perror("Error opening file");\n            return 1;\n        }\n\n        ima_attr_value = (char*)malloc(length / 2 );\n        for (int i = 0, j = 0; i < length; i += 2, j++) {\n            sscanf(hex_string + i, "%2hhx", &ima_attr_value[j]);\n        }\n\n        if (fsetxattr(fd, "security.ima", ima_attr_value, length/2, 0) == -1) {\n            perror("Error setting extended attribute");\n            close(fd);\n            return 1;\n        }\n\n        const char* selinux_value= "system_u:object_r:bin_t:s0";\n        if (fsetxattr(fd, "security.selinux", selinux_value, strlen(selinux_value), 0) == -1) {\n            perror("Error setting extended attribute");\n            close(fd);\n            return 1;\n        }\n\n        close(fd);\n\n        return 0;\n    }(CVE-2025-68183)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ncrash: fix crashkernel resource shrink\n\nWhen crashkernel is configured with a high reservation, shrinking its\nvalue below the low crashkernel reservation causes two issues:\n\n1. Invalid crashkernel resource objects\n2. Kernel crash if crashkernel shrinking is done twice\n\nFor example, with crashkernel=200M,high, the kernel reserves 200MB of high\nmemory and some default low memory (say 256MB).  The reservation appears\nas:\n\ncat /proc/iomem | grep -i crash\naf000000-beffffff : Crash kernel\n433000000-43f7fffff : Crash kernel\n\nIf crashkernel is then shrunk to 50MB (echo 52428800 >\n/sys/kernel/kexec_crash_size), /proc/iomem still shows 256MB reserved:\naf000000-beffffff : Crash kernel\n\nInstead, it should show 50MB:\naf000000-b21fffff : Crash kernel\n\nFurther shrinking crashkernel to 40MB causes a kernel crash with the\nfollowing trace (x86):\n\nBUG: kernel NULL pointer dereference, address: 0000000000000038\nPGD 0 P4D 0\nOops: 0000 [#1] PREEMPT SMP NOPTI\n<snip...>\nCall Trace: <TASK>\n? __die_body.cold+0x19/0x27\n? page_fault_oops+0x15a/0x2f0\n? search_module_extables+0x19/0x60\n? search_bpf_extables+0x5f/0x80\n? exc_page_fault+0x7e/0x180\n? asm_exc_page_fault+0x26/0x30\n? __release_resource+0xd/0xb0\nrelease_resource+0x26/0x40\n__crash_shrink_memory+0xe5/0x110\ncrash_shrink_memory+0x12a/0x190\nkexec_crash_size_store+0x41/0x80\nkernfs_fop_write_iter+0x141/0x1f0\nvfs_write+0x294/0x460\nksys_write+0x6d/0xf0\n<snip...>\n\nThis happens because __crash_shrink_memory()/kernel/crash_core.c\nincorrectly updates the crashk_res resource object even when\ncrashk_low_res should be updated.\n\nFix this by ensuring the correct crashkernel resource object is updated\nwhen shrinking crashkernel memory.(CVE-2025-68198)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nipvs: fix ipv4 null-ptr-deref in route error path\n\nThe IPv4 code path in __ip_vs_get_out_rt() calls dst_link_failure()\nwithout ensuring skb->dev is set, leading to a NULL pointer dereference\nin fib_compute_spec_dst() when ipv4_link_failure() attempts to send\nICMP destination unreachable messages.\n\nThe issue emerged after commit ed0de45a1008 ("ipv4: recompile ip options\nin ipv4_link_failure") started calling __ip_options_compile() from\nipv4_link_failure(). This code path eventually calls fib_compute_spec_dst()\nwhich dereferences skb->dev. An attempt was made to fix the NULL skb->dev\ndereference in commit 0113d9c9d1cc ("ipv4: fix null-deref in\nipv4_link_failure"), but it only addressed the immediate dev_net(skb->dev)\ndereference by using a fallback device. The fix was incomplete because\nfib_compute_spec_dst() later in the call chain still accesses skb->dev\ndirectly, which remains NULL when IPVS calls dst_link_failure().\n\nThe crash occurs when:\n1. IPVS processes a packet in NAT mode with a misconfigured destination\n2. Route lookup fails in __ip_vs_get_out_rt() before establishing a route\n3. The error path calls dst_link_failure(skb) with skb->dev == NULL\n4. ipv4_link_failure() → ipv4_send_dest_unreach() →\n   __ip_options_compile() → fib_compute_spec_dst()\n5. fib_compute_spec_dst() dereferences NULL skb->dev\n\nApply the same fix used for IPv6 in commit 326bf17ea5d4 ("ipvs: fix\nipv6 route unreach panic"): set skb->dev from skb_dst(skb)->dev before\ncalling dst_link_failure().\n\nKASAN: null-ptr-deref in range [0x0000000000000328-0x000000000000032f]\nCPU: 1 PID: 12732 Comm: syz.1.3469 Not tainted 6.6.114 #2\nRIP: 0010:__in_dev_get_rcu include/linux/inetdevice.h:233\nRIP: 0010:fib_compute_spec_dst+0x17a/0x9f0 net/ipv4/fib_frontend.c:285\nCall Trace:\n  <TASK>\n  spec_dst_fill net/ipv4/ip_options.c:232\n  spec_dst_fill net/ipv4/ip_options.c:229\n  __ip_options_compile+0x13a1/0x17d0 net/ipv4/ip_options.c:330\n  ipv4_send_dest_unreach net/ipv4/route.c:1252\n  ipv4_link_failure+0x702/0xb80 net/ipv4/route.c:1265\n  dst_link_failure include/net/dst.h:437\n  __ip_vs_get_out_rt+0x15fd/0x19e0 net/netfilter/ipvs/ip_vs_xmit.c:412\n  ip_vs_nat_xmit+0x1d8/0xc80 net/netfilter/ipvs/ip_vs_xmit.c:764(CVE-2025-68813)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nipv6: BUG() in pskb_expand_head() as part of calipso_skbuff_setattr()\n\nThere exists a kernel oops caused by a BUG_ON(nhead < 0) at\nnet/core/skbuff.c:2232 in pskb_expand_head().\nThis bug is triggered as part of the calipso_skbuff_setattr()\nroutine when skb_cow() is passed headroom > INT_MAX\n(i.e. (int)(skb_headroom(skb) + len_delta) < 0).\n\nThe root cause of the bug is due to an implicit integer cast in\n__skb_cow(). The check (headroom > skb_headroom(skb)) is meant to ensure\nthat delta = headroom - skb_headroom(skb) is never negative, otherwise\nwe will trigger a BUG_ON in pskb_expand_head(). However, if\nheadroom > INT_MAX and delta <= -NET_SKB_PAD, the check passes, delta\nbecomes negative, and pskb_expand_head() is passed a negative value for\nnhead.\n\nFix the trigger condition in calipso_skbuff_setattr(). Avoid passing\n"negative" headroom sizes to skb_cow() within calipso_skbuff_setattr()\nby only using skb_cow() to grow headroom.\n\nPoC:\n\tUsing `netlabelctl` tool:\n\n        netlabelctl map del default\n        netlabelctl calipso add pass doi:7\n        netlabelctl map add default address:0::1/128 protocol:calipso,7\n\n        Then run the following PoC:\n\n        int fd = socket(AF_INET6, SOCK_DGRAM, IPPROTO_UDP);\n\n        // setup msghdr\n        int cmsg_size = 2;\n        int cmsg_len = 0x60;\n        struct msghdr msg;\n        struct sockaddr_in6 dest_addr;\n        struct cmsghdr * cmsg = (struct cmsghdr *) calloc(1,\n                        sizeof(struct cmsghdr) + cmsg_len);\n        msg.msg_name = &dest_addr;\n        msg.msg_namelen = sizeof(dest_addr);\n        msg.msg_iov = NULL;\n        msg.msg_iovlen = 0;\n        msg.msg_control = cmsg;\n        msg.msg_controllen = cmsg_len;\n        msg.msg_flags = 0;\n\n        // setup sockaddr\n        dest_addr.sin6_family = AF_INET6;\n        dest_addr.sin6_port = htons(31337);\n        dest_addr.sin6_flowinfo = htonl(31337);\n        dest_addr.sin6_addr = in6addr_loopback;\n        dest_addr.sin6_scope_id = 31337;\n\n        // setup cmsghdr\n        cmsg->cmsg_len = cmsg_len;\n        cmsg->cmsg_level = IPPROTO_IPV6;\n        cmsg->cmsg_type = IPV6_HOPOPTS;\n        char * hop_hdr = (char *)cmsg + sizeof(struct cmsghdr);\n        hop_hdr[1] = 0x9; //set hop size - (0x9 + 1) * 8 = 80\n\n        sendmsg(fd, &msg, 0);(CVE-2025-71085)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ndriver core: platform: use generic driver_override infrastructure\n\nWhen a driver is probed through __driver_attach(), the bus' match()\ncallback is called without the device lock held, thus accessing the\ndriver_override field without a lock, which can cause a UAF.\n\nFix this by using the driver-core driver_override infrastructure taking\ncare of proper locking internally.\n\nNote that calling match() from __driver_attach() without the device lock\nheld is intentional. [1](CVE-2026-31527)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nusbip: validate number_of_packets in usbip_pack_ret_submit()\n\nWhen a USB/IP client receives a RET_SUBMIT response,\nusbip_pack_ret_submit() unconditionally overwrites\nurb->number_of_packets from the network PDU. This value is\nsubsequently used as the loop bound in usbip_recv_iso() and\nusbip_pad_iso() to iterate over urb->iso_frame_desc[], a flexible\narray whose size was fixed at URB allocation time based on the\n*original* number_of_packets from the CMD_SUBMIT.\n\nA malicious USB/IP server can set number_of_packets in the response\nto a value larger than what was originally submitted, causing a heap\nout-of-bounds write when usbip_recv_iso() writes to\nurb->iso_frame_desc[i] beyond the allocated region.\n\nKASAN confirmed this with kernel 7.0.0-rc5:\n\n  BUG: KASAN: slab-out-of-bounds in usbip_recv_iso+0x46a/0x640\n  Write of size 4 at addr ffff888106351d40 by task vhci_rx/69\n\n  The buggy address is located 0 bytes to the right of\n   allocated 320-byte region [ffff888106351c00, ffff888106351d40)\n\nThe server side (stub_rx.c) and gadget side (vudc_rx.c) already\nvalidate number_of_packets in the CMD_SUBMIT path since commits\nc6688ef9f297 ("usbip: fix stub_rx: harden CMD_SUBMIT path to handle\nmalicious input") and b78d830f0049 ("usbip: fix vudc_rx: harden\nCMD_SUBMIT path to handle malicious input"). The server side validates\nagainst USBIP_MAX_ISO_PACKETS because no URB exists yet at that point.\nOn the client side we have the original URB, so we can use the tighter\nbound: the response must not exceed the original number_of_packets.\n\nThis mirrors the existing validation of actual_length against\ntransfer_buffer_length in usbip_recv_xbuff(), which checks the\nresponse value against the original allocation size.\n\nKelvin Mbogo's series ("usb: usbip: fix integer overflow in\nusbip_recv_iso()", v2) hardens the receive-side functions themselves;\nthis patch complements that work by catching the bad value at its\nsource -- in usbip_pack_ret_submit() before the overwrite -- and\nusing the tighter per-URB allocation bound rather than the global\nUSBIP_MAX_ISO_PACKETS limit.\n\nFix this by checking rpdu->number_of_packets against\nurb->number_of_packets in usbip_pack_ret_submit() before the\noverwrite. On violation, clamp to zero so that usbip_recv_iso() and\nusbip_pad_iso() safely return early.(CVE-2026-31607)\n\nIn the Linux kernel, the following vulnerability has been resolved: smb: client: validate the whole DACL before rewriting it in cifsacl. build_sec_desc() and id_mode_to_cifs_acl() derive a DACL pointer from a server-supplied dacloffset and then use the incoming ACL to rebuild the chmod/chown security descriptor. The original fix only checked that the struct smb_acl header fits before reading dacl_ptr->size or dacl_ptr->num_aces. That avoids the immediate header-field OOB read, but the rewrite helpers still walk ACEs based on pdacl->num_aces with no structural validation of the incoming DACL body. A malicious server can return a truncated DACL that still contains a header, claims one or more ACEs, and then drive replace_sids_and_copy_aces() or set_chmod_dacl() past the validated extent while they compare or copy attacker-controlled ACEs.(CVE-2026-31709)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnetfilter: nf_tables: reject immediate NF_QUEUE verdict\n\nnft_queue is always used from userspace nftables to deliver the NF_QUEUE\nverdict. Immediately emitting an NF_QUEUE verdict is never used by the\nuserspace nft tools, so reject immediate NF_QUEUE verdicts.\n\nThe arp family does not provide queue support, but such an immediate\nverdict is still reachable. Globally reject NF_QUEUE immediate verdicts\nto address this issue.(CVE-2026-43024)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nipv6: icmp: clear skb2->cb[] in ip6_err_gen_icmpv6_unreach()\n\nSashiko AI-review observed:\n\n  In ip6_err_gen_icmpv6_unreach(), the skb is an outer IPv4 ICMP error packet\n  where its cb contains an IPv4 inet_skb_parm. When skb is cloned into skb2\n  and passed to icmp6_send(), it uses IP6CB(skb2).\n\n  IP6CB interprets the IPv4 inet_skb_parm as an inet6_skb_parm. The cipso\n  offset in inet_skb_parm.opt directly overlaps with dsthao in inet6_skb_parm\n  at offset 18.\n\n  If an attacker sends a forged ICMPv4 error with a CIPSO IP option, dsthao\n  would be a non-zero offset. Inside icmp6_send(), mip6_addr_swap() is called\n  and uses ipv6_find_tlv(skb, opt->dsthao, IPV6_TLV_HAO).\n\n  This would scan the inner, attacker-controlled IPv6 packet starting at that\n  offset, potentially returning a fake TLV without checking if the remaining\n  packet length can hold the full 18-byte struct ipv6_destopt_hao.\n\n  Could mip6_addr_swap() then perform a 16-byte swap that extends past the end\n  of the packet data into skb_shared_info?\n\n  Should the cb array also be cleared in ip6_err_gen_icmpv6_unreach() and\n  ip6ip6_err() to prevent this?\n\nThis patch implements the first suggestion.\n\nI am not sure if ip6ip6_err() needs to be changed.\nA separate patch would be better anyway.(CVE-2026-43038)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ndcache: Limit the minimal number of bucket to two\n\nThere is an OOB read problem on dentry_hashtable when user sets\n'dhash_entries=1':\n  BUG: unable to handle page fault for address: ffff888b30b774b0\n  #PF: supervisor read access in kernel mode\n  #PF: error_code(0x0000) - not-present page\n  Oops: Oops: 0000 [#1] SMP PTI\n  RIP: 0010:__d_lookup+0x56/0x120\n   Call Trace:\n    d_lookup.cold+0x16/0x5d\n    lookup_dcache+0x27/0xf0\n    lookup_one_qstr_excl+0x2a/0x180\n    start_dirop+0x55/0xa0\n    simple_start_creating+0x8d/0xa0\n    debugfs_start_creating+0x8c/0x180\n    debugfs_create_dir+0x1d/0x1c0\n    pinctrl_init+0x6d/0x140\n    do_one_initcall+0x6d/0x3d0\n    kernel_init_freeable+0x39f/0x460\n    kernel_init+0x2a/0x260\n\nThere will be only one bucket in dentry_hashtable when dhash_entries is\nset as one, and d_hash_shift is calculated as 32 by dcache_init(). Then,\nfollowing process will access more than one buckets(which memory region\nis not allocated) in dentry_hashtable:\n d_lookup\n  b = d_hash(hash)\n    dentry_hashtable + ((u32)hashlen >> d_hash_shift)\n    // The C standard defines the behavior of right shift amounts\n    // exceeding the bit width of the operand as undefined. The\n    // result of '(u32)hashlen >> d_hash_shift' becomes 'hashlen',\n    // so 'b' will point to an unallocated memory region.\n  hlist_bl_for_each_entry_rcu(b)\n   hlist_bl_first_rcu(head)\n    h->first  // read OOB!\n\nFix it by limiting the minimal number of dentry_hashtable bucket to two,\nso that 'd_hash_shift' won't exceeds the bit width of type u32.(CVE-2026-43071)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet: af_key: zero aligned sockaddr tail in PF_KEY exports\n\nPF_KEY export paths use `pfkey_sockaddr_size()` when reserving sockaddr\npayload space, so IPv6 addresses occupy 32 bytes on the wire. However,\n`pfkey_sockaddr_fill()` initializes only the first 28 bytes of\n`struct sockaddr_in6`, leaving the final 4 aligned bytes uninitialized.\n\nNot every PF_KEY message is affected. The state and policy dump builders\nalready zero the whole message buffer before filling the sockaddr\npayloads. Keep the fix to the export paths that still append aligned\nsockaddr payloads with plain `skb_put()`:\n\n  - `SADB_ACQUIRE`\n  - `SADB_X_NAT_T_NEW_MAPPING`\n  - `SADB_X_MIGRATE`\n\nFix those paths by clearing only the aligned sockaddr tail after\n`pfkey_sockaddr_fill()`.(CVE-2026-43088)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nxfrm_user: fix info leak in build_mapping()\n\nstruct xfrm_usersa_id has a one-byte padding hole after the proto\nfield, which ends up never getting set to zero before copying out to\nuserspace.  Fix that up by zeroing out the whole structure before\nsetting individual variables.(CVE-2026-43089)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nxfrm: account XFRMA_IF_ID in aevent size calculation\n\nxfrm_get_ae() allocates the reply skb with xfrm_aevent_msgsize(), then\nbuild_aevent() appends attributes including XFRMA_IF_ID when x->if_id is\nset.\n\nxfrm_aevent_msgsize() does not include space for XFRMA_IF_ID. For states\nwith if_id, build_aevent() can fail with -EMSGSIZE and hit BUG_ON(err < 0)\nin xfrm_get_ae(), turning a malformed netlink interaction into a kernel\npanic.\n\nAccount XFRMA_IF_ID in the size calculation unconditionally and replace\nthe BUG_ON with normal error unwinding.(CVE-2026-43107)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ntcp: fix potential race in tcp_v6_syn_recv_sock()\n\nCode in tcp_v6_syn_recv_sock() after the call to tcp_v4_syn_recv_sock()\nis done too late.\n\nAfter tcp_v4_syn_recv_sock(), the child socket is already visible\nfrom TCP ehash table and other cpus might use it.\n\nSince newinet->pinet6 is still pointing to the listener ipv6_pinfo\nbad things can happen as syzbot found.\n\nMove the problematic code in tcp_v6_mapped_child_init()\nand call this new helper from tcp_v4_syn_recv_sock() before\nthe ehash insertion.\n\nThis allows the removal of one tcp_sync_mss(), since\ntcp_v4_syn_recv_sock() will call it with the correct\ncontext.(CVE-2026-43198)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet: Drop the lock in skb_may_tx_timestamp()\n\nskb_may_tx_timestamp() may acquire sock::sk_callback_lock. The lock must\nnot be taken in IRQ context, only softirq is okay. A few drivers receive\nthe timestamp via a dedicated interrupt and complete the TX timestamp\nfrom that handler. This will lead to a deadlock if the lock is already\nwrite-locked on the same CPU.\n\nTaking the lock can be avoided. The socket (pointed by the skb) will\nremain valid until the skb is released. The ->sk_socket and ->file\nmember will be set to NULL once the user closes the socket which may\nhappen before the timestamp arrives.\nIf we happen to observe the pointer while the socket is closing but\nbefore the pointer is set to NULL then we may use it because both\npointer (and the file's cred member) are RCU freed.\n\nDrop the lock. Use READ_ONCE() to obtain the individual pointer. Add a\nmatching WRITE_ONCE() where the pointer are cleared.(CVE-2026-43216)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nvhost: move vdpa group bound check to vhost_vdpa\n\nRemove duplication by consolidating these here.  This reduces the\nposibility of a parent driver missing them.\n\nWhile we're at it, fix a bug in vdpa_sim where a valid ASID can be\nassigned to a group equal to ngroups, causing an out of bound write.(CVE-2026-43248)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nmm/page_alloc: clear page->private in free_pages_prepare()\n\nSeveral subsystems (slub, shmem, ttm, etc.) use page->private but don't\nclear it before freeing pages.  When these pages are later allocated as\nhigh-order pages and split via split_page(), tail pages retain stale\npage->private values.\n\nThis causes a use-after-free in the swap subsystem.  The swap code uses\npage->private to track swap count continuations, assuming freshly\nallocated pages have page->private == 0.  When stale values are present,\nswap_count_continued() incorrectly assumes the continuation list is valid\nand iterates over uninitialized page->lru containing LIST_POISON values,\ncausing a crash:\n\n  KASAN: maybe wild-memory-access in range [0xdead000000000100-0xdead000000000107]\n  RIP: 0010:__do_sys_swapoff+0x1151/0x1860\n\nFix this by clearing page->private in free_pages_prepare(), ensuring all\nfreed pages have clean state regardless of previous use.(CVE-2026-43303)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nscsi: hisi_sas: Fix NULL pointer exception during user_scan()\n\nuser_scan() invokes updated sas_user_scan() for channel 0, and if\nsuccessful, iteratively scans remaining channels (1 to shost->max_channel)\nvia scsi_scan_host_selected() in commit 37c4e72b0651 ("scsi: Fix\nsas_user_scan() to handle wildcard and multi-channel scans"). However,\nhisi_sas supports only one channel, and the current value of max_channel is\n1. sas_user_scan() for channel 1 will trigger the following NULL pointer\nexception:\n\n[  441.554662] Unable to handle kernel NULL pointer dereference at virtual address 00000000000008b0\n[  441.554699] Mem abort info:\n[  441.554710]   ESR = 0x0000000096000004\n[  441.554718]   EC = 0x25: DABT (current EL), IL = 32 bits\n[  441.554723]   SET = 0, FnV = 0\n[  441.554726]   EA = 0, S1PTW = 0\n[  441.554730]   FSC = 0x04: level 0 translation fault\n[  441.554735] Data abort info:\n[  441.554737]   ISV = 0, ISS = 0x00000004, ISS2 = 0x00000000\n[  441.554742]   CM = 0, WnR = 0, TnD = 0, TagAccess = 0\n[  441.554747]   GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0\n[  441.554752] user pgtable: 4k pages, 48-bit VAs, pgdp=00000828377a6000\n[  441.554757] [00000000000008b0] pgd=0000000000000000, p4d=0000000000000000\n[  441.554769] Internal error: Oops: 0000000096000004 [#1]  SMP\n[  441.629589] Modules linked in: arm_spe_pmu arm_smmuv3_pmu tpm_tis_spi hisi_uncore_sllc_pmu hisi_uncore_pa_pmu hisi_uncore_l3c_pmu hisi_uncore_hha_pmu hisi_uncore_ddrc_pmu hisi_uncore_cpa_pmu hns3_pmu hisi_ptt hisi_pcie_pmu tpm_tis_core spidev spi_hisi_sfc_v3xx hisi_uncore_pmu spi_dw_mmio fuse hclge hclge_common hisi_sec2 hisi_hpre hisi_zip hisi_qm hns3 hisi_sas_v3_hw sm3_ce sbsa_gwdt hnae3 hisi_sas_main uacce hisi_dma i2c_hisi dm_mirror dm_region_hash dm_log dm_mod\n[  441.670819] CPU: 46 UID: 0 PID: 6994 Comm: bash Kdump: loaded Not tainted 7.0.0-rc2+ #84 PREEMPT\n[  441.691327] pstate: 81400009 (Nzcv daif +PAN -UAO -TCO +DIT -SSBS BTYPE=--)\n[  441.698277] pc : sas_find_dev_by_rphy+0x44/0x118\n[  441.702896] lr : sas_find_dev_by_rphy+0x3c/0x118\n[  441.707502] sp : ffff80009abbba40\n[  441.710805] x29: ffff80009abbba40 x28: ffff082819a40008 x27: ffff082810c37c08\n[  441.717930] x26: ffff082810c37c28 x25: ffff082819a40290 x24: ffff082810c37c00\n[  441.725054] x23: 0000000000000000 x22: 0000000000000001 x21: ffff082819a40000\n[  441.732179] x20: ffff082819a40290 x19: 0000000000000000 x18: 0000000000000020\n[  441.739304] x17: 0000000000000000 x16: ffffb5dad6bda690 x15: 00000000ffffffff\n[  441.746428] x14: ffff082814c3b26c x13: 00000000ffffffff x12: ffff082814c3b26a\n[  441.753553] x11: 00000000000000c0 x10: 000000000000003a x9 : ffffb5dad5ea94f4\n[  441.760678] x8 : 000000000000003a x7 : ffff80009abbbab0 x6 : 0000000000000030\n[  441.767802] x5 : 0000000000000000 x4 : 0000000000000000 x3 : 0000000000000000\n[  441.774926] x2 : ffff08280f35a300 x1 : ffffb5dad7127180 x0 : 0000000000000000\n[  441.782053] Call trace:\n[  441.784488]  sas_find_dev_by_rphy+0x44/0x118 (P)\n[  441.789095]  sas_target_alloc+0x24/0xb0\n[  441.792920]  scsi_alloc_target+0x290/0x330\n[  441.797010]  __scsi_scan_target+0x88/0x258\n[  441.801096]  scsi_scan_channel+0x74/0xb8\n[  441.805008]  scsi_scan_host_selected+0x170/0x188\n[  441.809615]  sas_user_scan+0xfc/0x148\n[  441.813267]  store_scan+0x10c/0x180\n[  441.816743]  dev_attr_store+0x20/0x40\n[  441.820398]  sysfs_kf_write+0x84/0xa8\n[  441.824054]  kernfs_fop_write_iter+0x130/0x1c8\n[  441.828487]  vfs_write+0x2c0/0x370\n[  441.831880]  ksys_write+0x74/0x118\n[  441.835271]  __arm64_sys_write+0x24/0x38\n[  441.839182]  invoke_syscall+0x50/0x120\n[  441.842919]  el0_svc_common.constprop.0+0xc8/0xf0\n[  441.847611]  do_el0_svc+0x24/0x38\n[  441.850913]  el0_svc+0x38/0x158\n[  441.854043]  el0t_64_sync_handler+0xa0/0xe8\n[  441.858214]  el0t_64_sync+0x1ac/0x1b0\n[  441.861865] Code: aa1303e0 97ff70a8 34ffff80 d10a4273 (f9445a75)\n[  441.867946] ---[ end trace 0000000000000000 ]---\n\nTherefore\n---truncated---(CVE-2026-43413)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nipvs: skip ipv6 extension headers for csum checks\n\nProtocol checksum validation fails for IPv6 if there are extension\nheaders before the protocol header. iph->len already contains its\noffset, so use it to fix the problem.(CVE-2026-45850)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet: hns3: fix double free issue for tx spare buffer\n\nIn hns3_set_ringparam(), a temporary copy (tmp_rings) of the ring structure\nis created for rollback. However, the tx_spare pointer in the original\nring handle is incorrectly left pointing to the old backup memory.\n\nLater, if memory allocation fails in hns3_init_all_ring() during the setup,\nthe error path attempts to free all newly allocated rings. Since tx_spare\ncontains a stale (non-NULL) pointer from the backup, it is mistaken for\na newly allocated buffer and is erroneously freed, leading to a double-free\nof the backup memory.\n\nThe root cause is that the tx_spare field was not cleared after its value\nwas saved in tmp_rings, leaving a dangling pointer.\n\nFix this by setting tx_spare to NULL in the original ring structure\nwhen the creation of the new `tx_spare` fails. This ensures the\nerror cleanup path only frees genuinely newly allocated buffers.(CVE-2026-45891)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\niommu/vt-d: Clear Present bit before tearing down PASID entry\n\nThe Intel VT-d Scalable Mode PASID table entry consists of 512 bits (64\nbytes). When tearing down an entry, the current implementation zeros the\nentire 64-byte structure immediately using multiple 64-bit writes.\n\nSince the IOMMU hardware may fetch these 64 bytes using multiple\ninternal transactions (e.g., four 128-bit bursts), updating or zeroing\nthe entire entry while it is active (P=1) risks a "torn" read. If a\nhardware fetch occurs simultaneously with the CPU zeroing the entry, the\nhardware could observe an inconsistent state, leading to unpredictable\nbehavior or spurious faults.\n\nFollow the "Guidance to Software for Invalidations" in the VT-d spec\n(Section 6.5.3.3) by implementing the recommended ownership handshake:\n\n1. Clear only the 'Present' (P) bit of the PASID entry.\n2. Use a dma_wmb() to ensure the cleared bit is visible to hardware\n   before proceeding.\n3. Execute the required invalidation sequence (PASID cache, IOTLB, and\n   Device-TLB flush) to ensure the hardware has released all cached\n   references.\n4. Only after the flushes are complete, zero out the remaining fields\n   of the PASID entry.\n\nAlso, add a dma_wmb() in pasid_set_present() to ensure that all other\nfields of the PASID entry are visible to the hardware before the Present\nbit is set.(CVE-2026-45894)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nquota: fix livelock between quotactl and freeze_super\n\nWhen a filesystem is frozen, quotactl_block() enters a retry loop\nwaiting for the filesystem to thaw. It acquires s_umount, checks the\nfreeze state, drops s_umount and uses sb_start_write() - sb_end_write()\npair to wait for the unfreeze.\n\nHowever, this retry loop can trigger a livelock issue, specifically on\nkernels with preemption disabled.\n\nThe mechanism is as follows:\n1. freeze_super() sets SB_FREEZE_WRITE and calls sb_wait_write().\n2. sb_wait_write() calls percpu_down_write(), which initiates\n   synchronize_rcu().\n3. Simultaneously, quotactl_block() spins in its retry loop, immediately\n   executing the sb_start_write() - sb_end_write() pair.\n4. Because the kernel is non-preemptible and the loop contains no\n   scheduling points, quotactl_block() never yields the CPU. This\n   prevents that CPU from reaching an RCU quiescent state.\n5. synchronize_rcu() in the freezer thread waits indefinitely for the\n   quotactl_block() CPU to report a quiescent state.\n6. quotactl_block() spins indefinitely waiting for the freezer to\n   advance, which it cannot do as it is blocked on the RCU sync.\n\nThis results in a hang of the freezer process and 100% CPU usage by the\nquota process.\n\nWhile this can occur intermittently on multi-core systems, it is\nreliably reproducing on a node with the following script, running both\nthe freezer and the quota toggle on the same CPU:\n\n  # mkfs.ext4 -O quota /dev/sda 2g && mkdir a_mount\n  # mount /dev/sda -o quota,usrquota,grpquota a_mount\n  # taskset -c 3 bash -c "while true; do xfs_freeze -f a_mount; \\\n    xfs_freeze -u a_mount; done" &\n  # taskset -c 3 bash -c "while true; do quotaon a_mount; \\\n    quotaoff a_mount; done" &\n\nAdding cond_resched() to the retry loop fixes the issue. It acts as an\nRCU quiescent state, allowing synchronize_rcu() in percpu_down_write()\nto complete.(CVE-2026-45895)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nfat: avoid parent link count underflow in rmdir\n\nCorrupted FAT images can leave a directory inode with an incorrect\ni_nlink (e.g. 2 even though subdirectories exist). rmdir then\nunconditionally calls drop_nlink(dir) and can drive i_nlink to 0,\ntriggering the WARN_ON in drop_nlink().\n\nAdd a sanity check in vfat_rmdir() and msdos_rmdir(): only drop the\nparent link count when it is at least 3, otherwise report a filesystem\nerror.(CVE-2026-45915)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nsched/rt: Skip currently executing CPU in rto_next_cpu()\n\nCPU0 becomes overloaded when hosting a CPU-bound RT task, a non-CPU-bound\nRT task, and a CFS task stuck in kernel space. When other CPUs switch from\nRT to non-RT tasks, RT load balancing (LB) is triggered; with\nHAVE_RT_PUSH_IPI enabled, they send IPIs to CPU0 to drive the execution\nof rto_push_irq_work_func. During push_rt_task on CPU0,\nif next_task->prio < rq->donor->prio, resched_curr() sets NEED_RESCHED\nand after the push operation completes, CPU0 calls rto_next_cpu().\nSince only CPU0 is overloaded in this scenario, rto_next_cpu() should\nideally return -1 (no further IPI needed).\n\nHowever, multiple CPUs invoking tell_cpu_to_push() during LB increments\nrd->rto_loop_next. Even when rd->rto_cpu is set to -1, the mismatch between\nrd->rto_loop and rd->rto_loop_next forces rto_next_cpu() to restart its\nsearch from -1. With CPU0 remaining overloaded (satisfying rt_nr_migratory\n&& rt_nr_total > 1), it gets reselected, causing CPU0 to queue irq_work to\nitself and send self-IPIs repeatedly. As long as CPU0 stays overloaded and\nother CPUs run pull_rt_tasks(), it falls into an infinite self-IPI loop,\nwhich triggers a CPU hardlockup due to continuous self-interrupts.\n\nThe trigging scenario is as follows:\n\n         cpu0                      cpu1                    cpu2\n                                pull_rt_task\n                              tell_cpu_to_push\n                 <------------irq_work_queue_on\nrto_push_irq_work_func\n       push_rt_task\n    resched_curr(rq)                                   pull_rt_task\n    rto_next_cpu                                     tell_cpu_to_push\n                      <-------------------------- atomic_inc(rto_loop_next)\nrd->rto_loop != next\n     rto_next_cpu\n   irq_work_queue_on\nrto_push_irq_work_func\n\nFix redundant self-IPI by filtering the initiating CPU in rto_next_cpu().\nThis solution has been verified to effectively eliminate spurious self-IPIs\nand prevent CPU hardlockup scenarios.(CVE-2026-45919)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\next4: fix dirtyclusters double decrement on fs shutdown\n\nfstests test generic/388 occasionally reproduces a warning in\next4_put_super() associated with the dirty clusters count:\n\n  WARNING: CPU: 7 PID: 76064 at fs/ext4/super.c:1324 ext4_put_super+0x48c/0x590 [ext4]\n\nTracing the failure shows that the warning fires due to an\ns_dirtyclusters_counter value of -1. IOW, this appears to be a\nspurious decrement as opposed to some sort of leak. Further tracing\nof the dirty cluster count deltas and an LLM scan of the resulting\noutput identified the cause as a double decrement in the error path\nbetween ext4_mb_mark_diskspace_used() and the caller\next4_mb_new_blocks().\n\nFirst, note that generic/388 is a shutdown vs. fsstress test and so\nproduces a random set of operations and shutdown injections. In the\nproblematic case, the shutdown triggers an error return from the\next4_handle_dirty_metadata() call(s) made from\next4_mb_mark_context(). The changed value is non-zero at this point,\nso ext4_mb_mark_diskspace_used() does not exit after the error\nbubbles up from ext4_mb_mark_context(). Instead, the former\ndecrements both cluster counters and returns the error up to\next4_mb_new_blocks(). The latter falls into the !ar->len out path\nwhich decrements the dirty clusters counter a second time, creating\nthe inconsistency.\n\nTo avoid this problem and simplify ownership of the cluster\nreservation in this codepath, lift the counter reduction to a single\nplace in the caller. This makes it more clear that\next4_mb_new_blocks() is responsible for acquiring cluster\nreservation (via ext4_claim_free_clusters()) in the !delalloc case\nas well as releasing it, regardless of whether it ends up consumed\nor returned due to failure.(CVE-2026-45920)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\next4: fix e4b bitmap inconsistency reports\n\nA bitmap inconsistency issue was observed during stress tests under\nmixed huge-page workloads. Ext4 reported multiple e4b bitmap check\nfailures like:\n\next4_mb_complex_scan_group:2508: group 350, 8179 free clusters as\nper group info. But got 8192 blocks\n\nAnalysis and experimentation confirmed that the issue is caused by a\nrace condition between page migration and bitmap modification. Although\nthis timing window is extremely narrow, it is still hit in practice:\n\nfolio_lock                        ext4_mb_load_buddy\n__migrate_folio\n  check ref count\n  folio_mc_copy                     __filemap_get_folio\n                                      folio_try_get(folio)\n                                  ......\n                                  mb_mark_used\n                                  ext4_mb_unload_buddy\n  __folio_migrate_mapping\n    folio_ref_freeze\nfolio_unlock\n\nThe root cause of this issue is that the fast path of load_buddy only\nincrements the folio's reference count, which is insufficient to prevent\nconcurrent folio migration. We observed that the folio migration process\nacquires the folio lock. Therefore, we can determine whether to take the\nfast path in load_buddy by checking the lock status. If the folio is\nlocked, we opt for the slow path (which acquires the lock) to close this\nconcurrency window.\n\nAdditionally, this change addresses the following issues:\n\nWhen the DOUBLE_CHECK macro is enabled to inspect bitmap-related\nissues, the following error may be triggered:\n\ncorruption in group 324 at byte 784(6272): f in copy != ff on\ndisk/prealloc\n\nAnalysis reveals that this is a false positive. There is a specific race\nwindow where the bitmap and the group descriptor become momentarily\ninconsistent, leading to this error report:\n\next4_mb_load_buddy                   ext4_mb_load_buddy\n  __filemap_get_folio(create|lock)\n    folio_lock\n  ext4_mb_init_cache\n    folio_mark_uptodate\n                                     __filemap_get_folio(no lock)\n                                     ......\n                                     mb_mark_used\n                                       mb_mark_used_double\n  mb_cmp_bitmaps\n                                       mb_set_bits(e4b->bd_bitmap)\n  folio_unlock\n\nThe original logic assumed that since mb_cmp_bitmaps is called when the\nbitmap is newly loaded from disk, the folio lock would be sufficient to\nprevent concurrent access. However, this overlooks a specific race\ncondition: if another process attempts to load buddy and finds the folio\nis already in an uptodate state, it will immediately begin using it without\nholding folio lock.(CVE-2026-45942)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\niommu/vt-d: Clear Present bit before tearing down context entry\n\nWhen tearing down a context entry, the current implementation zeros the\nentire 128-bit entry using multiple 64-bit writes. This creates a window\nwhere the hardware can fetch a "torn" entry — where some fields are\nalready zeroed while the 'Present' bit is still set — leading to\nunpredictable behavior or spurious faults.\n\nWhile x86 provides strong write ordering, the compiler may reorder writes\nto the two 64-bit halves of the context entry. Even without compiler\nreordering, the hardware fetch is not guaranteed to be atomic with\nrespect to multiple CPU writes.\n\nAlign with the "Guidance to Software for Invalidations" in the VT-d spec\n(Section 6.5.3.3) by implementing the recommended ownership handshake:\n\n1. Clear only the 'Present' (P) bit of the context entry first to\n   signal the transition of ownership from hardware to software.\n2. Use dma_wmb() to ensure the cleared bit is visible to the IOMMU.\n3. Perform the required cache and context-cache invalidation to ensure\n   hardware no longer has cached references to the entry.\n4. Fully zero out the entry only after the invalidation is complete.\n\nAlso, add a dma_wmb() to context_set_present() to ensure the entry\nis fully initialized before the 'Present' bit becomes visible.(CVE-2026-45944)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\next4: fix memory leak in ext4_ext_shift_extents()\n\nIn ext4_ext_shift_extents(), if the extent is NULL in the while loop, the\nfunction returns immediately without releasing the path obtained via\next4_find_extent(), leading to a memory leak.\n\nFix this by jumping to the out label to ensure the path is properly\nreleased.(CVE-2026-45948)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ncpuidle: Skip governor when only one idle state is available\n\nOn certain platforms (PowerNV systems without a power-mgt DT node),\ncpuidle may register only a single idle state. In cases where that\nsingle state is a polling state (state 0), the ladder governor may\nincorrectly treat state 1 as the first usable state and pass an\nout-of-bounds index. This can lead to a NULL enter callback being\ninvoked, ultimately resulting in a system crash.\n\n[   13.342636] cpuidle-powernv : Only Snooze is available\n[   13.351854] Faulting instruction address: 0x00000000\n[   13.376489] NIP [0000000000000000] 0x0\n[   13.378351] LR  [c000000001e01974] cpuidle_enter_state+0x2c4/0x668\n\nFix this by adding a bail-out in cpuidle_select() that returns state 0\ndirectly when state_count <= 1, bypassing the governor and keeping the\ntick running.(CVE-2026-45968)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\next4: don't set EXT4_GET_BLOCKS_CONVERT when splitting before submitting I/O\n\nWhen allocating blocks during within-EOF DIO and writeback with\ndioread_nolock enabled, EXT4_GET_BLOCKS_PRE_IO was set to split an\nexisting large unwritten extent. However, EXT4_GET_BLOCKS_CONVERT was\nset when calling ext4_split_convert_extents(), which may potentially\nresult in stale data issues.\n\nAssume we have an unwritten extent, and then DIO writes the second half.\n\n   [UUUUUUUUUUUUUUUU] on-disk extent        U: unwritten extent\n   [UUUUUUUUUUUUUUUU] extent status tree\n            |<-   ->| ----> dio write this range\n\nFirst, ext4_iomap_alloc() call ext4_map_blocks() with\nEXT4_GET_BLOCKS_PRE_IO, EXT4_GET_BLOCKS_UNWRIT_EXT and\nEXT4_GET_BLOCKS_CREATE flags set. ext4_map_blocks() find this extent and\ncall ext4_split_convert_extents() with EXT4_GET_BLOCKS_CONVERT and the\nabove flags set.\n\nThen, ext4_split_convert_extents() calls ext4_split_extent() with\nEXT4_EXT_MAY_ZEROOUT, EXT4_EXT_MARK_UNWRIT2 and EXT4_EXT_DATA_VALID2\nflags set, and it calls ext4_split_extent_at() to split the second half\nwith EXT4_EXT_DATA_VALID2, EXT4_EXT_MARK_UNWRIT1, EXT4_EXT_MAY_ZEROOUT\nand EXT4_EXT_MARK_UNWRIT2 flags set. However, ext4_split_extent_at()\nfailed to insert extent since a temporary lack -ENOSPC. It zeroes out\nthe first half but convert the entire on-disk extent to written since\nthe EXT4_EXT_DATA_VALID2 flag set, but left the second half as unwritten\nin the extent status tree.\n\n   [0000000000SSSSSS]  data                S: stale data, 0: zeroed\n   [WWWWWWWWWWWWWWWW]  on-disk extent      W: written extent\n   [WWWWWWWWWWUUUUUU]  extent status tree\n\nFinally, if the DIO failed to write data to the disk, the stale data in\nthe second half will be exposed once the cached extent entry is gone.\n\nFix this issue by not passing EXT4_GET_BLOCKS_CONVERT when splitting\nan unwritten extent before submitting I/O, and make\next4_split_convert_extents() to zero out the entire extent range\nto zero for this case, and also mark the extent in the extent status\ntree for consistency.(CVE-2026-45985)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nKVM: nSVM: Triple fault if restore host CR3 fails on nested #VMEXIT\n\nIf loading L1's CR3 fails on a nested #VMEXIT, nested_svm_vmexit()\nreturns an error code that is ignored by most callers, and continues to\nrun L1 with corrupted state. A sane recovery is not possible in this\ncase, and HW behavior is to cause a shutdown. Inject a triple fault\ninstead, and do not return early from nested_svm_vmexit(). Continue\ncleaning up the vCPU state (e.g. clear pending exceptions), to handle\nthe failure as gracefully as possible.\n\nFrom the APM:\n\n  Upon #VMEXIT, the processor performs the following actions in order to\n  return to the host execution context:\n\n  ...\n\n  if (illegal host state loaded, or exception while loading host state)\n      shutdown\n  else\n      execute first host instruction following the VMRUN\n\nRemove the return value of nested_svm_vmexit(), which is mostly\nunchecked anyway.(CVE-2026-46032)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nfbdev: defio: Disconnect deferred I/O from the lifetime of struct fb_info\n\nHold state of deferred I/O in struct fb_deferred_io_state. Allocate an\ninstance as part of initializing deferred I/O and remove it only after\nthe final mapping has been closed. If the fb_info and the contained\ndeferred I/O meanwhile goes away, clear struct fb_deferred_io_state.info\nto invalidate the mapping. Any access will then result in a SIGBUS\nsignal.\n\nFixes a long-standing problem, where a device hot-unplug happens while\nuser space still has an active mapping of the graphics memory. The hot-\nunplug frees the instance of struct fb_info. Accessing the memory will\noperate on undefined state.(CVE-2026-46065)\n\nIn the Linux kernel, the vlan_dev_set_egress_priority() function currently keeps cleared egress priority mappings in the hash as tombstones. Repeated set/clear cycles with distinct skb priorities accumulate mapping nodes until device teardown, causing memory leakage. This vulnerability is fixed by deleting mappings instead of keeping tombstones, using RCU protection for safe deallocation.(CVE-2026-46153)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\neventpoll: fix ep_remove struct eventpoll / struct file UAF\n\nep_remove() (via ep_remove_file()) cleared file->f_ep under\nfile->f_lock but then kept using @file inside the critical section\n(is_file_epoll(), hlist_del_rcu() through the head, spin_unlock).\nA concurrent __fput() taking the eventpoll_release() fastpath in\nthat window observed the transient NULL, skipped\neventpoll_release_file() and ran to f_op->release / file_free().\n\nFor the epoll-watches-epoll case, f_op->release is\nep_eventpoll_release() -> ep_clear_and_put() -> ep_free(), which\nkfree()s the watched struct eventpoll. Its embedded ->refs\nhlist_head is exactly where epi->fllink.pprev points, so the\nsubsequent hlist_del_rcu()'s "*pprev = next" scribbles into freed\nkmalloc-192 memory.\n\nIn addition, struct file is SLAB_TYPESAFE_BY_RCU, so the slot\nbacking @file could be recycled by alloc_empty_file() --\nreinitializing f_lock and f_ep -- while ep_remove() is still\nnominally inside that lock. The upshot is an attacker-controllable\nkmem_cache_free() against the wrong slab cache.\n\nPin @file via epi_fget() at the top of ep_remove() and gate the\ncritical section on the pin succeeding. With the pin held @file\ncannot reach refcount zero, which holds __fput() off and\ntransitively keeps the watched struct eventpoll alive across the\nhlist_del_rcu() and the f_lock use, closing both UAFs.\n\nIf the pin fails @file has already reached refcount zero and its\n__fput() is in flight. Because we bailed before clearing f_ep,\nthat path takes the eventpoll_release() slow path into\neventpoll_release_file() and blocks on ep->mtx until the waiter\nside's ep_clear_and_put() drops it. The bailed epi's share of\nep->refcount stays intact, so the trailing ep_refcount_dec_and_test()\nin ep_clear_and_put() cannot free the eventpoll out from under\neventpoll_release_file(); the orphaned epi is then cleaned up\nthere.\n\nA successful pin also proves we are not racing\neventpoll_release_file() on this epi, so drop the now-redundant\nre-check of epi->dying under f_lock. The cheap lockless\nREAD_ONCE(epi->dying) fast-path bailout stays.(CVE-2026-46242)\n\nIn the Linux kernel, the following vulnerability has been resolved:  drm/amd/display: Fix dc_link NULL handling in HPD init  amdgpu_dm_hpd_init() may see connectors without a valid dc_link.  The code already checks dc_link for the polling decision, but later unconditionally dereferences it when setting up HPD interrupts.  Assign dc_link early and skip connectors where it is NULL.  Fixes the below: drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm_irq.c:940 amdgpu_dm_hpd_init() error: we previously assumed 'dc_link' could be null (see line 931)  drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm_irq.c     923                 /*     924                  * Analog connectors may be hot-plugged unlike other connector     925                  * types that don't support HPD. Only poll analog connectors.     926                  */     927                 use_polling |=     928                         amdgpu_dm_connector->dc_link &&                                 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^ The patch adds this NULL check but hopefully it can be removed      929                         dc_connector_supports_analog(amdgpu_dm_connector->dc_link->link_id.id);     930     931                 dc_link = amdgpu_dm_connector->dc_link;  dc_link assigned here.      932     933                 /*     934                  * Get a base driver irq reference for hpd ints for the lifetime     935                  * of dm. Note that only hpd interrupt types are registered with     936                  * base driver; hpd_rx types aren't. IOW, amdgpu_irq_get/put on     937                  * hpd_rx isn't available. DM currently controls hpd_rx     938                  * explicitly with dc_interrupt_set()     939                  */ --> 940                 if (dc_link->irq_source_hpd != DC_IRQ_SOURCE_INVALID) {                             ^^^^^^^^^^^^^^^^^^^^^^^ If it's NULL then we are trouble because we dereference it here.      941                         irq_type = dc_link->irq_source_hpd - DC_IRQ_SOURCE_HPD1;     942                         /*     943                          * TODO: There's a mismatch between mode_info.num_hpd     944                          * and what bios reports as the # of connectors with hpd  The Linux kernel CVE team has assigned CVE-2026-46245 to this issue.(CVE-2026-46245)\n\nIn the Linux kernel, the following vulnerability has been resolved:  procfs: fix missing RCU protection when reading real_parent in do_task_stat()  When reading /proc/[pid]/stat, do_task_stat() accesses task->real_parent without proper RCU protection, which leads to:    cpu 0                               cpu 1   -----                               -----   do_task_stat     var = task->real_parent                                       release_task                                         call_rcu(delayed_put_task_struct)     task_tgid_nr_ns(var)       rcu_read_lock   <--- Too late to protect task->real_parent!       task_pid_ptr    <--- UAF!       rcu_read_unlock  This patch uses task_ppid_nr_ns() instead of task_tgid_nr_ns() to add proper RCU protection for accessing task->real_parent.  The Linux kernel CVE team has assigned CVE-2026-46259 to this issue.(CVE-2026-46259)","modified":"2026-06-12T12:45:05.704245428Z","published":"2026-06-12T12:28:08Z","upstream":["CVE-2025-38389","CVE-2025-68183","CVE-2025-68198","CVE-2025-68813","CVE-2025-71085","CVE-2026-31527","CVE-2026-31607","CVE-2026-31709","CVE-2026-43024","CVE-2026-43038","CVE-2026-43071","CVE-2026-43088","CVE-2026-43089","CVE-2026-43107","CVE-2026-43198","CVE-2026-43216","CVE-2026-43248","CVE-2026-43303","CVE-2026-43413","CVE-2026-45850","CVE-2026-45891","CVE-2026-45894","CVE-2026-45895","CVE-2026-45915","CVE-2026-45919","CVE-2026-45920","CVE-2026-45942","CVE-2026-45944","CVE-2026-45948","CVE-2026-45968","CVE-2026-45985","CVE-2026-46032","CVE-2026-46065","CVE-2026-46153","CVE-2026-46242","CVE-2026-46245","CVE-2026-46259"],"database_specific":{"severity":"Critical"},"references":[{"type":"ADVISORY","url":"https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2026-2675"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-38389"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-68183"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-68198"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-68813"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-71085"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-31527"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-31607"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-31709"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-43024"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-43038"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-43071"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-43088"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-43089"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-43107"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-43198"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-43216"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-43248"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-43303"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-43413"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-45850"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-45891"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-45894"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-45895"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-45915"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-45919"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-45920"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-45942"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-45944"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-45948"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-45968"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-45985"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-46032"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-46065"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-46153"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-46242"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-46245"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-46259"}],"affected":[{"package":{"name":"kernel","ecosystem":"openEuler:24.03-LTS-SP1","purl":"pkg:rpm/openEuler/kernel&distro=openEuler-24.03-LTS-SP1"},"ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"6.6.0-145.1.15.153.oe2403sp1"}]}],"ecosystem_specific":{"aarch64":["bpftool-6.6.0-145.1.15.153.oe2403sp1.aarch64.rpm","bpftool-debuginfo-6.6.0-145.1.15.153.oe2403sp1.aarch64.rpm","kernel-6.6.0-145.1.15.153.oe2403sp1.aarch64.rpm","kernel-debuginfo-6.6.0-145.1.15.153.oe2403sp1.aarch64.rpm","kernel-debugsource-6.6.0-145.1.15.153.oe2403sp1.aarch64.rpm","kernel-devel-6.6.0-145.1.15.153.oe2403sp1.aarch64.rpm","kernel-headers-6.6.0-145.1.15.153.oe2403sp1.aarch64.rpm","kernel-source-6.6.0-145.1.15.153.oe2403sp1.aarch64.rpm","kernel-tools-6.6.0-145.1.15.153.oe2403sp1.aarch64.rpm","kernel-tools-debuginfo-6.6.0-145.1.15.153.oe2403sp1.aarch64.rpm","kernel-tools-devel-6.6.0-145.1.15.153.oe2403sp1.aarch64.rpm","perf-6.6.0-145.1.15.153.oe2403sp1.aarch64.rpm","perf-debuginfo-6.6.0-145.1.15.153.oe2403sp1.aarch64.rpm","python3-perf-6.6.0-145.1.15.153.oe2403sp1.aarch64.rpm","python3-perf-debuginfo-6.6.0-145.1.15.153.oe2403sp1.aarch64.rpm"],"src":["kernel-6.6.0-145.1.15.153.oe2403sp1.src.rpm"],"x86_64":["bpftool-6.6.0-145.1.15.153.oe2403sp1.x86_64.rpm","bpftool-debuginfo-6.6.0-145.1.15.153.oe2403sp1.x86_64.rpm","kernel-6.6.0-145.1.15.153.oe2403sp1.x86_64.rpm","kernel-debuginfo-6.6.0-145.1.15.153.oe2403sp1.x86_64.rpm","kernel-debugsource-6.6.0-145.1.15.153.oe2403sp1.x86_64.rpm","kernel-devel-6.6.0-145.1.15.153.oe2403sp1.x86_64.rpm","kernel-headers-6.6.0-145.1.15.153.oe2403sp1.x86_64.rpm","kernel-source-6.6.0-145.1.15.153.oe2403sp1.x86_64.rpm","kernel-tools-6.6.0-145.1.15.153.oe2403sp1.x86_64.rpm","kernel-tools-debuginfo-6.6.0-145.1.15.153.oe2403sp1.x86_64.rpm","kernel-tools-devel-6.6.0-145.1.15.153.oe2403sp1.x86_64.rpm","perf-6.6.0-145.1.15.153.oe2403sp1.x86_64.rpm","perf-debuginfo-6.6.0-145.1.15.153.oe2403sp1.x86_64.rpm","python3-perf-6.6.0-145.1.15.153.oe2403sp1.x86_64.rpm","python3-perf-debuginfo-6.6.0-145.1.15.153.oe2403sp1.x86_64.rpm"]},"database_specific":{"source":"https://repo.openeuler.org/security/data/osv/OESA-2026-2675.json"}}],"schema_version":"1.7.5"}