{"id":"OESA-2026-3703","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\nASoC: qcom: Fix sc7280 lpass potential buffer overflow\n\nCase values introduced in commit\n5f78e1fb7a3e ("ASoC: qcom: Add driver support for audioreach solution")\ncause out of bounds access in arrays of sc7280 driver data (e.g. in case\nof RX_CODEC_DMA_RX_0 in sc7280_snd_hw_params()).\n\nRedefine LPASS_MAX_PORTS to consider the maximum possible port id for\nq6dsp as sc7280 driver utilizes some of those values.\n\nFound by Linux Verification Center (linuxtesting.org) with SVACE.(CVE-2025-37979)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet: usb: asix_devices: Fix PHY address mask in MDIO bus initialization\n\nSyzbot reported shift-out-of-bounds exception on MDIO bus initialization.\n\nThe PHY address should be masked to 5 bits (0-31). Without this\nmask, invalid PHY addresses could be used, potentially causing issues\nwith MDIO bus operations.\n\nFix this by masking the PHY address with 0x1f (31 decimal) to ensure\nit stays within the valid range.(CVE-2025-38736)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ncrypto: af_alg - Fix page reassignment overflow in af_alg_pull_tsgl\n\nWhen page reassignment was added to af_alg_pull_tsgl the original\nloop wasn't updated so it may try to reassign one more page than\nnecessary.\n\nAdd the check to the reassignment so that this does not happen.\n\nAlso update the comment which still refers to the obsolete offset\nargument.(CVE-2026-43078)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ncrypto: algif_aead - snapshot IV for async AEAD requests\n\nAF_ALG AEAD AIO requests currently use the socket-wide IV buffer during\nrequest processing.  For async requests, later socket activity can\nupdate that shared state before the original request has fully\ncompleted, which can lead to inconsistent IV handling.\n\nSnapshot the IV into per-request storage when preparing the AEAD\nrequest, so in-flight operations no longer depend on mutable socket\nstate.(CVE-2026-46028)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nxfrm: esp: restore combined single-frag length gate\n\nThe ESP out-of-place fast path appends the trailer in esp_output_head()\nbefore esp_output_tail() allocates the destination page frag. The\nhead-side gate currently checks skb->data_len and tailen separately, but\nthe tail code allocates a single destination frag from the combined\npost-trailer skb->data_len.\n\nReject the page-frag fast path when the combined aligned length exceeds a\npage. Otherwise skb_page_frag_refill() may fall back to a single page while\nthe destination sg still spans the combined skb->data_len.\n\nRestore this combined-length page gate for both IPv4 and IPv6.(CVE-2026-63912)\n\nIn the Linux kernel, the following vulnerability has been resolved: ipvs: reload ip header after head reallocation. __ip_vs_get_out_rt() calls skb_ensure_writable() which may reallocate skb->head, causing the previously obtained IP header pointer to become a dangling pointer, leading to a use-after-free vulnerability.(CVE-2026-68476)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nipvs: fix more places with wrong ipv6 transport offsets\n\nSashiko reports for more incorrect IPv6 transport offsets.\n\nThe app code for TCP was assuming IPv4 network header\neven after the ipvsh argument was provided. This can\ncause problems with apps over IPv6. As for the only\nofficial app in the kernel tree (FTP) this problem is\nharmless because we use Netfilter to mangle the FTP\nports and we do not adjust the TCP seq numbers.\n\nAlso, provide correct offset of the ICMPV6 header in\nip_vs_out_icmp_v6() for correct checksum checks when\nthe IPv6 packet has extension headers.(CVE-2026-68477)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nipvs: use parsed transport offset in SCTP state lookup\n\nset_sctp_state() reads the SCTP chunk header again in order to drive the\nIPVS SCTP state table. For IPv6 it computes the offset with\nsizeof(struct ipv6hdr), while the surrounding IPVS code uses iph.len from\nip_vs_fill_iph_skb(), where ipv6_find_hdr() has already skipped\nextension headers and found the real transport header.\n\nThis makes the state machine read from the wrong offset for IPv6 SCTP\npackets that carry extension headers. For example, an INIT packet with an\n8-byte destination options header can be scheduled correctly by\nsctp_conn_schedule(), but set_sctp_state() reads the first byte of the\nSCTP verification tag as a DATA chunk type. The connection then moves\nfrom NONE to ESTABLISHED instead of INIT1, gets the longer established\ntimeout, and updates the active/inactive destination counters\nincorrectly. This happens even though the SCTP handshake has not\ncompleted.\n\nUse the parsed transport offset passed down from ip_vs_set_state() for\nthe SCTP chunk-header lookup. For IPv4 and IPv6 packets without\nextension headers this preserves the existing offset.(CVE-2026-72021)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nieee802154: admin-gate legacy LLSEC dump operations\n\nIn net/ieee802154/netlink.c, the legacy IEEE802154_NL family ops table\nbuilds the LLSEC dump entries (LLSEC_LIST_KEY, LLSEC_LIST_DEV,\nLLSEC_LIST_DEVKEY, LLSEC_LIST_SECLEVEL) with IEEE802154_DUMP() which\nsets no .flags, so generic netlink runs them ungated. The modern\nnl802154 family admin-gates the equivalent reads via\nNL802154_CMD_GET_SEC_KEY and friends with .flags = GENL_ADMIN_PERM.\n\nAny local uid that can open AF_NETLINK / NETLINK_GENERIC can resolve\nthe "802.15.4 MAC" family and dump LLSEC_LIST_KEY on any wpan netdev\nthat has an LLSEC key installed; the dump handler writes the raw\n16-byte AES-128 key bytes (IEEE802154_ATTR_LLSEC_KEY_BYTES, copied\nverbatim from struct ieee802154_llsec_key.key) into the reply.\nRecovering the AES key compromises 802.15.4 LLSEC link confidentiality\nand authenticity, since LLSEC uses CCM* and the same key authenticates\nand encrypts frames.\n\nImpact: any local uid with no capabilities can read the raw 16-byte\nAES-128 LLSEC key from the kernel keytable on any wpan netdev that has\nan administrator-installed LLSEC key, by issuing an LLSEC_LIST_KEY\ndump on the legacy IEEE802154_NL generic-netlink family.\n\nIntroduce IEEE802154_DUMP_PRIV() mirroring IEEE802154_DUMP() but\nsetting .flags = GENL_ADMIN_PERM, and use it for the four LLSEC dump\nentries. LIST_PHY and LIST_IFACE retain IEEE802154_DUMP() because the\nmodern nl802154 family exposes their equivalents to unprivileged\nreaders by design (NL802154_CMD_GET_WPAN_PHY and\nNL802154_CMD_GET_INTERFACE carry "can be retrieved by unprivileged\nusers" annotations).(CVE-2026-72049)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet: ip6_gre: require CAP_NET_ADMIN in the device netns for changelink\n\nip6gre_changelink() and ip6erspan_changelink() operate on at most two\nnetns, dev_net(dev) and the tunnel link netns t->net. They differ once\nthe device is created in or moved to a netns other than the one the\nrequest runs in. The rtnl changelink path checks CAP_NET_ADMIN only\nagainst dev_net(dev), so a caller privileged there but not in t->net can\nrewrite a tunnel that lives in t->net.\n\nGate both ops on rtnl_dev_link_net_capable() at their top, before any\nattribute is parsed.(CVE-2026-72052)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet: ipip: require CAP_NET_ADMIN in the device netns for changelink\n\nipip_changelink() operates on at most two netns, dev_net(dev) and the\ntunnel link netns t->net. They differ once the device is created in or\nmoved to a netns other than the one the request runs in. The rtnl\nchangelink path checks CAP_NET_ADMIN only against dev_net(dev), so a\ncaller privileged there but not in t->net can rewrite a tunnel that\nlives in t->net.\n\nGate ipip_changelink() on rtnl_dev_link_net_capable() at its top,\nbefore any attribute is parsed.(CVE-2026-72053)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet: ip_vti: require CAP_NET_ADMIN in the device netns for changelink\n\nvti_changelink() operates on at most two netns, dev_net(dev) and the\ntunnel link netns t->net. They differ once the device is created in or\nmoved to a netns other than the one the request runs in. The rtnl\nchangelink path checks CAP_NET_ADMIN only against dev_net(dev), so a\ncaller privileged there but not in t->net can rewrite a tunnel that\nlives in t->net.\n\nGate vti_changelink() on rtnl_dev_link_net_capable() at its top,\nbefore any attribute is parsed.(CVE-2026-72054)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet: sit: require CAP_NET_ADMIN in the device netns for changelink\n\nipip6_changelink() operates on at most two netns, dev_net(dev) and the\ntunnel link netns t->net. They differ once the device is created in or\nmoved to a netns other than the one the request runs in. The rtnl\nchangelink path checks CAP_NET_ADMIN only against dev_net(dev), so a\ncaller privileged there but not in t->net can rewrite a tunnel that\nlives in t->net.\n\nGate ipip6_changelink() on rtnl_dev_link_net_capable() at its top,\nbefore any attribute is parsed. sit was the one tunnel type not covered\nby the recent series that added this check to the other changelink()\nhandlers.(CVE-2026-72061)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet/mlx5e: macsec: fix use-after-free of metadata_dst on RX SC delete\n\nWhen an offloaded MACsec RX SC is deleted, macsec_del_rxsc_ctx() freed\nthe per-SC metadata_dst with metadata_dst_free(), which kfree()s the\nobject unconditionally and ignores the dst reference count. The RX\ndatapath in mlx5e_macsec_offload_handle_rx_skb() looks up the SC under\nrcu_read_lock() via xa_load(), takes a reference with dst_hold() and\nattaches the dst to the skb with skb_dst_set(). A reader that already\nobtained the rx_sc pointer can race with the delete path and operate on\nfreed memory.\n\nFix the owner side by dropping the reference with dst_release() instead\nof freeing unconditionally, and convert the RX datapath to\ndst_hold_safe() so a reader racing the SC delete cannot attach a dst\nwhose last reference was just dropped; only attach it when a reference\nwas actually taken.\n\nmlx5e_macsec_add_rxsc() also published sc_xarray_element via xa_alloc()\nbefore rx_sc->md_dst was allocated and initialised, so a datapath reader\nthat looked the SC up by fs_id could observe rx_sc with md_dst still\nNULL or, on weakly-ordered architectures, a non-NULL md_dst pointer\nwhose contents were not yet visible. NULL-check the xa_load() result and\nmd_dst on the datapath, and reorder add_rxsc() so the xa_alloc() publish\nhappens only after md_dst is fully initialised; the xarray RCU publish\nthen pairs with the rcu_read_lock()/xa_load() in the datapath.\n\nNote: macsec_del_rxsc_ctx() also kfree()s rx_sc->sc_xarray_element\nwithout an RCU grace period while the same datapath reads it under\nrcu_read_lock(); that is a separate pre-existing issue left to a\nfollow-up patch.\n\nFound by 0sec automated security-research tooling (https://0sec.ai).(CVE-2026-72072)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnvmet-rdma: handle inline data with a nonzero offset\n\nnvmet_rdma_use_inline_sg() maps the host-controlled inline data offset\ninto the per-command inline scatterlist.  The bounds check admits any\noffset with off + len <= inline_data_size, but the mapping still assumes\nthe data begins in the first inline page:\n\n\tsg->offset = off;\n\tsg->length = min_t(int, len, PAGE_SIZE - off);\n\nWhen a port is configured with inline_data_size > PAGE_SIZE (settable up\nto max(SZ_16K, PAGE_SIZE)), an offset in (PAGE_SIZE, inline_data_size]\nmakes "PAGE_SIZE - off" underflow, so sg->length is set to ~4 GiB and\nthe block backend reads far past the first inline page.  num_pages(len)\nalso ignores the offset, so an in-bounds offset whose [off, off+len)\nspan crosses a page boundary under-counts the scatterlist.\n\nMap the offset properly: split it into a page index and an in-page\noffset, start the scatterlist at that page, and size the page count from\npage_off + len.  Because the request scatterlist may now start at\ninline_sg[page_idx] rather than inline_sg[0], generalize the inline-SGL\nidentity test in nvmet_rdma_release_rsp() to a range test; otherwise the\npersistent inline scatterlist is mistaken for an allocated one and\nnvmet_req_free_sgls() frees an inline page (and warns in\nfree_large_kmalloc()).(CVE-2026-72129)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ntpm: Make the TPM character devices non-seekable\n\nThe TPM character devices expose a sequential command/response\ninterface, but their open handlers leave FMODE_PREAD and FMODE_PWRITE\nenabled.\n\nAfter a command leaves a response pending, pread(fd, buf, 16, 0x1400)\npasses 0x1400 as *off to tpm_common_read(). The transfer length is\nbounded by response_length, but the offset is used unchecked when\nforming data_buffer + *off. A sufficiently large offset therefore causes\nan out-of-bounds heap read through copy_to_user() and, if the copy\nsucceeds, an out-of-bounds zero-write through the following memset().\n\nPositional I/O does not provide coherent semantics for this interface.\nAn arbitrary pread offset cannot represent how much of a response has\nbeen consumed sequentially. The write callback always stores a command\nat the start of data_buffer, while pwrite() does not update file->f_pos\nand can leave the sequential read cursor stale.\n\nCall nonseekable_open() from both open handlers. This removes\nFMODE_PREAD and FMODE_PWRITE, causing positional reads and writes to\nfail with -ESPIPE before reaching the TPM callbacks, and explicitly\nmarks the files non-seekable. Normal read() and write() continue to use\nthe existing sequential f_pos cursor, leaving the response state machine\nunchanged.\n\nTested on Linux 6.12 with KASAN and a swtpm TPM2 device:\n\n - sequential partial reads returned the complete response\n - pread() and preadv() with offset 0x1400 returned -ESPIPE\n - pwrite() and pwritev() with offset zero returned -ESPIPE\n - the pending response remained intact after the rejected operations\n - a subsequent normal command/response cycle completed normally\n - no KASAN report was produced.(CVE-2026-72135)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nxfrm: xfrm_interface: require CAP_NET_ADMIN in the device netns for changelink\n\nxfrmi_changelink() operates on at most two netns, dev_net(dev) and the\ninterface link netns xi->net. They differ once the device is created in\nor moved to a netns other than the one the request runs in. The rtnl\nchangelink path checks CAP_NET_ADMIN only against dev_net(dev), so a\ncaller privileged there but not in xi->net can rewrite an interface that\nlives in xi->net.\n\nGate xfrmi_changelink() on rtnl_dev_link_net_capable() at its top,\nbefore any attribute is parsed.(CVE-2026-72136)\n\nIn the Linux kernel, the following vulnerability has been resolved: net: thunderbolt: Fix frags[] overflow by bounding frame_count. tbnet_poll() assembles a multi-frame ThunderboltIP packet into one skb. The first frame goes into the skb linear area and every further frame is added as a page fragment. A packet of frame_count frames therefore ends up with frame_count - 1 fragments. tbnet_check_frame() only bounds the peer supplied frame_count to TBNET_RING_SIZE / 4 (64), which is far above MAX_SKB_FRAGS (17 by default). A peer that sends a packet of 19 or more small frames pushes nr_frags past MAX_SKB_FRAGS, so skb_add_rx_frag() writes past skb_shinfo()->frags[] and corrupts memory after the shared info.(CVE-2026-72157)\n\nIn the Linux kernel, the following vulnerability has been resolved: mm/mm_init: fix uninitialized struct pages for ZONE_DEVICE. If DAX memory is hotplugged into an unoccupied subsection of an early section, section_activate() reuses the unoptimized boot memmap. However, compound_nr_pages() still assumes that vmemmap optimization is in effect and initializes only the reduced number of struct pages. As a result, the remaining tail struct pages are left uninitialized, which can later lead to unexpected behavior or crashes. Fix this by treating early sections as unoptimized when calculating how many struct pages to initialize.(CVE-2026-72172)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nSUNRPC: Bound-check xdr_buf_to_bvec() stores before writing\n\nxdr_buf_to_bvec() writes a bio_vec into the caller's array before\ntesting whether that slot is in range, and the head branch performs\nthe store with no check at all. When the caller's budget is exactly\nused up, the next store lands one element past the end of the array.\nThe overflow label returns count - 1, which masks the surplus store\nbut cannot undo it.\n\nrq_bvec, the array passed by nfsd_vfs_write(), is allocated to\nexactly rq_maxpages entries with no slack. The OOB store can land in\nadjacent slab memory; the bv_len and bv_offset fields written there\nare derived from client-supplied RPC payload sizes.\n\nMove the in-range check ahead of the store in the head, page-loop,\nand tail branches. With the check at the top of each sequence, count\nis incremented only after a successful store, so the overflow label\ncan return count directly.(CVE-2026-72217)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nsunrpc: wait for in-flight TLS handshake callback when cancel loses race\n\nWhen wait_for_completion_interruptible_timeout() in\nsvc_tcp_handshake() returns 0 (timeout) or -ERESTARTSYS (signal) and\ntls_handshake_cancel() then returns false, handshake_complete() has\nwon the cancellation race: it has set HANDSHAKE_F_REQ_COMPLETED and\nis about to invoke svc_tcp_handshake_done(), but the callback's\nside effects on xpt_flags and on svsk->sk_handshake_done have not\nyet committed.\n\nThe current code reads xpt_flags immediately to decide whether the\nsession succeeded. Two races result.\n\nIf the callback has executed set_bit(XPT_TLS_SESSION) but not yet\nclear_bit(XPT_HANDSHAKE), svc_tcp_handshake() sees a session,\nenqueues the transport, and returns. svc_xprt_received() then\nclears XPT_BUSY, a worker thread picks the transport up, the\ndispatcher in svc_handle_xprt() observes XPT_HANDSHAKE still set,\nand xpo_handshake is invoked a second time. That svc_tcp_handshake()\ncalls init_completion(&svsk->sk_handshake_done) while the original\ncallback concurrently calls complete_all() on it, corrupting the\nembedded swait_queue.\n\nIf the callback has set HANDSHAKE_F_REQ_COMPLETED but not yet\nentered svc_tcp_handshake_done(), svc_tcp_handshake() reads\nXPT_TLS_SESSION as clear and tears the connection down even though\nthe handshake is about to succeed.\n\nWait for the callback to commit before inspecting xpt_flags. The\ncompletion is guaranteed to fire because handshake_complete()\ninvokes svc_tcp_handshake_done() unconditionally once it has set\nHANDSHAKE_F_REQ_COMPLETED.(CVE-2026-72221)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nsunrpc: pin svc_xprt across the asynchronous TLS handshake callback\n\nsvc_tcp_handshake() stores the raw svc_xprt pointer in\ntls_handshake_args.ta_data and submits the request through\ntls_server_hello_x509(). The handshake core takes only\nsock_hold(req->hr_sk); nothing references the embedding struct\nsvc_sock that svc_tcp_handshake_done() reaches via container_of().\n\nTwo close races leave the in-flight callback writing through a freed\nsvc_sock. svc_sock_free() calls tls_handshake_cancel() and discards\nits return value: a false return means handshake_complete() has\nalready set HANDSHAKE_F_REQ_COMPLETED but hp_done() may not have\nfinished, yet svc_sock_free() proceeds to kfree(svsk). The\ncancel-loser fall-through inside svc_tcp_handshake() itself produces\nthe same window: when wait_for_completion_interruptible_timeout()\nreturns <= 0 (timeout or signal) and tls_handshake_cancel() returns\nfalse, the function does not drain, returns, and svc_handle_xprt()\ncalls svc_xprt_received(), which clears XPT_BUSY and can drop the\nlast reference. A concurrent close then runs svc_sock_free() while\nsvc_tcp_handshake_done() is still updating xpt_flags and walking\nsvsk->sk_handshake_done.\n\nThe corruption surfaces as set_bit/clear_bit RMW into the freed\nxpt_flags slab slot and as complete_all() walking and writing the\nfreed wait_queue_head_t list embedded in sk_handshake_done -- a\nslab-corruption primitive, not a benign read. The path is reachable\non any TLS-enabled NFS server whenever a connection close overlaps\nthe tlshd downcall delivery window; the interruptible wait means\nsignal delivery suffices, not just SVC_HANDSHAKE_TO expiry.\n\nTake svc_xprt_get(xprt) immediately before tls_server_hello_x509()\nso the in-flight callback owns its own reference. Release it on the\ntwo edges where the callback is guaranteed not to fire -- submission\nfailure from tls_server_hello_x509() and a successful\ntls_handshake_cancel() -- and at the tail of\nsvc_tcp_handshake_done() after complete_all().\n\n[cel: rewrote commit message to describe the actual change](CVE-2026-72222)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nbatman-adv: retrieve ethhdr after potential skb realloc on RX\n\npskb_may_pull() in batadv_interface_rx() could reallocate the buffer behind\nthe skb. Variables which were pointing to the old buffer need to be\nreassigned to avoid an use-after-free.\n\nThis was done correctly for the VLAN header but missed for the ethernet\nheader which is later used for the TT and AP isolation handling.(CVE-2026-72235)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nKVM: Move kvm_io_bus_get_dev() locking responsibilities to callers\n\nkvm_io_bus_get_dev() returns a device that is only matched by the\naddress, and nothing else. This can cause a lifetime issue if\nthe matched device is not the expected type, as by the time\nthe caller can introspect the object, it might be gone (the srcu\nlock having been dropped).\n\nGiven that there is only a single user of this helper, the simplest\noption is to move the locking responsibility to the caller, which\ncan keep the srcu lock held for as long as it wants.\n\nNote that this aligns with other kvm_io_bus*() helpers, which\nalready require the srcu lock to be held by the callers.(CVE-2026-72282)\n\nIn the Linux kernel, the following vulnerability has been resolved: smb: client: fix overflow in passthrough ioctl bounds check. smb2_ioctl_query_info() validates the PASSTHRU_FSCTL response payload before copying it to userspace. The payload offset and length both come from 32-bit fields. The bounds check currently adds OutputOffset and qi.input_buffer_length directly, so the addition can wrap in 32-bit arithmetic before the result is compared against the response buffer length. A malicious server can use a large OutputOffset and a small OutputCount to make the wrapped sum pass the bounds check. The later copy_to_user() then reads from io_rsp + OutputOffset, outside the response buffer, leading to an out-of-bounds read.(CVE-2026-72310)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ndm era: fix NULL pointer dereference in metadata_open()\n\nmetadata_open() returns NULL when kzalloc_obj() fails, but the\ncaller era_ctr() only checks IS_ERR(md).  Since IS_ERR(NULL)\nreturns false, the NULL pointer is treated as a valid result\nand later assigned to era->md, leading to a NULL pointer\ndereference when the metadata is accessed.\n\nFix this by returning ERR_PTR(-ENOMEM) on allocation failure,\nconsistent with dm-cache-metadata.c, dm-thin-metadata.c, and\ndm-clone-metadata.c which all use ERR_PTR(-ENOMEM) for the\nsame pattern.(CVE-2026-72316)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nSUNRPC: pin upper rpc_clnt across the TLS connect_worker\n\nThe TLS connect path has a use-after-free: nothing pins the\nupper rpc_clnt across the delayed connect_worker. xs_connect()\nstores task->tk_client in sock_xprt::clnt as a raw pointer\nand queues the worker; for TLS-secured transports that worker\nis xs_tcp_tls_setup_socket(), which reads several fields out\nof the saved pointer (cl_timeout, cl_program, cl_prog,\ncl_vers, cl_cred, cl_stats) to construct the args for the\ninner handshake rpc_clnt.\n\nThe xprt does not reference the rpc_clnt; the rpc_clnt\nreferences the xprt. xs_destroy() does cancel the\nconnect_worker, but it runs only when the xprt's refcount\ndrops to zero, which cannot happen until the rpc_clnt\nreleases its cl_xprt reference in rpc_free_client_work().\nWhen a TLS handshake fails fatally (for example, an mTLS\nmount whose client cert does not match the server), the\nconnecting task is woken with -EACCES and exits, the mount\ncaller invokes rpc_shutdown_client(), and the upper rpc_clnt\nis freed before the queued connect_worker fires.\nxs_tcp_tls_setup_socket() then dereferences the freed clnt,\nproducing the refcount_t underflow Michael Nemanov reported.\n\nTake a reference on the upper rpc_clnt in xs_connect() for\nTLS transports via a new rpc_hold_client() helper, and drop\nit in the connect_worker's exit path with rpc_release_client().\nThe xprt_lock_connect() / xprt_unlock_connect() pairing\nalready serialises xs_connect() with xs_tcp_tls_setup_socket(),\nso the take and release are balanced one-for-one.\n\nThe non-TLS connect worker (xs_tcp_setup_socket) never reads\nsock_xprt::clnt, so leave that path alone and avoid the\nclnt-holds-xprt-holds-clnt cycle that would otherwise prevent\nxprt destruction.(CVE-2026-72317)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ncifs: validate DFS referral string offsets\n\nparse_dfs_referrals() validates that the response header and referral\narray fit in the received buffer, but each referral also contains string\noffsets supplied by the server.\n\nThose offsets are used to compute the DfsPath and NetworkAddress string\npointers without checking whether they still point inside the response\nbuffer. A malformed referral can therefore make the computed pointer\nexceed the end of the buffer. The resulting negative max_len is then\npassed to cifs_strndup_from_utf16(), and the non-Unicode path forwards it\nto kstrndup() as a size_t, allowing strnlen() to read out of bounds.\n\nValidate each string offset before deriving the string pointer.(CVE-2026-72318)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nipvs: ensure inner headers in ICMP errors are in headroom\n\nSashiko points out that after stripping the outer headers\nwith pskb_pull() we should ensure the inner IP headers\nin ICMP errors from tunnels are present in the skb headroom\nfor functions like ipv4_update_pmtu(), icmp_send() and\nIP_VS_DBG().\n\nAlso, add more checks for the length of the inner headers.(CVE-2026-72319)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet/tls: Consume empty data records in tls_sw_read_sock()\n\nA peer may send a zero-length TLS application_data record; TLS 1.3\nexplicitly permits these as a traffic-analysis countermeasure (RFC\n8446, Section 5.1). After decryption such a record has full_len ==\n0. tls_sw_read_sock() hands it to the read_actor, which has no\npayload to consume and returns zero. The loop treats a zero return\nas backpressure (used <= 0), requeues the skb at the head of\nrx_list, and stops. rx_list is serviced head-first on the next\ncall, so the empty record is dequeued, fails the same way, and is\nrequeued again; every later record on the connection is blocked\nbehind it.\n\ntls_sw_recvmsg() does not stall on this: a zero-length data record\ncopies nothing and falls through to consume_skb(). Mirror that in\nthe read_sock() path by recognizing an empty data record before\nthe actor runs, consuming it, and continuing.(CVE-2026-72330)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nqede: fix off-by-one in BD ring consumption on build_skb failure\n\nqede_rx_build_skb() and qede_tpa_rx_build_skb() do not check for a\nNULL return from qede_build_skb(). When it returns NULL under memory\npressure, the functions still consume a BD from the ring before\nreturning NULL. The callers then recycle additional BDs, resulting in\none extra BD being consumed (off-by-one). This desynchronizes the BD\nring, which can corrupt DMA page reference counts and lead to SLUB\nfreelist corruption.\n\nCommit 4e910dbe3650 ("qede: confirm skb is allocated before using")\nadded a NULL check inside qede_build_skb() to prevent a NULL pointer\ndereference, but did not address the missing NULL checks in the\ncallers, making this off-by-one reachable.\n\nFix this by adding NULL checks for the return value of\nqede_build_skb() in both qede_rx_build_skb() and\nqede_tpa_rx_build_skb(), returning NULL immediately before any BD ring\nmanipulation.(CVE-2026-72339)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet/mlx5e: Fix HV VHCA stats agent registration race\n\nmlx5e_hv_vhca_stats_create() registers the stats agent through\nmlx5_hv_vhca_agent_create(). The helper publishes the agent in\nhv_vhca->agents[type] under agents_lock and immediately schedules an\nasynchronous control invalidation on the HV VHCA workqueue before\nreturning to mlx5e.\n\nThe asynchronous invalidation invokes the control agent's invalidate\ncallback, which reads the hypervisor control block and forwards the\ncommand to mlx5e_hv_vhca_stats_control(). That callback may either:\n\n  - call cancel_delayed_work_sync(&priv->stats_agent.work), or\n  - call queue_delayed_work(priv->wq, &sagent->work, sagent->delay).\n\nHowever, the delayed_work and priv->stats_agent.agent are only\ninitialized after mlx5_hv_vhca_agent_create() returns to mlx5e:\n\n    agent = mlx5_hv_vhca_agent_create(...);   /* publish + invalidate */\n    ...\n    priv->stats_agent.agent = agent;          /* too late */\n    INIT_DELAYED_WORK(&priv->stats_agent.work, ...); /* too late */\n\nIf the asynchronous control path runs before the two assignments\nabove, it can:\n\n  - Operate on an uninitialized delayed_work whose timer.function is\n    NULL. queue_delayed_work() calls add_timer() unconditionally, so\n    when the timer expires the timer softirq invokes a NULL function\n    pointer.\n  - Re-initialize the timer later through INIT_DELAYED_WORK() while\n    the timer is already enqueued in the timer wheel, corrupting the\n    hlist (entry.pprev cleared while the previous bucket node still\n    points at this entry).\n  - When the worker eventually runs, mlx5e_hv_vhca_stats_work() reads\n    sagent->agent (NULL) and dereferences it inside\n    mlx5_hv_vhca_agent_write().\n\nFix this by:\n\n  - Initializing priv->stats_agent.work before invoking\n    mlx5_hv_vhca_agent_create(), so the work is always in a valid\n    state when the control callback observes it.\n  - Adding a struct mlx5_hv_vhca_agent **ctx_update out-parameter\n    to mlx5_hv_vhca_agent_create(). The helper writes the agent\n    pointer to *ctx_update before publishing into hv_vhca->agents[]\n    and triggering the agents_update flow, so any callback\n    subsequently invoked from that flow already sees a valid\n    priv->stats_agent.agent. This avoids having the control\n    callback participate in agent initialization.\n\nWhile at it, access priv->stats_agent.agent with\nREAD_ONCE()/WRITE_ONCE() for the cross-CPU access with the worker, and\nclear priv->stats_agent.buf on the agent_create() failure path.(CVE-2026-72342)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nbridge: stp: Fix a potential use-after-free when deleting a bridge\n\nThe three STP timers are not supposed to be armed while the bridge is\nadministratively down. They are synchronously deactivated when the\nbridge is put administratively down and the various call sites check for\n'IFF_UP' before arming them.\n\nThis check is missing from br_topology_change_detection() and it is\npossible to engineer a situation in which the topology change timer is\narmed while the bridge is administratively down, resulting in a\nuse-after-free [1] when the bridge is deleted.\n\nFix by adding the missing check and for good measures synchronously\nshutdown the three timers when the bridge is deleted.\n\n[1]\nODEBUG: free active (active state 0) object: ffff88811662b9b0 object type: timer_list hint: br_topology_change_timer_expired (net/bridge/br_stp_timer.c:120)\nWARNING: lib/debugobjects.c:629 at debug_print_object+0x1bc/0x450, CPU#9: ip/359(CVE-2026-72389)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nseg6: validate SRH length before reading fixed fields\n\nseg6_validate_srh() reads fixed SRH fields such as srh->type and\nsrh->hdrlen before checking that the supplied length covers the fixed\nstruct ipv6_sr_hdr fields.\n\nThe BPF SEG6 encap path reaches this with a BPF program-supplied pointer\nand length: bpf_lwt_push_encap() and the SEG6 local BPF END_B6 and\nEND_B6_ENCAP actions call bpf_push_seg6_encap(), which forwards the\nlength to seg6_validate_srh() with no minimum-size guard.  A 2-byte SEG6\nencap header can therefore make the validator read srh->type at offset 2\nbeyond the caller-supplied buffer.\n\nReject lengths shorter than the fixed SRH at the top of\nseg6_validate_srh(), before any field is read.  This fixes the BPF helper\npath and keeps the common validator robust.(CVE-2026-72400)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nice: fix FDIR CTRL VSI resource leak in ice_reset_all_vfs()\n\nResetting all VFs causes resource leak on VFs with FDIR filters\nenabled as CTRL VSIs are only invalidated and not freed. Fix by using\nice_vf_ctrl_vsi_release() instead of ice_vf_ctrl_invalidate_vsi() which\naligns behavior with the ice_reset_vf() function.\n\nReproduction:\n  echo 1 > /sys/class/net/$pf/device/sriov_numvfs\n  ethtool -N $vf flow-type ether proto 0x9000 action 0\n  echo 1 > /sys/class/net/$pf/device/reset(CVE-2026-72425)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nxfrm: validate selector family and prefixlen during match\n\nsyzbot reported a shift-out-of-bounds in xfrm_selector_match()\ndue to AF_UNSPEC selector with large prefixlen (e.g. 128) matched\nagainst IPv4 flow (when XFRM_STATE_AF_UNSPEC is set).\n\nFix this by:\n\n- Rejecting mismatched families in xfrm_selector_match.\n- Returning false in addr4_match if prefixlen > 32.\n- Returning false in addr_match if prefixlen > 128 (prevents overflow).(CVE-2026-72450)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\napparmor: aa_label_alloc use aa_label_free on alloc failure\n\naa_label_alloc() allocates a secid before allocating or taking the label\nproxy. If the later proxy step fails, the error path only freed the label\nmemory, leaking any resources initialized by aa_label_init().\n\nUse aa_label_free() on the failure path so partially initialized labels\nrelease their secid and other label resources before the backing memory is\nfreed.(CVE-2026-72459)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\napparmor: check label build before no_new_privs test\n\naa_change_profile() builds a replacement label with\nfn_label_build_in_scope() before the no_new_privs subset check. The build\nhelper can fail and return NULL or an ERR_PTR, but the result was passed\nto aa_label_is_unconfined_subset() before the existing IS_ERR_OR_NULL()\ncheck.\n\nReuse the existing target-label build failure handling immediately after\nthe build. This preserves the current audit handling while preventing the\nsubset helper from dereferencing an invalid label.(CVE-2026-72460)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nxprtrdma: Repost Receive buffers for malformed replies\n\nrpcrdma_wc_receive() decrements the transport's Receive count for\nevery completion before it dispatches a successful Receive to\nrpcrdma_reply_handler(). The handler must post a replacement\nReceive WR before returning unless ownership of the rep has moved\nelsewhere, as on the backchannel path.\n\nCommit 2ae50ad68cd7 ("xprtrdma: Close window between waking RPC\nsenders and posting Receives") moved the Receive refill out of\nrpcrdma_wc_receive(), where it had run ahead of every reply, into\nrpcrdma_reply_handler() so that the responder's credit grant could\nbe parsed before reposting. The bad-version and short-reply exits\nnever reach that refill: they recycle the rep and return without\ncalling rpcrdma_post_recvs().\n\nA remote peer can therefore drain the client's posted Receive\nqueue by sending a sustained stream of replies that are shorter\nthan the fixed transport header or that carry an unrecognized\nRPC/RDMA version. Each such reply consumes one posted Receive\nwithout replacing it. Once the queue empties, the peer's next\nSend finds no posted Receive and the transport stalls until\nreconnect.\n\nRoute both malformed-reply exits through the shared repost tail\nafter recycling the rep, refilling against buf->rb_credits, the\nmost recent accepted credit grant. Neither exit updates the\ncongestion window, so RPCs admitted under the previous grant\nremain in flight awaiting replies. A smaller refill target would\nlet a stream of malformed replies ratchet the posted Receive count\ndown to the batch floor while the congestion window still admits\nrb_credits RPCs; a burst of valid replies to those RPCs could then\noverrun the posted Receives, and because the client connects with\nrnr_retry_count of zero, a single RNR NAK terminates the\nconnection. Refilling against rb_credits also restores the target\nthat applied to malformed replies before commit 2ae50ad68cd7\n("xprtrdma: Close window between waking RPC senders and posting\nReceives") when rpcrdma_post_recvs() computed it from rb_credits\ninternally. rb_credits is at least one from connection\nestablishment onward, so the repost path always keeps Receives\nposted.(CVE-2026-72464)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nxprtrdma: Fix bcall rep leak and unbounded peek\n\nrpcrdma_is_bcall() decodes a reply's first words to decide whether\nthe frame is a backchannel call. Two issues in that decode path\nlet a short or malformed reply leak the receive buffer and drain\nthe Receive queue.\n\nFirst, the speculative peek\n\n    p = xdr_inline_decode(xdr, 0);\n    /* five p++ reads follow */\n\nasks xdr_inline_decode() for zero bytes, which returns xdr->p\nwithout consulting xdr->end. The five subsequent __be32 reads can\nthen walk up to 20 bytes past the wire payload into stale regbuf\ncontents and misclassify the reply as a backchannel call.\n\nSecond, after the post-peek\n\n    p = xdr_inline_decode(xdr, 3 * sizeof(*p));\n    if (unlikely(!p))\n            return true;\n\nthe short-header arm returns true without calling\nrpcrdma_bc_receive_call(). The contract with the caller is that a\ntrue return transfers ownership of rep to the backchannel path:\n\n    rpcrdma_reply_handler()\n      if (rpcrdma_is_bcall(r_xprt, rep))\n              return;        /* bare return, skips out_post */\n      ...\n    out_post:\n      rpcrdma_post_recvs(r_xprt, credits + ...);\n\nBecause rpcrdma_bc_receive_call() never ran, no one took rep, but\nrpcrdma_reply_handler still bare-returns past rpcrdma_rep_put()\nand rpcrdma_post_recvs(). The rep, with its persistently\nDMA-mapped receive buffer, is orphaned on rb_all_reps and freed\nonly at transport teardown. This completion reposts nothing, so\nits slot is reclaimed only when a later forward-channel reply\nreaches out_post and rpcrdma_post_recvs() allocates a fresh rep to\nbackfill; absent that traffic the Receive queue drains and the\npeer's Sends draw RNR NAKs.\n\nFix by consulting xdr->end after the zero-length peek so the five\n__be32 reads cannot run unless 20 bytes of wire payload remain. A\nbyte-precise comparison against xdr->end is required because a\nnon-4-aligned receive rounds the stream's word count up past the\ntrue payload. Also return false from the short-header arm so the\nreply falls through the normal out_norqst cleanup chain\n(rpcrdma_rep_put() plus rpcrdma_post_recvs()).(CVE-2026-72466)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nxprtrdma: Decouple req recycling from RPC completion\n\nrl_kref formerly served two distinct lifetimes through a single\nrefcount: it gated when a Reply could wake its RPC task, and it\ngated when an rpcrdma_req could return to its free pool. The\nmarshal path took the Send-side reference only when SGEs needed\nDMA-unmap (sc_unmap_count > 0), which made a Send carrying only\npre-registered buffers an exception: the Reply handler dropped\nrl_kref from 1 to 0 and freed the req while the HCA might still\nbe DMA-reading from its send buffer.\n\nGive rl_kref a narrower job. The RPC layer takes one reference\nwhen slot allocation hands a req out. rpcrdma_prepare_send_sges()\ntakes a Send-side reference unconditionally after WR preparation\nsucceeds. xprt_rdma_free_slot() and xprt_rdma_bc_free_rqst() drop\nthe RPC-layer reference; rpcrdma_sendctx_unmap() drops the\nSend-side reference. The req returns to its free pool only after\nboth owners have signed off.\n\nThe existing kref_init(&req->rl_kref) call in\nrpcrdma_prepare_send_sges() is removed. Initialization moves to\nthe slot-allocation paths (xprt_rdma_alloc_slot and\nrpcrdma_bc_rqst_get), and the release callback re-arms rl_kref\nbefore the req returns to a free pool. A re-init in the marshal\npath would discard the RPC-layer reference that already exists\non entry.\n\nThree invariants follow:\n\n  - Any rpcrdma_req held by an rpc_rqst has rl_kref >= 1.\n    xprt_rdma_alloc_slot(), rpcrdma_bc_rqst_get(), and the\n    backlog-wake branch in xprt_rdma_alloc_slot() each kref_init\n    rl_kref before publishing the req. Without this invariant,\n    an RPC task that aborts between slot allocation and marshal\n    (gss_refresh failure or signal during call_connect, for\n    example) would drive xprt_release() ->\n    xprt_rdma_free_slot() -> kref_put against a refcount of\n    zero, saturating refcount_t and stranding the slot.\n\n  - The Send-side reference is taken only after WR prep\n    succeeds. A mapping failure in rpcrdma_prepare_send_sges()\n    runs rpcrdma_sendctx_cancel(), which DMA-unmaps the sendctx\n    and clears sc_req without touching rl_kref. The sendctx\n    ring walks in rpcrdma_sendctx_put_locked() and\n    rpcrdma_sendctxs_destroy() skip entries with sc_req == NULL,\n    so a burst of -EIO marshal failures cannot hold reqs off\n    rb_send_bufs.\n\n  - The release callback re-arms rl_kref so the next consumer\n    enters with the invariant satisfied.\n\nReplies now complete the RPC directly. rpcrdma_reply_handler()\ncalls rpcrdma_complete_rqst() in place of kref_put on the\nnon-LocalInv branch. The LocalInv branch already completes the\nRPC from frwr_unmap_async() and is unaffected.\n\nBecause Send-side references can now outlive RPC completion,\nconnection teardown drains sendctx entries whose unsignaled\nSends never had a later signaled completion to walk the ring.\nrpcrdma_sendctxs_destroy() walks the active range and runs\nrpcrdma_sendctx_unmap() on each entry with a non-NULL sc_req\nbefore the request buffers are reset, and is moved ahead of\nrpcrdma_reqs_reset() in rpcrdma_xprt_disconnect() so the reqs\nare still in their pre-reset state when the Send-side refs are\nreleased.\n\nThe drain creates a teardown-ordering hazard on the backchannel\npath. With the new lifetime, releasing a bc_prealloc req from\nrpcrdma_req_release() re-adds it to bc_pa_list. The disconnect\nin xprt_rdma_destroy() runs after xprt_destroy_backchannel() has\nalready emptied bc_pa_list, so the drained reqs would otherwise\nleak. xprt_rdma_destroy() now runs xprt_rdma_bc_destroy(xprt, 0)\na second time after the disconnect to reclaim them.(CVE-2026-72473)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\npower: supply: core: fix supplied_from allocations\n\nIf dts property power-supplies has multiple values, then accessing to\npsy->supplied_from[i-1] in __power_supply_populate_supplied_from will\noverrun supplied_from array.(CVE-2026-74271)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ntipc: require net admin for TIPCv2 netlink mutators\n\nTIPCv2 registers mutating generic-netlink operations without admin\npermission flags. Generic netlink only checks CAP_NET_ADMIN when an\noperation sets GENL_ADMIN_PERM or GENL_UNS_ADMIN_PERM, so a local\nunprivileged process can currently change TIPC state through commands\nsuch as TIPC_NL_NET_SET, TIPC_NL_KEY_SET, TIPC_NL_KEY_FLUSH, and\nbearer enable/disable.\n\nThe legacy TIPC netlink API already checks netlink_net_capable(...,\nCAP_NET_ADMIN) for administrative commands. Give the TIPCv2 mutators\nthe equivalent generic-netlink gate. Use GENL_UNS_ADMIN_PERM, which\nmaps to the same namespace-aware CAP_NET_ADMIN check that\nnetlink_net_capable() performs, so the behaviour matches the legacy\npath and keeps working for CAP_NET_ADMIN holders in a non-initial user\nnamespace (containers).\n\nA QEMU/KASAN repro run as uid/gid 65534 with zero effective\ncapabilities previously succeeded in changing the network id and node\nidentity, setting and flushing key material, and enabling/disabling a\nUDP bearer. With this patch applied the same operations fail with\n-EPERM.(CVE-2026-74283)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nsctp: validate embedded address parameter length\n\nsctp_verify_asconf() and sctp_verify_param() only validate ADD_IP, DEL_IP,\nand SET_PRIMARY parameters against a fixed minimum size of sizeof(struct\nsctp_addip_param) + sizeof(struct sctp_paramhdr). This ensures the outer\nparameter is large enough to contain an embedded address parameter header,\nbut does not verify that the embedded address parameter's declared length\nfits within the bounds of the outer parameter.\n\nLater, sctp_process_param() and sctp_process_asconf_param() extract the\nembedded address parameter and pass it to af->from_addr_param(), which uses\nthe address parameter length to parse the variable-length address payload.\nA malformed peer can therefore advertise an embedded address parameter\nlength that exceeds the remaining bytes in the enclosing parameter.\n\nValidate that addr_param->p.length does not exceed the space available\nafter the sctp_addip_param header before processing the embedded address\nparameter. Reject malformed parameters when the embedded address length\nextends beyond the enclosing parameter bounds.\n\nThis prevents out-of-bounds reads when parsing malformed parameters carried\nin INIT or ASCONF processing paths.(CVE-2026-74287)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nbpf: Tighten cgroup storage cookie checks for prog arrays\n\nThe fix in commit abad3d0bad72 ("bpf: Fix oob access in cgroup local\nstorage") is still incomplete. The prog-array compatibility check\ntreats a program with no cgroup storage as compatible with any stored\nstorage cookie. This allows a storage-less program to bridge a tail\ncall chain between an entry program and a storage-using callee even\nthough cgroup local storage at runtime still follows the caller's\ncontext, that is, A -> B(no storage) -> C(storage) path.\n\nRequiring exact cookie equality would break the legitimate case of a\nstorage-less leaf program being tail called from a storage-using one.\nInstead, only accept a zero storage cookie if the program cannot\nperform tail calls itself. This keeps A -> B(no storage) working\nwhile rejecting the A -> B(no storage) -> C(storage) bridge.(CVE-2026-74305)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nRDMA/rxe: Copy WQE to local buffer in non-SRQ receive path\n\nFor non-SRQ QPs, the responder reads WQE fields directly from the\nshared queue buffer mapped into userspace. This allows a malicious\nuser to modify fields like num_sge or sge entries while the kernel\nis processing the WQE, leading to out-of-bounds reads in\nrxe_resp_check_length() and copy_data().\n\nIntroduce get_recv_wqe() that validates num_sge and copies the WQE\nto a kernel-local buffer before processing, matching the approach\nalready used for SRQ WQEs in get_srq_wqe(). The srq_wqe buffer is\nreused since SRQ and non-SRQ paths are mutually exclusive per QP.(CVE-2026-74377)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nRDMA/rxe: Fix TOCTOU heap overflow in get_srq_wqe\n\nget_srq_wqe() reads wqe->dma.num_sge from the shared receive queue\nbuffer, which is mapped into userspace. It validates num_sge against\nmax_sge, but then re-reads the same field to calculate the memcpy\nsize. A concurrent userspace thread can modify num_sge between\nvalidation and use, causing a heap buffer overflow when copying the\nWQE into qp->resp.srq_wqe.\n\nRead num_sge into a local variable and use it for both the bounds\ncheck and the size calculation.(CVE-2026-74378)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nRDMA/srpt: fix integer overflow in immediate data length check\n\nimm_buf->len is a user-controlled uint32_t received from the network.\nAdding it to imm_data_offset without overflow checking allows a\nmalicious initiator to send len=0xFFFFFFFF, causing req_size to wrap\naround to a small value, bypassing the bounds check, and subsequently\npassing a ~4GB length to sg_init_one().\n\nUse check_add_overflow() to detect wrapping before the comparison.(CVE-2026-74394)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nIB/mlx5: Fix transport-domain rollback and initialize lb mutex earlier\n\nmlx5_ib_alloc_transport_domain() allocates a transport domain and then\nmay fail in mlx5_ib_enable_lb(). In that case, the allocated TD is leaked.\n\nFix this by deallocating the TD when mlx5_ib_enable_lb() returns an\nerror. Also return 0 explicitly in the no-loopback-capability success\nbranch, and move dev->lb.mutex initialization to mlx5_ib_stage_init_init().(CVE-2026-74397)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nipv6: addrconf: bail out of dad_failure when state is no longer POSTDAD\n\naddrconf_dad_failure() transitions ifp->state from DAD to POSTDAD\nvia addrconf_dad_end(), which drops ifp->lock on return.  The lock\nis re-acquired after net_info_ratelimited().  A concurrent\nipv6_del_addr() can take the lock in that window, set ifp->state\nto DEAD and run list_del_rcu(&ifp->if_list).\n\naddrconf_dad_failure() then overwrites DEAD with ERRDAD at errdad:\nand schedules a new dad_work.  The work calls ipv6_del_addr()\nagain, hitting the already-poisoned list entry:\n\n  general protection fault: 0000 [#1] SMP NOPTI\n  CPU: 4 PID: 217 Comm: kworker/4:1\n  Workqueue: ipv6_addrconf addrconf_dad_work\n  RIP: 0010:ipv6_del_addr+0xe9/0x280\n  RAX: dead000000000122\n  Call Trace:\n   addrconf_dad_stop+0x113/0x140\n   addrconf_dad_work+0x28c/0x430\n   process_one_work+0x1eb/0x3b0\n   worker_thread+0x4d/0x400\n   kthread+0x104/0x140\n   ret_from_fork+0x35/0x40\n\nFold the addrconf_dad_end() logic into addrconf_dad_failure() under\na single ifp->lock critical section.  The STABLE_PRIVACY branch\ntemporarily drops ifp->lock around address regeneration, so at\nlock_errdad: verify the state is still POSTDAD before transitioning\nto ERRDAD; bail out otherwise to avoid overwriting a state set by\nanother path while the lock was released.(CVE-2026-74398)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nvxlan: Fix potential null-ptr-deref in vxlan_gro_prepare_receive().\n\nudp_tunnel_sock_release() could set sk->sk_user_data to NULL\nwhile vxlan_gro_prepare_receive() is running.\n\nLet's check if rcu_dereference_sk_user_data() is NULL after\nskb_gro_remcsum_init().(CVE-2026-74406)","modified":"2026-09-05T15:16:42.349276330Z","published":"2026-09-05T15:04:07Z","upstream":["CVE-2025-37979","CVE-2025-38736","CVE-2026-43078","CVE-2026-46028","CVE-2026-63912","CVE-2026-68476","CVE-2026-68477","CVE-2026-72021","CVE-2026-72049","CVE-2026-72052","CVE-2026-72053","CVE-2026-72054","CVE-2026-72061","CVE-2026-72072","CVE-2026-72129","CVE-2026-72135","CVE-2026-72136","CVE-2026-72157","CVE-2026-72172","CVE-2026-72217","CVE-2026-72221","CVE-2026-72222","CVE-2026-72235","CVE-2026-72282","CVE-2026-72310","CVE-2026-72316","CVE-2026-72317","CVE-2026-72318","CVE-2026-72319","CVE-2026-72330","CVE-2026-72339","CVE-2026-72342","CVE-2026-72389","CVE-2026-72400","CVE-2026-72425","CVE-2026-72450","CVE-2026-72459","CVE-2026-72460","CVE-2026-72464","CVE-2026-72466","CVE-2026-72473","CVE-2026-74271","CVE-2026-74283","CVE-2026-74287","CVE-2026-74305","CVE-2026-74377","CVE-2026-74378","CVE-2026-74394","CVE-2026-74397","CVE-2026-74398","CVE-2026-74406"],"database_specific":{"severity":"Critical"},"references":[{"type":"ADVISORY","url":"https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2026-3703"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-37979"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-38736"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-43078"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-46028"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-63912"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-68476"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-68477"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-72021"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-72049"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-72052"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-72053"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-72054"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-72061"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-72072"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-72129"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-72135"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-72136"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-72157"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-72172"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-72217"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-72221"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-72222"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-72235"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-72282"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-72310"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-72316"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-72317"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-72318"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-72319"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-72330"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-72339"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-72342"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-72389"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-72400"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-72425"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-72450"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-72459"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-72460"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-72464"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-72466"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-72473"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-74271"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-74283"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-74287"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-74305"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-74377"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-74378"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-74394"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-74397"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-74398"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-74406"}],"affected":[{"package":{"name":"kernel","ecosystem":"openEuler:24.03-LTS-SP1","purl":"pkg:rpm/openEuler/kernel&distro=openEuler-24.03-LTS-SP1"},"ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"6.6.0-145.1.24.161.oe2403sp1"}]}],"ecosystem_specific":{"src":["kernel-6.6.0-145.1.24.161.oe2403sp1.src.rpm"],"x86_64":["bpftool-6.6.0-145.1.24.161.oe2403sp1.x86_64.rpm","bpftool-debuginfo-6.6.0-145.1.24.161.oe2403sp1.x86_64.rpm","kernel-6.6.0-145.1.24.161.oe2403sp1.x86_64.rpm","kernel-debuginfo-6.6.0-145.1.24.161.oe2403sp1.x86_64.rpm","kernel-debugsource-6.6.0-145.1.24.161.oe2403sp1.x86_64.rpm","kernel-devel-6.6.0-145.1.24.161.oe2403sp1.x86_64.rpm","kernel-headers-6.6.0-145.1.24.161.oe2403sp1.x86_64.rpm","kernel-source-6.6.0-145.1.24.161.oe2403sp1.x86_64.rpm","kernel-tools-6.6.0-145.1.24.161.oe2403sp1.x86_64.rpm","kernel-tools-debuginfo-6.6.0-145.1.24.161.oe2403sp1.x86_64.rpm","kernel-tools-devel-6.6.0-145.1.24.161.oe2403sp1.x86_64.rpm","perf-6.6.0-145.1.24.161.oe2403sp1.x86_64.rpm","perf-debuginfo-6.6.0-145.1.24.161.oe2403sp1.x86_64.rpm","python3-perf-6.6.0-145.1.24.161.oe2403sp1.x86_64.rpm","python3-perf-debuginfo-6.6.0-145.1.24.161.oe2403sp1.x86_64.rpm"],"aarch64":["bpftool-6.6.0-145.1.24.161.oe2403sp1.aarch64.rpm","bpftool-debuginfo-6.6.0-145.1.24.161.oe2403sp1.aarch64.rpm","kernel-6.6.0-145.1.24.161.oe2403sp1.aarch64.rpm","kernel-debuginfo-6.6.0-145.1.24.161.oe2403sp1.aarch64.rpm","kernel-debugsource-6.6.0-145.1.24.161.oe2403sp1.aarch64.rpm","kernel-devel-6.6.0-145.1.24.161.oe2403sp1.aarch64.rpm","kernel-headers-6.6.0-145.1.24.161.oe2403sp1.aarch64.rpm","kernel-source-6.6.0-145.1.24.161.oe2403sp1.aarch64.rpm","kernel-tools-6.6.0-145.1.24.161.oe2403sp1.aarch64.rpm","kernel-tools-debuginfo-6.6.0-145.1.24.161.oe2403sp1.aarch64.rpm","kernel-tools-devel-6.6.0-145.1.24.161.oe2403sp1.aarch64.rpm","perf-6.6.0-145.1.24.161.oe2403sp1.aarch64.rpm","perf-debuginfo-6.6.0-145.1.24.161.oe2403sp1.aarch64.rpm","python3-perf-6.6.0-145.1.24.161.oe2403sp1.aarch64.rpm","python3-perf-debuginfo-6.6.0-145.1.24.161.oe2403sp1.aarch64.rpm"]},"database_specific":{"source":"https://repo.openeuler.org/security/data/osv/OESA-2026-3703.json"}}],"schema_version":"1.9.0","severity":[{"type":"CVSS_V3","score":"CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H"}]}