{"schema_version":"1.7.2","id":"OESA-2026-3532","modified":"2026-08-30T04:15:17Z","published":"2026-08-30T04:15:17Z","upstream":["CVE-2022-49289","CVE-2025-37991","CVE-2025-68190","CVE-2026-23102","CVE-2026-43373","CVE-2026-46054","CVE-2026-46191","CVE-2026-46234","CVE-2026-46275","CVE-2026-53023","CVE-2026-53043","CVE-2026-53112","CVE-2026-53120","CVE-2026-63829","CVE-2026-63920","CVE-2026-63921","CVE-2026-64007","CVE-2026-64114","CVE-2026-64133","CVE-2026-64266","CVE-2026-64422","CVE-2026-64436","CVE-2026-64546","CVE-2026-64573","CVE-2026-68160","CVE-2026-72135","CVE-2026-72350"],"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\nuaccess: fix integer overflow on access_ok()\n\nThree architectures check the end of a user access against the\naddress limit without taking a possible overflow into account.\nPassing a negative length or another overflow in here returns\nsuccess when it should not.\n\nUse the most common correct implementation here, which optimizes\nfor a constant 'size' argument, and turns the common case into a\nsingle comparison.(CVE-2022-49289)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nparisc: Fix double SIGFPE crash\n\nCamm noticed that on parisc a SIGFPE exception will crash an application with\na second SIGFPE in the signal handler.  Dave analyzed it, and it happens\nbecause glibc uses a double-word floating-point store to atomically update\nfunction descriptors. As a result of lazy binding, we hit a floating-point\nstore in fpe_func almost immediately.\n\nWhen the T bit is set, an assist exception trap occurs when when the\nco-processor encounters *any* floating-point instruction except for a double\nstore of register %fr0.  The latter cancels all pending traps.  Let's fix this\nby clearing the Trap (T) bit in the FP status register before returning to the\nsignal handler in userspace.\n\nThe issue can be reproduced with this test program:\n\nroot@parisc:~# cat fpe.c\n\nstatic void fpe_func(int sig, siginfo_t *i, void *v) {\n        sigset_t set;\n        sigemptyset(&set);\n        sigaddset(&set, SIGFPE);\n        sigprocmask(SIG_UNBLOCK, &set, NULL);\n        printf("GOT signal %d with si_code %ld\\n", sig, i->si_code);\n}\n\nint main() {\n        struct sigaction action = {\n                .sa_sigaction = fpe_func,\n                .sa_flags = SA_RESTART|SA_SIGINFO };\n        sigaction(SIGFPE, &action, 0);\n        feenableexcept(FE_OVERFLOW);\n        return printf("%lf\\n",1.7976931348623158E308*1.7976931348623158E308);\n}\n\nroot@parisc:~# gcc fpe.c -lm\nroot@parisc:~# ./a.out\n Floating point exception\n\nroot@parisc:~# strace -f ./a.out\n execve("./a.out", ["./a.out"], 0xf9ac7034 /* 20 vars */) = 0\n getrlimit(RLIMIT_STACK, {rlim_cur=8192*1024, rlim_max=RLIM_INFINITY}) = 0\n ...\n rt_sigaction(SIGFPE, {sa_handler=0x1110a, sa_mask=[], sa_flags=SA_RESTART|SA_SIGINFO}, NULL, 8) = 0\n --- SIGFPE {si_signo=SIGFPE, si_code=FPE_FLTOVF, si_addr=0x1078f} ---\n --- SIGFPE {si_signo=SIGFPE, si_code=FPE_FLTOVF, si_addr=0xf8f21237} ---\n +++ killed by SIGFPE +++\n Floating point exception(CVE-2025-37991)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ndrm/amdgpu/atom: Check kcalloc() for WS buffer in amdgpu_atom_execute_table_locked()\n\nkcalloc() may fail. When WS is non-zero and allocation fails, ectx.ws\nremains NULL while ectx.ws_size is set, leading to a potential NULL\npointer dereference in atom_get_src_int() when accessing WS entries.\n\nReturn -ENOMEM on allocation failure to avoid the NULL dereference.(CVE-2025-68190)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\narm64/fpsimd: signal: Fix restoration of SVE context\n\nWhen SME is supported, Restoring SVE signal context can go wrong in a\nfew ways, including placing the task into an invalid state where the\nkernel may read from out-of-bounds memory (and may potentially take a\nfatal fault) and/or may kill the task with a SIGKILL.\n\n(1) Restoring a context with SVE_SIG_FLAG_SM set can place the task into\n    an invalid state where SVCR.SM is set (and sve_state is non-NULL)\n    but TIF_SME is clear, consequently resuting in out-of-bounds memory\n    reads and/or killing the task with SIGKILL.\n\n    This can only occur in unusual (but legitimate) cases where the SVE\n    signal context has either been modified by userspace or was saved in\n    the context of another task (e.g. as with CRIU), as otherwise the\n    presence of an SVE signal context with SVE_SIG_FLAG_SM implies that\n    TIF_SME is already set.\n\n    While in this state, task_fpsimd_load() will NOT configure SMCR_ELx\n    (leaving some arbitrary value configured in hardware) before\n    restoring SVCR and attempting to restore the streaming mode SVE\n    registers from memory via sve_load_state(). As the value of\n    SMCR_ELx.LEN may be larger than the task's streaming SVE vector\n    length, this may read memory outside of the task's allocated\n    sve_state, reading unrelated data and/or triggering a fault.\n\n    While this can result in secrets being loaded into streaming SVE\n    registers, these values are never exposed. As TIF_SME is clear,\n    fpsimd_bind_task_to_cpu() will configure CPACR_ELx.SMEN to trap EL0\n    accesses to streaming mode SVE registers, so these cannot be\n    accessed directly at EL0. As fpsimd_save_user_state() verifies the\n    live vector length before saving (S)SVE state to memory, no secret\n    values can be saved back to memory (and hence cannot be observed via\n    ptrace, signals, etc).\n\n    When the live vector length doesn't match the expected vector length\n    for the task, fpsimd_save_user_state() will send a fatal SIGKILL\n    signal to the task. Hence the task may be killed after executing\n    userspace for some period of time.\n\n(2) Restoring a context with SVE_SIG_FLAG_SM clear does not clear the\n    task's SVCR.SM. If SVCR.SM was set prior to restoring the context,\n    then the task will be left in streaming mode unexpectedly, and some\n    register state will be combined inconsistently, though the task will\n    be left in legitimate state from the kernel's PoV.\n\n    This can only occur in unusual (but legitimate) cases where ptrace\n    has been used to set SVCR.SM after entry to the sigreturn syscall,\n    as syscall entry clears SVCR.SM.\n\n    In these cases, the the provided SVE register data will be loaded\n    into the task's sve_state using the non-streaming SVE vector length\n    and the FPSIMD registers will be merged into this using the\n    streaming SVE vector length.\n\nFix (1) by setting TIF_SME when setting SVCR.SM. This also requires\nensuring that the task's sme_state has been allocated, but as this could\ncontain live ZA state, it should not be zeroed. Fix (2) by clearing\nSVCR.SM when restoring a SVE signal context with SVE_SIG_FLAG_SM clear.\n\nFor consistency, I've pulled the manipulation of SVCR, TIF_SVE, TIF_SME,\nand fp_type earlier, immediately after the allocation of\nsve_state/sme_state, before the restore of the actual register state.\nThis makes it easier to ensure that these are always modified\nconsistently, even if a fault is taken while reading the register data\nfrom the signal context. I do not expect any software to depend on the\nexact state restored when a fault is taken while reading the context.(CVE-2026-23102)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet: ncsi: fix skb leak in error paths\n\nEarly return paths in NCSI RX and AEN handlers fail to release\nthe received skb, resulting in a memory leak.\n\nSpecifically, ncsi_aen_handler() returns on invalid AEN packets\nwithout consuming the skb. Similarly, ncsi_rcv_rsp() exits early\nwhen failing to resolve the NCSI device, response handler, or\nrequest, leaving the skb unfreed.(CVE-2026-43373)\n\nIn the Linux kernel, the following vulnerability has been resolved:  selinux: fix overlayfs mmap() and mprotect() access checks  The existing SELinux security model for overlayfs is to allow access if the current task is able to access the top level file (the "user" file) and the mounter's credentials are sufficient to access the lower level file (the "backing" file).  Unfortunately, the current code does not properly enforce these access controls for both mmap() and mprotect() operations on overlayfs filesystems.  This patch makes use of the newly created security_mmap_backing_file() LSM hook to provide the missing backing file enforcement for mmap() operations, and leverages the backing file API and new LSM blob to provide the necessary information to properly enforce the mprotect() access controls.  The Linux kernel CVE team has assigned CVE-2026-46054 to this issue.(CVE-2026-46054)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nfbcon: Avoid OOB font access if console rotation fails\n\nClear the font buffer if the reallocation during console rotation fails\nin fbcon_rotate_font(). The putcs implementations for the rotated buffer\nwill return early in this case. See [1] for an example.\n\nCurrently, fbcon_rotate_font() keeps the old buffer, which is too small\nfor the rotated font. Printing to the rotated console with a high-enough\ncharacter code will overflow the font buffer.\n\nv2:\n- fix typos in commit message(CVE-2026-46191)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nvsock: fix buffer size clamping order\n\nIn vsock_update_buffer_size(), the buffer size was being clamped to the\nmaximum first, and then to the minimum. If a user sets a minimum buffer\nsize larger than the maximum, the minimum check overrides the maximum\ncheck, inverting the constraint.\n\nThis breaks the intended socket memory boundaries by allowing the\nvsk->buffer_size to grow beyond the configured vsk->buffer_max_size.\n\nFix this by checking the minimum first, and then the maximum. This\nensures the buffer size never exceeds the buffer_max_size.(CVE-2026-46234)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nBluetooth: hci_uart: fix UAFs and race conditions in close and init paths\n\nVulnerabilities leading to Use-After-Free (UAF) and Null Pointer\nDereference (NPD) conditions were observed in the lifecycle management\nof hci_uart.\n\nThe primary issue arises because the workqueues (init_ready and\nwrite_work) are only flushed/cancelled if the HCI_UART_PROTO_READY\nflag is set during TTY close. If a hangup occurs before setup completes,\nhci_uart_tty_close() skips the teardown of these workqueues and\nproceeds to free the `hu` struct. When the scheduled work executes\nlater, it blindly dereferences the freed `hu` struct.\n\nFurthermore, several data races and UAFs were identified in the teardown\nsequence:\n1. Calling hci_uart_flush() from hci_uart_close() without effectively\n   disabling write_work causes a race condition where both can concurrently\n   double-free hu->tx_skb. This happens because protocol timers can\n   concurrently invoke hci_uart_tx_wakeup() and requeue write_work.\n2. Calling hci_free_dev(hdev) before hu->proto->close(hu) causes a UAF\n   when vendor specific protocol close callbacks dereference hu->hdev.\n3. In the initialization error paths, failing to take the proto_lock\n   write lock before clearing PROTO_READY leads to races with active\n   readers. Additionally, hci_uart_tty_receive() accesses hu->hdev\n   outside the read lock, leading to UAFs if the initialization error\n   path frees hdev concurrently.\n\nFix these synchronization and lifecycle issues by:\n1. Re-ordering hci_uart_tty_close() to clear HCI_UART_PROTO_READY first,\n   followed immediately by a cancel_work_sync(&hu->write_work). Clearing\n   the flag locks out concurrent protocol timers from successfully invoking\n   hci_uart_tx_wakeup(), effectively rendering the cancellation permanent\n   and preventing the tx_skb double-free.\n2. Note: Clearing PROTO_READY early causes hci_uart_close() to skip\n   hu->proto->flush(). This is perfectly safe in the tty_close path\n   because hu->proto->close() executes shortly after, which intrinsically\n   purges all protocol SKB queues and tears down the state.\n3. Relocating hu->proto->close(hu) strictly prior to hci_free_dev(hdev)\n   across all close and error paths to prevent vendor-level UAFs.\n4. Moving the hdev->stat.byte_rx increment in hci_uart_tty_receive()\n   inside the proto_lock read-side critical section to safely synchronize\n   with device unregistration.\n5. Adding cancel_work_sync(&hu->write_work) to hci_uart_close() to safely\n   flush the workqueue before hci_uart_flush() is invoked via the HCI core.\n6. Utilizing cancel_work_sync() instead of disable_work_sync() across\n   all paths to prevent permanently breaking user-space retry capabilities.(CVE-2026-46275)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nfs/ntfs3: terminate the cached volume label after UTF-8 conversion\n\nntfs_fill_super() loads the on-disk volume label with utf16s_to_utf8s()\nand stores the result in sbi->volume.label. The converted label is later\nexposed through ntfs3_label_show() using %s, but utf16s_to_utf8s() only\nreturns the number of bytes written and does not add a trailing NUL.\n\nIf the converted label fills the entire fixed buffer,\nntfs3_label_show() can read past the end of sbi->volume.label while\nlooking for a terminator.\n\nTerminate the cached label explicitly after a successful conversion and\nclamp the exact-full case to the last byte of the buffer.(CVE-2026-53023)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nocfs2/dlm: validate qr_numregions in dlm_match_regions()\n\nPatch series "ocfs2/dlm: fix two bugs in dlm_match_regions()".\n\nIn dlm_match_regions(), the qr_numregions field from a DLM_QUERY_REGION\nnetwork message is used to drive loops over the qr_regions buffer without\nsufficient validation.  This series fixes two issues:\n\n- Patch 1 adds a bounds check to reject messages where qr_numregions\n  exceeds O2NM_MAX_REGIONS. The o2net layer only validates message\n  byte length; it does not constrain field values, so a crafted message\n  can set qr_numregions up to 255 and trigger out-of-bounds reads past\n  the 1024-byte qr_regions buffer.\n\n- Patch 2 fixes an off-by-one in the local-vs-remote comparison loop,\n  which uses '<=' instead of '<', reading one entry past the valid range\n  even when qr_numregions is within bounds.\n\n\nThis patch (of 2):\n\nThe qr_numregions field from a DLM_QUERY_REGION network message is used\ndirectly as loop bounds in dlm_match_regions() without checking against\nO2NM_MAX_REGIONS.  Since qr_regions is sized for at most O2NM_MAX_REGIONS\n(32) entries, a crafted message with qr_numregions > 32 causes\nout-of-bounds reads past the qr_regions buffer.\n\nAdd a bounds check for qr_numregions before entering the loops.(CVE-2026-53043)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nwifi: rtlwifi: pci: fix possible use-after-free caused by unfinished irq_prepare_bcn_tasklet\n\nThe irq_prepare_bcn_tasklet is initialized in rtl_pci_init() and\nscheduled when RTL_IMR_BCNINT interrupt is triggered by hardware.\nBut it is never killed in rtl_pci_deinit(). When the rtlwifi card\nprobe fails or is being detached, the ieee80211_hw is deallocated.\nHowever, irq_prepare_bcn_tasklet may still be running or pending,\nleading to use-after-free when the freed ieee80211_hw is accessed\nin _rtl_pci_prepare_bcn_tasklet().\n\nSimilar to irq_tasklet, add tasklet_kill() in rtl_pci_deinit() to\nensure that irq_prepare_bcn_tasklet is properly terminated before\nthe ieee80211_hw is released.\n\nThe issue was identified through static analysis.(CVE-2026-53112)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nPCI: 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-53120)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet: ip_gre: require CAP_NET_ADMIN in the device netns for changelink\n\nA tunnel changelink() operates on at most two netns, dev_net(dev) and\nthe tunnel link netns t->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 t->net can rewrite a tunnel that\nlives in t->net.\n\nAdd rtnl_dev_link_net_capable() next to rtnl_get_net_ns_capable() in\nnet/core/rtnetlink.c. It requires CAP_NET_ADMIN in the link netns and is\nskipped when the link netns is dev_net(dev), where the rtnl path already\nchecked it. The other patches in this series use the same helper.\n\nGate ipgre_changelink() and erspan_changelink() with it, at the top of\nthe op before any attribute is parsed, because the parsers update live\ntunnel fields first. ipgre_netlink_parms() sets t->collect_md before\nip_tunnel_changelink() runs.\n\nCommit 8b484efd5cb4 ("ip6: vti: Use ip6_tnl.net in\nvti6_siocdevprivate().") added the same check on the ioctl path. This\nadds it on RTM_NEWLINK.(CVE-2026-63829)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nipv6: validate extension header length before copying to cmsg\n\nip6_datagram_recv_specific_ctl() builds IPV6_{HOPOPTS,DSTOPTS,RTHDR}\ncmsgs (and their IPV6_2292* legacy counterparts) by trusting the\non-wire hdrlen byte (ptr[1]) when computing the put_cmsg() length.\nThe length was validated only at parse time (ipv6_parse_hopopts(),\netc.).  An nftables payload-write expression can rewrite hdrlen after\nparsing and before the skb reaches recvmsg; the write itself is\nin-bounds but put_cmsg() then reads up to ((hdrlen+1) << 3) = 2040\nbytes from an 8-byte header.  nftables is reachable from an\nunprivileged user namespace, so this is an unprivileged\nslab-out-of-bounds read:\n\n  BUG: KASAN: slab-out-of-bounds in put_cmsg+0x3ac/0x540\n   put_cmsg+0x3ac/0x540\n   udpv6_recvmsg+0xca0/0x1250\n   sock_recvmsg+0xdf/0x190\n   ____sys_recvmsg+0x1b1/0x620\n\nAdd ipv6_get_exthdr_len() which validates that at least two bytes\nare accessible before reading the hdrlen field, then checks the\ncomputed length against skb_tail_pointer(skb), returning 0 on\nfailure.  Extension headers are kept in the linear skb area by\npskb_may_pull() during input, so skb_tail_pointer() is the correct\nbound.\n\nUse ipv6_get_exthdr_len() at all non-AH call sites: the five\nstandalone cmsg blocks (HbH, 2292HbH, 2292DSTOPTS x2, 2292RTHDR)\nand the three standard cases in the extension-header walk loop\n(DSTOPTS, ROUTING, default).  AH retains an inline bounds check\nbecause its length formula differs ((ptr[1]+2)<<2).\n\nThe walk loop also gets a pre-read bounds check at the top to\nvalidate ptr before any case accesses ptr[0] or ptr[1].\n\nWhen the walk loop detects a corrupted header, return from the\nfunction instead of continuing to process later socket options.(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\nnetfilter: synproxy: refresh tcphdr after skb_ensure_writable\n\nsynproxy_tstamp_adjust() rewrites the TCP timestamp option in place\nand then patches the TCP checksum via inet_proto_csum_replace4() on\nthe caller-supplied tcphdr pointer.  Both ipv4_synproxy_hook() and\nipv6_synproxy_hook() obtain that pointer with skb_header_pointer()\nbefore calling in, so it may either alias skb->head directly or\npoint at the caller's on-stack _tcph buffer.\n\nBetween obtaining the pointer and using it, the function calls\nskb_ensure_writable(skb, optend), which on a cloned or non-linear\nskb invokes pskb_expand_head() and frees the old skb->head.  After\nthat point the cached th is stale:\n\n    caller (ipv[46]_synproxy_hook)\n      th = skb_header_pointer(skb, ..., &_tcph)\n      synproxy_tstamp_adjust(skb, protoff, th, ...)\n        skb_ensure_writable(skb, optend)\n          pskb_expand_head()        /* kfree(old skb->head) */\n        ...\n        inet_proto_csum_replace4(&th->check, ...)\n                                    /* writes into freed head, or\n                                       into the caller's stack copy\n                                       leaving the on-wire checksum\n                                       stale */\n\nThe option bytes are written through skb->data and are fine; only\nthe checksum update goes through th and so lands in the wrong\nplace.  The result is either a write into freed slab memory or a\npacket leaving with a checksum that does not match its payload.\n\nFix by re-deriving th from skb->data + protoff immediately after\nskb_ensure_writable() succeeds, so the subsequent checksum update\ntargets the linear, writable header.(CVE-2026-64007)\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\nALSA: asihpi: Fix potential OOB array access at reading cache\n\nfind_control() to retrieve a cached info accesses the array with the\ngiven index blindly, which may lead to an OOB array access.\nAdd a sanity check for avoiding it.(CVE-2026-64133)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nfuse: re-lock request before returning from fuse_ref_folio()\n\nfuse_ref_folio() unlocks the request but does not re-lock it before\nreturning. fuse_chan_abort() can end the request and the async end\ncallback (eg fuse_writepage_free()) can free the args while the\nsubsequent copy chain logic after fuse_ref_folio() accesses them,\nleading to use-after-free issues.\n\nFix this by locking the request in fuse_ref_folio() before returning.(CVE-2026-64266)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet: ipv4: bound TCP reordering sysctl writes and MTU probe sizes\n\nReject invalid `net.ipv4.tcp_reordering` values before they reach TCP\nsocket state. The sysctl is stored as an `int` but copied into the\n`u32` `tp->reordering` field for new sockets, so negative writes wrap\nto large values.\n\nWith `tcp_mtu_probing=2`, the wrapped value can overflow the\n`tcp_mtu_probe()` size calculation and drive the MTU probing path into\nan out-of-bounds read. Route `tcp_reordering` writes through\n`proc_dointvec_minmax()` and require it to be at least 1. Also require\n`tcp_max_reordering` to be at least 1 so the configured maximum cannot\nbecome negative either.\n\nWhen registering the table for a non-init network namespace, relocate\n`extra2` pointers that refer into `init_net.ipv4` so the\n`tcp_reordering` upper bound follows that namespace's\n`tcp_max_reordering`.\n\nHarden `tcp_mtu_probe()` itself by computing `size_needed` as `u64`.\nThis keeps the send queue and window checks from being bypassed through\nsigned integer overflow.(CVE-2026-64422)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet: af_key: initialize alg_key_len for IPComp states\n\npfkey_msg2xfrm_state() handles the IPComp (SADB_X_SATYPE_IPCOMP) case by\nallocating x->calg and copying only the algorithm name:\n\n\tx->calg = kmalloc_obj(*x->calg);\n\tif (!x->calg) {\n\t\terr = -ENOMEM;\n\t\tgoto out;\n\t}\n\tstrcpy(x->calg->alg_name, a->name);\n\tx->props.calgo = sa->sadb_sa_encrypt;\n\nUnlike the authentication (x->aalg) and encryption (x->ealg) branches of\nthe same function, the compression branch never initializes\ncalg->alg_key_len.  IPComp carries no key and the allocation only\nreserves sizeof(struct xfrm_algo) (i.e. no room for a key), so the field\nis left containing uninitialized slab data.\n\ncalg->alg_key_len is later used as a length by xfrm_algo_clone() when an\nIPComp state is cloned during XFRM_MSG_MIGRATE:\n\n\txfrm_state_migrate()\n\t  xfrm_state_clone_and_setup()\n\t    x->calg = xfrm_algo_clone(orig->calg);\n\t      kmemdup(orig, xfrm_alg_len(orig));\n\nwhere xfrm_alg_len() returns sizeof(*alg) + (alg_key_len + 7) / 8.  With\na non-zero garbage alg_key_len, kmemdup() reads past the end of the\n68-byte calg object.  Adding an IPComp SA via PF_KEY and then migrating\nit triggers (net-next, KASAN, init_on_alloc=0):\n\n  BUG: KASAN: slab-out-of-bounds in kmemdup_noprof+0x44/0x60\n  Read of size 4164 at addr ff11000025a74980 by task diag2/9287\n  CPU: 3 UID: 0 PID: 9287 Comm: diag2 7.1.0-rc6-g903db046d557 #1\n  Call Trace:\n   <TASK>\n   dump_stack_lvl+0x10e/0x1f0\n   print_report+0xf7/0x600\n   kasan_report+0xe4/0x120\n   kasan_check_range+0x105/0x1b0\n   __asan_memcpy+0x23/0x60\n   kmemdup_noprof+0x44/0x60\n   xfrm_state_migrate+0x70a/0x1da0\n   xfrm_migrate+0x753/0x18a0\n   xfrm_do_migrate+0xb47/0xf10\n   xfrm_user_rcv_msg+0x411/0xb50\n   netlink_rcv_skb+0x158/0x420\n   xfrm_netlink_rcv+0x71/0x90\n   netlink_unicast+0x584/0x850\n   netlink_sendmsg+0x8b0/0xdc0\n   ____sys_sendmsg+0x9f7/0xb90\n   ___sys_sendmsg+0x134/0x1d0\n   __sys_sendmsg+0x16d/0x220\n   do_syscall_64+0x116/0x7d0\n   entry_SYSCALL_64_after_hwframe+0x77/0x7f\n   </TASK>\n\n  Allocated by task 9287:\n   kasan_save_stack+0x33/0x60\n   kasan_save_track+0x14/0x30\n   __kasan_kmalloc+0xaa/0xb0\n   pfkey_add+0x2652/0x2ea0\n   pfkey_process+0x6d0/0x830\n   pfkey_sendmsg+0x42c/0x850\n   __sys_sendto+0x461/0x4b0\n   __x64_sys_sendto+0xe0/0x1c0\n   do_syscall_64+0x116/0x7d0\n   entry_SYSCALL_64_after_hwframe+0x77/0x7f\n\n  The buggy address belongs to the object at ff11000025a74980\n   which belongs to the cache kmalloc-96 of size 96\n  The buggy address is located 0 bytes inside of\n   allocated 68-byte region [ff11000025a74980, ff11000025a749c4)\n\nDepending on the uninitialized value the same field can instead request\nan oversized kmemdup() allocation and make the migration clone fail.\n\nThe XFRM netlink path is not affected: verify_one_alg() rejects an\nXFRMA_ALG_COMP attribute shorter than xfrm_alg_len(), so a calg added via\nXFRM_MSG_NEWSA is always self-consistent.\n\nInitialize calg->alg_key_len to 0, matching the aalg/ealg branches.(CVE-2026-64436)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ndrm/edid: fix OOB read in drm_parse_tiled_block()\n\ndrm_parse_tiled_block() casts the DisplayID block to a\nstruct displayid_tiled_block and reads the full fixed layout up to\ntile->topology_id[7] without checking block->num_bytes. The DisplayID\niterator only validates the declared payload length, so a crafted EDID\ncan advertise a tiled-display block (tag DATA_BLOCK_TILED_DISPLAY, or\nDATA_BLOCK_2_TILED_DISPLAY_TOPOLOGY for v2.0) with a small num_bytes at\nthe end of a DisplayID extension. The read then runs past the end of the\nexact-sized kmemdup()'d EDID allocation, a heap out-of-bounds read.\n\nReject blocks shorter than the spec's 22-byte tiled payload before\nreading the fixed struct, as drm_parse_vesa_mso_data() already does.\n\n  BUG: KASAN: slab-out-of-bounds in drm_edid_connector_update\n  Read of size 2 at addr ffff888010077700 by task exploit/147\n   dump_stack_lvl (lib/dump_stack.c:94 ...)\n   print_report (mm/kasan/report.c:378 ...)\n   kasan_report (mm/kasan/report.c:595)\n   drm_edid_connector_update (drivers/gpu/drm/drm_edid.c:7581)\n   bochs_connector_helper_get_modes (drivers/gpu/drm/tiny/bochs.c:574)\n   drm_helper_probe_single_connector_modes (drivers/gpu/drm/drm_probe_helper.c:426)\n   status_store (drivers/gpu/drm/drm_sysfs.c:219)\n   ...\n   vfs_write (fs/read_write.c:595 fs/read_write.c:688)\n   ksys_write (fs/read_write.c:740)(CVE-2026-64546)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nBluetooth: qca: fix NVM tag length underflow in TLV parser\n\nIn the TLV_TYPE_NVM branch of qca_tlv_check_data() the tag loop bound is\n"while (idx < length - sizeof(struct tlv_type_nvm))". "length" is a signed\nint from the firmware TLV header and sizeof(struct tlv_type_nvm) is a\nsize_t (12), so "length" is converted to size_t and any firmware-supplied\n"length" < 12 makes the subtraction wrap to a huge value. The loop body\nthen reads a 12-byte struct tlv_type_nvm past the end of the short\nvmalloc'd firmware buffer (and the EDL_TAG_ID_* handlers can write past it).\n\nRewrite the bound as "idx + sizeof(struct tlv_type_nvm) <= length"; both\noperands are non-negative, so it no longer underflows and a "length" too\nsmall for one record correctly skips the loop.\n\n  BUG: KASAN: vmalloc-out-of-bounds in qca_download_firmware.isra.0 (drivers/bluetooth/btqca.c:421)\n  Read of size 2 at addr ffffc900000e5004 by task kworker/u9:0/52\n  Workqueue: hci0 hci_power_on\n  Call Trace:\n   ...\n   kasan_report (mm/kasan/report.c:595)\n   qca_download_firmware.isra.0 (drivers/bluetooth/btqca.c:421 drivers/bluetooth/btqca.c:617)\n   qca_uart_setup (drivers/bluetooth/btqca.c:948)\n   qca_setup (drivers/bluetooth/hci_qca.c:2029)\n   hci_uart_setup (drivers/bluetooth/hci_ldisc.c:438)\n   hci_dev_open_sync (net/bluetooth/hci_sync.c:5227)\n   hci_power_on (net/bluetooth/hci_core.c:920)\n   process_one_work (kernel/workqueue.c:3322)\n   worker_thread (kernel/workqueue.c:3486)\n   kthread (kernel/kthread.c:436)\n   ret_from_fork (arch/x86/kernel/process.c:158)\n   ret_from_fork_asm (arch/x86/entry/entry_64.S:245)(CVE-2026-64573)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nceph: fix pre-auth out-of-bounds read on snaptrace in ceph_handle_caps()\n\nceph_handle_caps() reads snap_trace_len from the wire-format\nceph_mds_caps header and uses it unconditionally to build a fake\nend pointer (snaptrace + snaptrace_len) that is later handed to\nceph_update_snap_trace() in the CEPH_CAP_OP_IMPORT case:\n\n    snaptrace     = h + 1;\n    snaptrace_len = le32_to_cpu(h->snap_trace_len);\n    p             = snaptrace + snaptrace_len;\n    ...\n    case CEPH_CAP_OP_IMPORT:\n        if (snaptrace_len) {\n            ...\n            if (ceph_update_snap_trace(mdsc, snaptrace,\n                                       snaptrace + snaptrace_len,\n                                       false, &realm)) { ... }\n\nceph_update_snap_trace() then decodes a struct ceph_mds_snap_realm\nfrom snaptrace using ceph_decode_need(&p, e, sizeof(*ri), bad)\nwith the attacker-supplied fake end e == snaptrace + snaptrace_len.\nWith snaptrace_len == 0xFFFFFFFF the bound check is trivially\nsatisfied, ri = p reads sizeof(struct ceph_mds_snap_realm) past\nthe legitimate msg->front buffer, and ri->num_snaps /\nri->num_prior_parent_snaps then drive further out-of-bounds\nreads of the encoded snap arrays.\n\nThe eleven msg_version >= 2 .. msg_version >= 12 decoder blocks\nabove the op switch each catch this OOB through their\nceph_decode_*_safe() / ceph_decode_need() helpers, but they sit\nbehind a hdr.version-gated if, so a malicious or compromised\nMDS that sets msg->hdr.version = 1 reaches the IMPORT path with\nno version-gated decoder having validated snap_trace_len. The\nshape has been present since ceph_handle_caps() was introduced.\n\nValidate snap_trace_len against the message front buffer before\nconsuming it, using the canonical ceph_decode_need() / ceph_has_room()\nhelper.  The helper bounds the length with subtraction (n <= end - p,\nguarded by end >= p) rather than pointer addition, so it is wrap-safe\nfor the attacker-controlled u32 length on 32-bit builds where\np + snap_trace_len could overflow the address space.  This matches the\nrest of the ceph decode path (e.g. the pool_ns_len check a few lines\nbelow), and the existing goto bad cleanup already covers this exit\npath.(CVE-2026-68160)\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\nnetfilter: xt_u32: reject invalid shift counts\n\nu32_match_it() executes rule-supplied shift operands on a 32-bit\nvalue. A malformed u32 rule can provide a shift count of 32 or more,\ntriggering an undefined shift out-of-bounds during packet evaluation.\n\nValidate XT_U32_LEFTSH and XT_U32_RIGHTSH operands in\nu32_mt_checkentry() and reject malformed rules before they reach the\npacket path.(CVE-2026-72350)","affected":[{"package":{"ecosystem":"openEuler:22.03-LTS-SP4","name":"kernel","purl":"pkg:rpm/openEuler/kernel&distro=openEuler-22.03-LTS-SP4"},"ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"5.10.0-330.0.0.231.oe2203sp4"}]}],"ecosystem_specific":{"aarch64":["bpftool-5.10.0-330.0.0.231.oe2203sp4.aarch64.rpm","bpftool-debuginfo-5.10.0-330.0.0.231.oe2203sp4.aarch64.rpm","kernel-5.10.0-330.0.0.231.oe2203sp4.aarch64.rpm","kernel-debuginfo-5.10.0-330.0.0.231.oe2203sp4.aarch64.rpm","kernel-debugsource-5.10.0-330.0.0.231.oe2203sp4.aarch64.rpm","kernel-devel-5.10.0-330.0.0.231.oe2203sp4.aarch64.rpm","kernel-headers-5.10.0-330.0.0.231.oe2203sp4.aarch64.rpm","kernel-source-5.10.0-330.0.0.231.oe2203sp4.aarch64.rpm","kernel-tools-5.10.0-330.0.0.231.oe2203sp4.aarch64.rpm","kernel-tools-debuginfo-5.10.0-330.0.0.231.oe2203sp4.aarch64.rpm","kernel-tools-devel-5.10.0-330.0.0.231.oe2203sp4.aarch64.rpm","perf-5.10.0-330.0.0.231.oe2203sp4.aarch64.rpm","perf-debuginfo-5.10.0-330.0.0.231.oe2203sp4.aarch64.rpm","python3-perf-5.10.0-330.0.0.231.oe2203sp4.aarch64.rpm","python3-perf-debuginfo-5.10.0-330.0.0.231.oe2203sp4.aarch64.rpm"],"src":["kernel-5.10.0-330.0.0.231.oe2203sp4.src.rpm"],"x86_64":["bpftool-5.10.0-330.0.0.231.oe2203sp4.x86_64.rpm","bpftool-debuginfo-5.10.0-330.0.0.231.oe2203sp4.x86_64.rpm","kernel-5.10.0-330.0.0.231.oe2203sp4.x86_64.rpm","kernel-debuginfo-5.10.0-330.0.0.231.oe2203sp4.x86_64.rpm","kernel-debugsource-5.10.0-330.0.0.231.oe2203sp4.x86_64.rpm","kernel-devel-5.10.0-330.0.0.231.oe2203sp4.x86_64.rpm","kernel-headers-5.10.0-330.0.0.231.oe2203sp4.x86_64.rpm","kernel-source-5.10.0-330.0.0.231.oe2203sp4.x86_64.rpm","kernel-tools-5.10.0-330.0.0.231.oe2203sp4.x86_64.rpm","kernel-tools-debuginfo-5.10.0-330.0.0.231.oe2203sp4.x86_64.rpm","kernel-tools-devel-5.10.0-330.0.0.231.oe2203sp4.x86_64.rpm","perf-5.10.0-330.0.0.231.oe2203sp4.x86_64.rpm","perf-debuginfo-5.10.0-330.0.0.231.oe2203sp4.x86_64.rpm","python3-perf-5.10.0-330.0.0.231.oe2203sp4.x86_64.rpm","python3-perf-debuginfo-5.10.0-330.0.0.231.oe2203sp4.x86_64.rpm"]}}],"references":[{"type":"ADVISORY","url":"https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2026-3532"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2022-49289"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-37991"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-68190"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-23102"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-43373"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-46054"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-46191"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-46234"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-46275"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-53023"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-53043"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-53112"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-53120"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-63829"},{"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-64007"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-64114"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-64133"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-64266"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-64422"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-64436"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-64546"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-64573"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-68160"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-72135"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-72350"}],"severity":[{"type":"CVSS_V3","score":"CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H"}],"database_specific":{"severity":"Critical"}}