cves
publicly-credited vulnerability disclosures across kernel and userspace targets. each row links to the nvd record and (where available) the advisory and original write-up.
- CVE-2026-68127 9.8 CRITICAL
ila: reload IPv6 header after pskb_may_pull in checksum adjust
Linux kernel - ILA (net/ipv6/ila) [CWE-416]
ila_csum_adjust_transport() cached ip6h = ipv6_hdr(skb) before calling pskb_may_pull(). On a non-linear skb whose transport header sits in a page fragment, pskb_may_pull() can call __pskb_pull_tail()/pskb_expand_head() and free the old skb head, leaving the cached pointer dangling; the following get_csum_diff(ip6h, p) then reads freed memory. ila_update_ipv6_locator() uses ip6h (and the address derived from it) again after the checksum-adjust call and additionally writes the new locator through that stale pointer, so the defect is a write as well as a read. The fix reloads the header after every pull.
- CVE-2026-68302 9.8 CRITICAL
amt: re-read skb header pointers after every pull
Linux kernel - AMT tunnel driver (drivers/net/amt.c) [CWE-416]
Several AMT receive and transmit paths cached a pointer into the skb head (ip_hdr(), ipv6_hdr(), eth_hdr() or the AMT message header) and then called a helper that can reallocate that head before the cached pointer was used again. pskb_may_pull(), ip_mc_may_pull(), ipv6_mc_may_pull(), iptunnel_pull_header(), ip_mc_check_igmp() and ipv6_mc_check_mld() can all free the old head and move the data, so a pointer taken before the call dangles afterwards and the later access is a use-after-free. The fix re-reads the header pointers after every such call.
- CVE-2026-64268 9.8 CRITICAL
RDMA/siw: bound Read Response placement to the RREAD length
Linux kernel - RDMA/siw (drivers/infiniband/sw/siw)
siw_proc_rresp() places each inbound Read Response DDP segment at the sink SGE and accumulates the running offset, but never checks that total against the sink buffer length on continuation segments: the sink is resolved and validated only on the first fragment and the cumulative length is compared to the requested bytes only on the final segment. A connected siw peer that answers an outstanding RREAD with Read Response segments that keep the DDP Last flag clear, carrying more payload than requested, drives the placement offset past the validated sink buffer, producing an out-of-bounds write. siw runs iWARP over ordinary routable TCP, so the peer is the remote end of an established RDMA connection and needs no local privilege.
Second receive-path length fix in siw_qp_rx.c; companion to the MPA FPDU length-underflow guard, which does not cover the accumulated-placement case.
- CVE-2026-64439 9.8 CRITICAL
crypto: krb5 - filter out async aead implementations at alloc
Linux kernel - crypto/krb5 (crypto/krb5)
The krb5 AEAD helpers set a NULL completion callback and treat any negative return from crypto_aead_encrypt()/decrypt() as terminal, falling through to kfree_sensitive() on the request buffer. When the configured enctype resolves to an async AEAD instance the call returns -EINPROGRESS, so the buffer is freed while the backend worker still holds a pointer to it and dereferences the freed slab on completion (KASAN slab-use-after-free). The path is reachable via rxrpc, AFS cm_security and Ceph on systems that have an async AEAD provider bound to the krb5 enctype name. The fix filters async instances out at allocation time.
- CVE-2026-64459 9.8 CRITICAL
tcp: restore RCU grace period in tcp_ao_destroy_sock
Linux kernel - TCP-AO (net/ipv4)
Commit 51e547e8c89c removed the call_rcu() grace period from tcp_ao_destroy_sock() on the assumption that the info/keys are no longer discoverable at destroy time. That does not hold for the tcp_connect() call site: there the socket is in TCP_SYN_SENT and has already been inserted into the ehash, so a softirq running tcp_v4_rcv() on another CPU can load tp->ao_info via RCU and walk ao->head while the destroying CPU synchronously frees it, a use-after-free in softirq context. An unprivileged user in a user plus network namespace can drive it by installing TCP-MD5 and TCP-AO keys, spraying forged TCP-AO segments toward the eventual four-tuple, and calling connect(). The fix restores the grace period by freeing tcp_ao_info through call_rcu().
Reported via security@kernel.org and reviewed merge-ready by Dmitry Safonov and Eric Dumazet; reproduced from an unprivileged user+net namespace.
- CVE-2026-63808 9.8 CRITICAL
exfat: fix potential use-after-free in exfat_find_dir_entry()
Linux kernel - exfat filesystem (fs/exfat)
In exfat_find_dir_entry(), the buffer_head obtained from exfat_get_dentry() is released with brelse(bh) before the fall-through TYPE_EXTEND branch reads the directory entry through ep (which points into bh->b_data): brelse(bh); if (entry_type == TYPE_EXTEND) { ... len = exfat_extract_uni_name(ep, entry_uniname); ... } After brelse() drops our reference, nothing guarantees that the underlying page backing bh->b_data remains valid for the subsequent exfat_extract_uni_name() read.
- CVE-2026-63887 9.8 CRITICAL
scsi: target: iscsi: bound iscsi_encode_text_output() appends to the login response buffer
Linux kernel - SCSI target / iSCSI (drivers/target/iscsi)
iscsi_encode_text_output() concatenates key=value records into login->rsp_buf, an 8192-byte buffer, using sprintf() at three call sites with no check against the remaining capacity. The 8 KiB ceiling bounds the input Login PDU, but a single PDU can carry up to 2048 minimal four-byte key pairs, each unknown key expanding to a 16-byte NotUnderstood record, so 2048 * 16 = 32 KiB of output is written into the 8 KiB buffer, a roughly 24 KiB heap overrun in the kmalloc-8k slab. The overflow is reachable during login, before authentication completes. The fix adds a bounded snprintf() encoder that checks remaining space per record and fails the login on overflow.
- CVE-2026-63888 9.8 CRITICAL
scsi: target: iscsi: fix CRC overread and double-free in iscsit_handle_text_cmd()
Linux kernel - SCSI target / iSCSI (drivers/target/iscsi)
Two defects in the iSCSI target Text-phase handler. First, when DataDigest is negotiated the CRC is computed over an rx_size that was already incremented by the 4-byte digest length, so iscsit_crc_buf() reads four bytes past the text_in allocation (KASAN slab-out-of-bounds in crc32c on every Text PDU with DataDigest=CRC32C). Second, on a DataDigest mismatch with ErrorRecoveryLevel greater than zero the handler frees text_in but leaves cmd->text_in_ptr pointing at the freed buffer; the next Text Request on the same ITT, or session teardown, frees it a second time. On kernels built with CONFIG_SLAB_FREELIST_HARDENED (the distro default) the double-free is a remote kernel BUG(); otherwise it corrupts the slab freelist.
- CVE-2026-64102 9.8 CRITICAL
RDMA/siw: Reject MPA FPDU length underflow before signed receive math
Linux kernel - infiniband driver (drivers/infiniband)
A malicious connected siw peer can send an iWARP FPDU whose MPA length field (c_hdr->mpa_len, 16 bit big-endian, peer-controlled) is smaller than the fixed DDP/RDMAP header for the announced opcode. Soft-iWARP parses the full header in siw_get_hdr() based on iwarp_pktinfo[opcode] .hdr_len, but never compares mpa_len against that header length.
- CVE-2026-64113 9.8 CRITICAL
ixgbevf: fix use-after-free in VEPA multicast source pruning
Linux kernel - net driver (drivers/net)
ixgbevf_clean_rx_irq() prunes frames whose source MAC matches the VF's own address (VEPA multicast workaround) by freeing the skb and continuing to the next descriptor: dev_kfree_skb_irq(skb); continue; The skb pointer is declared outside the while loop and persists across iterations.
-
rxrpc: Fix the ACK parser to extract the SACK table for parsing
Linux kernel - rxrpc (net/rxrpc) [NVD-CWE-noinfo]
Fix modification of the received skbuff in rxrpc_input_soft_acks() and a potential incorrect access of the buffer in a fragmented UDP packet (the packet would probably have to be deliberately pre-generated as fragmented) when AF_RXRPC tries to extract the contents of the SACK table by copying out the contents of the SACK table into a buffer before attempting to parse AF_RXRPC assumes that it can just call skb_condense() and then validly access the SACK table from skb->data and that it will be a flat buffer - but skb_condense() can silently fail to do anything under some circumstances.
Reported the bug and submitted the original fix (lore link above). Maintainer David Howells reworked the fix around the skb_condense() silent-failure root cause and committed it under his own authorship, crediting the report with Reported-by: Michael Bommarito.
- CVE-2026-53176 9.8 CRITICAL
IB/isert: Reject login PDUs shorter than ISER_HEADERS_LEN
Linux kernel - RDMA/iSER (drivers/infiniband/ulp/isert) [CWE-191]
In drivers/infiniband/ulp/isert/ib_isert.c, isert_login_recv_done() computes the login request payload length as wc->byte_len minus ISER_HEADERS_LEN with no lower bound, and login_req_len is a signed int. A remote iSER initiator can post a login Send work request carrying fewer than ISER_HEADERS_LEN (76) bytes, so the subtraction underflows and login_req_len becomes negative. isert_rx_login_req() then reads that negative length back into a signed int, takes size = min(rx_buflen, MAX_KEY_VALUE_PAIRS), and because the min() is signed it keeps the negative value; the value is then passed as the memcpy() length and sign-extended to a multi-gigabyte size_t.
- CVE-2026-46195 9.8 CRITICAL
smb: client: validate dacloffset before building DACL pointers
Linux kernel - SMB client (fs/smb/client) [CWE-476, CWE-787]
The Linux kernel SMB client added a server-supplied DACL offset to the security-descriptor base before proving that a DACL header fit within the returned descriptor. On 32-bit builds a malicious server could supply an offset near the 4 GiB boundary, wrap the derived DACL pointer below the end of the ACL, and bypass the later pointer-based bounds checks in parse_sec_desc(), build_sec_desc(), and the chown path of id_mode_to_cifs_acl().
Continues the cifsacl bound-check hardening line (cf. CVE-2026-43350); adds the dacloffset wrap check for 32-bit builds.
- CVE-2026-53186 9.1 CRITICAL
RDMA/srp: bound SRP_RSP sense copy by the received length
Linux kernel - RDMA/SRP (drivers/infiniband/ulp/srp) [NVD-CWE-noinfo]
srp_process_rsp() copies sense data from rsp->data + resp_data_len, where resp_data_len is the full 32-bit value supplied by the SRP target and is never checked against the number of bytes actually received (wc->byte_len). The copy length is bounded to SCSI_SENSE_BUFFERSIZE, so at most 96 bytes are copied, but the source offset is not bounded. A malicious or compromised SRP target on the InfiniBand/RoCE fabric that the initiator has logged into can return an SRP_RSP with SRP_RSP_FLAG_SNSVALID set and a large resp_data_len.
- CVE-2026-53225 9.1 CRITICAL
sctp: fix uninit-value in __sctp_rcv_asconf_lookup()
Linux kernel - sctp networking (net/sctp) [CWE-908]
__sctp_rcv_asconf_lookup() in net/sctp/input.c only checks that the ASCONF chunk can hold the ADDIP header and a parameter header, then calls af->from_addr_param(), which reads the full address (16 bytes for IPv6) trusting the parameter's declared length.
- CVE-2026-64106 9 CRITICAL
KVM: arm64: vgic-its: Reject restored DTE with out-of-range num_eventid_bits
Linux kernel - arm64 arch (arch/arm64)
Userspace can restore an ITS Device Table Entry whose Size field encodes more EventID bits than the virtual ITS supports. The live MAPD path rejects that state, but vgic_its_restore_dte() accepts it and stores the out-of-range value in dev->num_eventid_bits. Reject restored DTEs with num_eventid_bits > VITS_TYPER_IDBITS before allocating the device.
-
Apache Traffic Server: memory-safety errors in MIME and HTTP header parsing
The Apache Software Foundation - Apache Traffic Server
Apache Traffic Server can write out of bounds or overflow integers while parsing MIME and HTTP headers. The hand-rolled digit-accumulation loops used to parse numeric header fields (mime_parse_int / mime_parse_uint / mime_parse_int64) accumulated without an overflow guard, so an oversized numeric value in a header such as Content-Length, Age or Max-Forwards produced signed-overflow undefined behaviour and an attacker-influenced parsed value. Because a proxy's interpretation of Content-Length is what downstream servers rely on, a divergent parse is a request-integrity problem, not merely a crash. The fix replaces the loops with std::from_chars and applies RFC-specific overflow policy per header: Content-Length is rejected as a parse error (RFC 9112 Section 6.3), Age is clamped to 2^31 (RFC 9111 Section 1.2.2), and Max-Forwards is clamped to INT32_MAX (RFC 9110 Section 7.6.2).
The ASF advisory credits three reporters: Michael Bommarito, Apache Community, and Omkhar Arasaratnam. Our report covered the MIME numeric-parse integer overflow; the published CVE covers memory-safety errors across MIME and header parsing, so it appears to consolidate more than one report.
- CVE-2026-63923 8.8 HIGH
octeontx2-af: validate body pcifunc in rvu_mbox_handler_rep_event_notify
Linux kernel - net driver (drivers/net)
rvu_mbox_handler_rep_event_notify() in drivers/net/ethernet/marvell/ octeontx2/af/rvu_rep.c queues a sender-controlled REP_EVENT_NOTIFY request body verbatim, and rvu_rep_up_notify() then forwards event->pcifunc (the nested body field, distinct from the AF-normalised header pcifunc) into rvu_get_pfvf(), rvu_get_pf() and the AF->PF mailbox device index without any bounds check.
- CVE-2026-31706 8.8 HIGH
ksmbd: validate num_aces and harden ACE walk in smb_inherit_dacl()
Linux kernel - ksmbd (fs/smb/server) [NVD-CWE-noinfo]
ksmbd's smb_inherit_dacl() trusted the on-disk num_aces from a parent directory's stored DACL. A crafted parent DACL could drive smb_inherit_dacl into an out-of-bounds ACE walk, with potential 32-bit allocation-size overflow on the inherited buffer construction.
- CVE-2026-31709 8.8 HIGH
smb: client: validate the whole DACL before rewriting it in cifsacl
Linux kernel - Linux SMB client (fs/smb/client) [NVD-CWE-noinfo, CWE-1288]
The Linux SMB client's cifsacl chmod/chown paths trusted server-supplied dacloffset and num_aces fields when rebuilding ACLs locally. A malicious server could provide a DACL whose advertised structure exceeded the actual buffer, causing replace_sids_and_copy_aces() and set_chmod_dacl() to walk past the validated end of the security descriptor.
Client-side counterpart of CVE-2025-21994. Sent 2026-04-16 v1, 2026-04-20 v2; in-thread follow-up KCIFS2_END_OF_DACL_DEBUG2 sent 2026-04-21.
-
ksmbd: require 3 sub-authorities before reading sub_auth[2]
Linux kernel - ksmbd (fs/smb/server) [NVD-CWE-noinfo]
The Linux kernel ksmbd parse_dacl() compared each ACE SID against sid_unix_NFS_mode using only min(num_subauth, 2) sub-authorities. A client SID with num_subauth = 2 could match the NFS-mode SID prefix; reading sub_auth[2] then crossed the end-of-ACL boundary by 4 bytes, applying out-of-band bytes as the file's POSIX mode.
Server-side sister of my client-side patch (sent 2026-04-20 to linux-cifs@). Same bug class in fs/smb/client/cifsacl.c was disclosed first; the direct client-side assignment is CVE-2026-43350.
- CVE-2026-53369 8.4 HIGH
udf: reject descriptors with oversized CRC length
Linux kernel - udf filesystem (fs/udf)
udf_read_tagged() skips CRC verification when descCRCLength + sizeof(struct tag) exceeds the block size. A crafted UDF image can set descCRCLength to an oversized value to bypass CRC validation entirely; the descriptor is then accepted based solely on the 8-bit tag checksum, which is trivially recomputable. Reject such descriptors instead of silently accepting them. A legitimate single-block descriptor should never have a CRC length that exceeds the block
- CVE-2026-31712 8.3 HIGH
ksmbd: require minimum ACE size in smb_check_perm_dacl()
Linux kernel - ksmbd (fs/smb/server) [CWE-787]
ksmbd's smb_check_perm_dacl() walked Access Control Entries after checking only that the remaining DACL buffer could hold the ACE header. A crafted ACE whose declared size was smaller than the minimum valid layout could pass the loop bounds and drive out-of-bounds reads of access_req and SID fields during a later CREATE permission check.
Patch 3 of the original KIPC_series, later tracked as the companion CVE to CVE-2026-31707 for the ipc_validate_msg() response-size validation patch.
- CVE-2026-46303 8.2 HIGH
isofs: validate Rock Ridge CE continuation extent against volume size
Linux kernel - isofs (fs/isofs) [CWE-401]
The isofs Rock Ridge handler read the CE (continuation entry) extent block number (rs->cont_extent) verbatim from on-disk directory metadata in rock_continue() and passed it to sb_bread() without checking that the block fell within the mounted ISO 9660 volume. Earlier fixes had validated the CE continuation offset and size and capped the CE chain length, but left the extent block number itself unchecked. With a crafted ISO mounted via desktop optical auto-mount (udisks2) or a CAP_SYS_ADMIN mount, the CE extent could point at an out-of-range block or at blocks belonging to an adjacent filesystem on the same device. The fix adds an s_nzones bounds check to rock_continue().
Continues the isofs hardening line (cf. CVE-2026-46124); validates the Rock Ridge CE extent block number against the volume size.
- CVE-2026-64223 8.1 HIGH
wifi: mac80211: consume only present negotiated TTLM maps
Linux kernel - mac80211 (net/mac80211)
ieee80211_parse_neg_ttlm() advanced its parse cursor for every TID, including TIDs whose presence bit is clear and therefore carry no map bytes, while ieee80211_tid_to_link_map_size_ok() sized the element counting only present entries. A peer-supplied sparse negotiated TT-LM element can then make a later present TID read past the validated element (slab-out-of-bounds under KUnit plus KASAN). The stray bytes land in the parsed uplink/downlink arrays but are gated by valid_links before being applied to driver state, so a peer cannot turn the read into a policy change.
- CVE-2026-63889 8.1 HIGH
scsi: scsi_transport_fc: Widen FPIN pname walker counter to u32
Linux kernel - scsi driver (drivers/scsi)
An adjacent Fibre Channel fabric actor that can deliver an FPIN ELS frame to an lpfc or qla2xxx Linux initiator can trigger a non-return in the generic FC transport. This is not a local userspace or IP network path; the attacker must be able to inject fabric traffic, for example as a compromised switch or fabric controller, or as a same-zone N_Port on a fabric that permits source spoofing.
- CVE-2026-63893 8.1 HIGH
thunderbolt: property: Reject u32 wrap in tb_property_entry_valid()
Linux kernel - thunderbolt driver (drivers/thunderbolt)
entry->value is u32 and entry->length is u16; the sum is performed in u32 and wraps. A malicious XDomain peer can pick value = 0xffffff00, length = 0x100 so the sum 0x100000000 wraps to 0 and passes the > block_len check. tb_property_parse() then passes entry->value to parse_dwdata() as a dword offset into the property block, reading attacker-directed memory far past the allocation.
- CVE-2026-53147 8.1 HIGH
thunderbolt: Validate XDomain request packet size before type cast
Linux kernel - Thunderbolt/USB4 XDomain (drivers/thunderbolt) [CWE-125]
tb_xdp_handle_request() casts the received packet buffer to protocol-specific structs without verifying that the allocation is large enough for the target type. A peer can send a minimal XDomain packet that passes the generic header length check but is shorter than the struct accessed after the cast, causing out-of- bounds reads from the kmemdup allocation. Plumb the packet length through xdomain_request_work and validate it against the expected struct size before each cast. The Linux kernel CVE team has assigned CVE-2026-53147 to this issue.
- CVE-2026-31708 8.1 HIGH
smb: client: fix OOB read in smb2_ioctl_query_info QUERY_INFO path
Linux kernel - Linux SMB client (fs/smb/client) [CWE-125]
The Linux SMB client's smb2_ioctl_query_info() had two response-copy branches: PASSTHRU_FSCTL was bounds-checked since 2019, but the QUERY_INFO branch never validated qi.input_buffer_length against the on-wire response, allowing a malicious SMB server to drive an out-of-bounds copy on the response buffer tail.
- CVE-2026-64532 7.8 HIGH
fs/ntfs3: bound NTFS_DE view.data_off in UpdateRecordData{Root,Allocation}
Linux kernel - NTFS3 filesystem (fs/ntfs3)
In the NTFS3 journal replay path, do_action()'s UpdateRecordDataRoot and UpdateRecordDataAllocation cases compute a memmove destination as Add2Ptr(e, e->view.data_off), where view.data_off is read from an on-disk NTFS_DE inside an INDEX_ROOT or INDEX_BUFFER. Neither case validated view.data_off + dlen against e->size: the existing check_if_index_root / check_if_alloc_index helpers walk the entry chain and validate each entry's offset, but not the view fields inside it. Neighbouring read sites in fs/ntfs3/index.c already enforce view.data_off + view.data_size <= e->size; the fix applies the same bound at the two memmove sites. Mounting a crafted NTFS image therefore drove an out-of-bounds write during log replay.
Reported and fixed by us; part of a four-patch fs/ntfs3 log-replay hardening series sent via security@kernel.org.
- CVE-2026-64324 7.8 HIGH
udf: validate free block extents against the partition length
Linux kernel - udf (fs/udf)
udf_free_blocks() checks the logical block number and count against the partition length but drops the extent offset from that final bound, so a crafted extent can pass the guard while logicalBlockNum + offset + count points past the partition and later indexes past the space-bitmap array. A single ftruncate(2) on a file backed by such an extent reliably panics the kernel. On desktop systems where UDisks/polkit lets the active user mount removable UDF media without CAP_SYS_ADMIN, an unprivileged local user can supply the crafted filesystem and trigger the panic.
- CVE-2026-64401 7.8 HIGH
smb: client: resolve SWN tcon from live registrations
Linux kernel - SMB client (fs/smb/client)
cifs_swn_notify() looked up a witness registration by id under cifs_swnreg_idr_mutex, dropped the mutex, and then used the registration's cached tcon pointer, which is not a lifetime reference and is not a stable representative once one registration id is shared by multiple tcons for the same net/share name. A same-share second mount can keep the registration alive after the first tcon unregisters and is freed, leaving the cached pointer dangling, so taking tc_lock or incrementing tc_count through it is a use-after-free (and also violated the documented CIFS lock order). The fix stores only stable witness identity and pins a live matching tcon at notify time under the correct lock order.
- CVE-2026-63894 7.8 HIGH
usb: gadget: f_fs: serialize DMABUF cancel against request completion
Linux kernel - usb driver (drivers/usb)
ffs_epfile_dmabuf_io_complete() calls usb_ep_free_request() on the completed request but leaves priv->req, the back-pointer that ffs_dmabuf_transfer() set on submission, pointing at the freed memory. A later FUNCTIONFS_DMABUF_DETACH ioctl or ffs_epfile_release() on the close path still sees priv->req non-NULL under ffs->eps_lock: if (priv->ep && priv->req) usb_ep_dequeue(priv->ep, priv->req); so usb_ep_dequeue() is called on a freed usb_request.
- CVE-2026-63918 7.8 HIGH
l2tp: use refcount_inc_not_zero in l2tp_session_get_by_ifname
Linux kernel - l2tp networking (net/l2tp)
A reader in l2tp_session_get_by_ifname() can return a pointer to a session whose refcount has reached zero. The getter takes its reference with plain refcount_inc(), but every other session getter in the same file (l2tp_v2_session_get, l2tp_v3_session_get, and the corresponding _get_next variants) uses refcount_inc_not_zero() because the IDR/RCU lookup can race with refcount_dec_and_test() -> l2tp_session_free() -> kfree_rcu().
- CVE-2026-64103 7.8 HIGH
scsi: isci: Fix use-after-free in device removal path
Linux kernel - scsi driver (drivers/scsi)
The ISCI completion tasklet is initialized in isci_host_alloc() (drivers/scsi/isci/init.c:496) and scheduled from both MSI-X and legacy interrupt handlers (drivers/scsi/isci/host.c:223,613). isci_host_deinit() stops the controller and waits for stop completion, but it never kills completion_tasklet before teardown continues.
- CVE-2026-64114 7.8 HIGH
ipv4: raw: reject IP_HDRINCL packets with ihl < 5
Linux kernel - ipv4 networking (net/ipv4)
raw_send_hdrinc() validates that the caller-supplied IPv4 header fits within the message length: iphlen = iph->ihl * 4; err = -EINVAL; if (iphlen > length) goto error_free; if (iphlen >= sizeof(*iph)) { /* fix up saddr, tot_len, id, csum, transport_header */ } It does not, however, reject ihl < 5. For such a packet the "if (iphlen >= sizeof(*iph))" branch is skipped, leaving the crafted iphdr untouched, but the packet is still handed to __ip_local_out() and onward.
- CVE-2026-64123 7.8 HIGH
net: hsr: defer node table free until after RCU readers
Linux kernel - hsr networking (net/hsr)
HSR node-list and node-status generic-netlink operations run under rcu_read_lock(). They walk hsr->node_db through hsr_get_next_node() and hsr_get_node_data(), but RTM_DELLINK teardown removes the same node table with plain list_del() and frees each node immediately. That lets a generic-netlink reader hold a struct hsr_node pointer across hsr_dellink().
- CVE-2026-64137 7.8 HIGH
smb: client: require net admin for CIFS SWN netlink
Linux kernel - smb filesystem (fs/smb)
CIFS_GENL_CMD_SWN_NOTIFY is the userspace witness-notify command. The intended sender is the cifs.witness helper, but the generic-netlink operation currently has no capability flag, so any local process can send RESOURCE_CHANGE or CLIENT_MOVE notifications to the in-kernel witness handler. The same family exposes CIFS_GENL_MCGRP_SWN without multicast-group capability flags.
- CVE-2026-53148 7.8 HIGH
thunderbolt: Clamp XDomain response data copy to allocation size
Linux kernel - Thunderbolt/USB4 XDomain (drivers/thunderbolt) [CWE-787]
tb_xdp_properties_request() derives the per-packet copy length from the response header without checking that it fits in the previously allocated data buffer. A malicious peer can set its length field larger than the declared data_length, causing memcpy to write past the kcalloc allocation. Clamp the per-packet copy length so that the cumulative offset never exceeds data_len. The Linux kernel CVE team has assigned CVE-2026-53148 to this issue.
- CVE-2026-53004 7.8 HIGH
sctp: fix OOB write to userspace in sctp_getsockopt_peer_auth_chunks
Linux kernel - SCTP (net/sctp) [CWE-787]
sctp_getsockopt_peer_auth_chunks() checks that the caller's optval buffer is large enough for the peer AUTH chunk list with if (len < num_chunks) return -EINVAL; but then writes num_chunks bytes to p->gauth_chunks, which lives at offset offsetof(struct sctp_authchunks, gauth_chunks) == 8 inside optval. The check is missing the sizeof(struct sctp_authchunks) = 8-byte header. When the caller supplies len == num_chunks (for any num_chunks > 0) the test passes but copy_to_user() writes sizeof(struct sctp_authchunks) = 8 bytes past the declared buffer.
- CVE-2026-64456 7.7 HIGH
hwrng: virtio: clamp device-reported used.len at copy_data()
Linux kernel - hwrng virtio (drivers/char/hw_random)
random_recv_done() stored the device-reported used.len directly into vi->data_avail, and copy_data() then indexed vi->data[] with a running index and issued a memcpy() without re-validating either value against the posted buffer size. A malicious or buggy virtio-rng backend can set used.len beyond the inline array, steering the memcpy past its end into adjacent kmalloc-1k slab bytes; hwrng_fillfn() mixes those bytes into the guest RNG and guest root can also read them via /dev/hwrng. The fill thread runs as soon as the device is probed, so no guest userspace interaction is needed to first trigger the out-of-bounds read. The fix clamps used.len at point of use with array_index_nospec().
- CVE-2026-46123 7.7 HIGH
Bluetooth: virtio_bt: clamp rx length before skb_put
Linux kernel - Bluetooth virtio_bt (drivers/bluetooth) [CWE-787]
The virtio Bluetooth transport called skb_put(skb, len) in virtbt_rx_work() with a length taken directly from the device backend via virtqueue_get_buf(), without validating it against the buffer actually posted to the device. A malicious or buggy virtio backend could supply an oversized length and overflow the receive skb.
First of a two-patch virtio_bt receive-path hardening series; CVE-2026-46186 is the second.
- CVE-2026-43350 7.6 HIGH
smb: client: require a full NFS mode SID before reading mode bits
Linux kernel - SMB client (fs/smb/client)
The Linux kernel SMB client treated an ACE SID matching sid_unix_NFS_mode as an NFS mode SID, then read sub_auth[2] without first requiring the ACE to carry three subauthorities. A malicious SMB server could return a short SID that still matched the prefix and trigger an out-of-bounds read in cifsacl parsing.
Direct client-side KCIFS4 assignment. CVE-2026-31611 remains the related server-side sister-fix for the same SID bound-check pattern.
- CVE-2026-53391 7.5 HIGH
NFSv4/pNFS: reject zero-length r_addr in nfs4_decode_mp_ds_addr
Linux kernel - nfs filesystem (fs/nfs) [CWE-476]
nfs4_decode_mp_ds_addr() decodes the r_netid and r_addr opaques of a netaddr4 from a GETDEVICEINFO multipath-DS body, then immediately calls strrchr(buf, '.') to locate the port separator. Both decodes use xdr_stream_decode_string_dup(), and the current code checks only "nlen < 0" / "rlen < 0" before dereferencing the returned string.
- CVE-2026-53392 7.5 HIGH
NFSv4/flexfiles: reject zero filehandle version count
Linux kernel - nfs filesystem (fs/nfs) [CWE-476]
ff_layout_alloc_lseg() decodes the filehandle-version array count from the flexfiles layout body. The value is used as the count for kzalloc_objs(), and the current code only rejects NULL. A zero count yields ZERO_SIZE_PTR, which can be stored in dss_info->fh_versions even though later flexfiles paths assume that at least one filehandle version exists. Reject fh_count == 0 before the allocation, matching the existing zero version_count validation in the flexfiles GETDEVICEINFO parser.
- CVE-2026-46114 7.5 HIGH
RDMA/rxe: Reject non-8-byte ATOMIC_WRITE payloads
Linux kernel - RDMA/rxe (drivers/infiniband/sw/rxe) [CWE-476]
The Linux kernel software RoCEv2 RDMA driver (rxe) accepted an ATOMIC_WRITE request whose RETH length was zero, because the length check only compared the packet length against the residual. atomic_write_reply() then unconditionally dereferenced eight bytes at the payload address, so a remote initiator could trigger an out-of-bounds read of kernel memory past the received packet.
Direct assignment for the rxe ATOMIC_WRITE bound-check fix.
- CVE-2026-46124 7.5 HIGH
isofs: validate block number from NFS file handle in isofs_export_iget
Linux kernel - isofs (fs/isofs)
The isofs NFS export path passed an attacker-controlled block number from the NFS file handle (ifid->block or ifid->parent_block) to isofs_export_iget(), which only rejected block 0 before calling isofs_iget() and ultimately sb_bread(). A crafted file handle could drive a read of an out-of-range block on an exported ISO9660 filesystem.
Direct assignment for the isofs NFS file-handle block-number validation fix.
- CVE-2026-46133 7.5 HIGH
RDMA/rxe: Reject unknown opcodes before ICRC processing
Linux kernel - RDMA/rxe (drivers/infiniband/sw/rxe) [CWE-125]
Even after an earlier fix that handled payload_size() underflow for valid opcodes in short packets, the rxe receive path still computed payload_size() for packets carrying an unknown opcode before rejecting them. A single unauthenticated UDP packet could therefore trigger an out-of-bounds read and kernel panic. The fix rejects unknown opcodes before any ICRC or length processing.
Distinct from CVE-2026-46114; this is the unknown-opcode receive-path fix in rxe_recv.
- CVE-2026-31711 7.5 HIGH
smb: server: fix active_num_conn leak on transport allocation failure
Linux kernel - ksmbd (fs/smb/server) [CWE-401]
ksmbd's transport allocation path leaked the active_num_conn counter when alloc_transport() returned NULL after a successful kernel_accept(). An unauthenticated remote attacker could drive cumulative allocation failures (e.g. via memory pressure) until atomic_inc_return() saturated max_connections, denying service to legitimate SMB clients.
Pre-auth slow remote DoS. Companion to other ksmbd hardening sent in the same week.
- CVE-2002-1809 7.5 HIGH
MySQL Windows binary release default NULL root password
MySQL AB - MySQL Windows binary 3.23.2-3.23.52 [NVD-CWE-Other]
The default configuration of the Windows binary release of MySQL 3.23.2 through 3.23.52 has a NULL root password, which could allow remote attackers to gain unauthorized root access to the MySQL database.
PoC published as mysqlfuck.c on Bugtraq.
- CVE-2002-1921 7.5 HIGH
MySQL Windows default bind address allows remote connections
MySQL AB - MySQL Windows 3.20.32-3.23.52 [NVD-CWE-Other]
The default configuration of MySQL 3.20.32 through 3.23.52, when running on Windows, does set the bind address to the loopback interface, which allows remote attackers to connect to the database.
Reported in same series as CVE-2002-1809.
- CVE-2002-1923 7.5 HIGH
MySQL Windows default config has logging disabled
MySQL AB - MySQL Windows 3.20.32-3.23.52 [NVD-CWE-Other]
The default configuration in MySQL 3.20.32 through 3.23.52, when running on Windows, does not have logging enabled, which could allow remote attackers to conduct activities without detection.
Reported in same series as CVE-2002-1809 and CVE-2002-1921.
- CVE-2026-64126 7.3 HIGH
Bluetooth: MGMT: validate Add Extended Advertising Data length
Linux kernel - bluetooth networking (net/bluetooth)
MGMT_OP_ADD_EXT_ADV_DATA is registered as a variable-length command, with MGMT_ADD_EXT_ADV_DATA_SIZE as the fixed header size. The handler then uses cp->adv_data_len and cp->scan_rsp_len to validate and copy cp->data, but it never checks that those bytes are part of the mgmt command payload. A short command can therefore make add_ext_adv_data() pass an out-of-bounds pointer into tlv_data_is_valid().
- CVE-2026-68425 7.1 HIGH
IB/mad: drop unmatched RMPP responses before reassembly
Linux kernel - InfiniBand MAD/RMPP (drivers/infiniband/core) [CWE-405, CWE-407]
Kernel-handled RMPP receive processing began reassembly for active DATA responses before the response was matched to an outstanding send; the normal match happens later, after ib_process_rmpp_recv_wc() has either assembled a complete message or consumed the segment. That ordering let an unsolicited response which routes to a kernel RMPP agent by the high TID bits allocate or extend RMPP receive state before the full TID and source address were checked against a real request, so an unmatched peer on the fabric could drive reassembly work and state growth. The fix drops unmatched responses before reassembly.
-
GLPI: arbitrary document read via answerable-form access-control bypass
GLPI - GLPI (glpi-project/glpi) [CWE-862, CWE-639]
GLPI's Document::canViewFileFromForm() served any file under GLPI_DOC_DIR without confirming the document was actually linked (Document_Item) to the targeted answerable form. On a public DirectAccess form the permission logic could therefore grant access to an uploaded document that the requester was not entitled to view, exposing arbitrary files by identifier. Fixed in GLPI 11.0.8.
GLPI advisory GHSA-q9rc-v6vm-q5mm publicly credits five analysts (Pig-Tail, Shad0wMazt3r, cipher-creator, geo-chen, mjbommar); reported independently by us. Affects >= 11.0.5, fixed 11.0.8.
-
isofs: bound Rock Ridge symlink components to the SL record
Linux kernel - isofs (fs/isofs)
get_symlink_chunk() and the SL handling in parse_rock_ridge_inode_internal() walk the variable-length components of a Rock Ridge SL (symbolic link) record. Each component is a two-byte header (flags, len) followed by len bytes of text, so it occupies len + 2 bytes, but the walk did not bound a component against the space actually remaining in the SL record. A crafted ISO9660 image with an oversized component length therefore drove an out-of-bounds read while resolving a symlink.
Independently found and reproduced by us (KUnit/UML/KASAN) with a local patch prepared, but Bryam Vargas filed the same fix publicly first. The upstream commit credits us with a Suggested-by trailer; the fix itself is Vargas's work.
- CVE-2026-64121 7.1 HIGH
net: ifb: report ethtool stats over num_tx_queues
Linux kernel - net driver (drivers/net)
ifb_dev_init() allocates dp->tx_private to dev->num_tx_queues entries via kzalloc_objs(*txp, dev->num_tx_queues). Both IFB per-queue RX and TX stats live in those entries: ifb_xmit() updates txp->rx_stats using the skb queue mapping, ifb_ri_tasklet() updates txp->tx_stats, and ifb_stats64() aggregates both over dev->num_tx_queues. The ethtool stats callbacks instead size and walk the per-queue stats with dev->real_num_rx_queues and dev->real_num_tx_queues.
- CVE-2026-53146 7.1 HIGH
thunderbolt: Limit XDomain response copy to actual frame size
Linux kernel - Thunderbolt/USB4 XDomain (drivers/thunderbolt) [NVD-CWE-noinfo]
tb_xdomain_copy() copies req->response_size bytes from the received packet buffer regardless of the actual frame size. When a short response arrives, this reads past the valid frame data in the DMA pool buffer into stale contents from previous transactions. Use the minimum of frame size and expected response size for the copy length. The Linux kernel CVE team has assigned CVE-2026-53146 to this issue.
- CVE-2026-53149 7.1 HIGH
thunderbolt: Bound root directory content to block size
Linux kernel - Thunderbolt/USB4 XDomain (drivers/thunderbolt) [CWE-125]
__tb_property_parse_dir() does not check that content_offset + content_len fits within block_len for the root directory case. When rootdir->length equals or exceeds block_len - 2, the entry loop reads past the allocated property block. Add a bounds check after computing content_offset and content_len to reject directories whose content extends past the block. The Linux kernel CVE team has assigned CVE-2026-53149 to this issue.
- CVE-2026-31707 7.1 HIGH
ksmbd: validate response sizes in ipc_validate_msg()
Linux kernel - ksmbd (fs/smb/server) [CWE-787]
ksmbd's ipc_validate_msg() computed the expected message size for each response type by summing or multiplying attacker-controlled fields from the userspace daemon's response into unsigned int arithmetic. Three response cases could overflow the size computation, leading to under-allocated buffers consumed by downstream parsing.
Patch 1 of the original KIPC_series; this is the cap on response sizes. The companion smb_check_perm_dacl() minimum ACE-size patch is tracked separately as CVE-2026-31712.
-
scsi: fcoe: Reject FIP descriptors with zero fip_dlen in CVL walker
Linux kernel - scsi driver (drivers/scsi)
drivers/scsi/fcoe/fcoe_ctlr.c::fcoe_ctlr_recv_clr_vlink() advanced the descriptor cursor by an attacker-supplied fip_dlen without ever requiring dlen >= sizeof(struct fip_desc) in the default branch. The named descriptor cases (FIP_DT_MAC, FIP_DT_NAME, FIP_DT_VN_ID) checked their per-type minimum lengths, but a FIP_DT_NON_CRITICAL descriptor (fip_dtype >= 128, which the standard requires receivers to silently ignore) skipped that check entirely.
-
Wireshark: NetLog reader NULL dereference on crafted file
Wireshark - Wireshark (wiretap NetLog reader) [CWE-476]
The wiretap NetLog (Chrome net-export JSON) reader used the result of json_get_array() without a NULL check, so a crafted NetLog file crashes Wireshark/tshark. Fixed upstream (commit b98723c359).
Fix commit authored by us. No CVE/advisory assigned (fixed as a robustness bug).
- CVE-2026-57963 6.5 MEDIUM
Thunderbird: chat UI manipulation via HTML message injection
Mozilla - Thunderbird (chat: Matrix/XMPP) [CWE-79]
An attacker who can send HTML chat messages (via Matrix or XMPP) can inject arbitrary styled content, phishing links, and CSS that manipulates the chat UI.
Reported to Mozilla; credited in MFSA 2026-63 for HTML/CSS injection in the Matrix and XMPP chat UI.
-
BlueZ: A2DP remote-endpoint codec-capability stack buffer overflow
BlueZ - BlueZ (A2DP profile) [CWE-121, CWE-787]
BlueZ stored a remote SEP's codec capabilities into a fixed stack buffer during A2DP endpoint discovery without bounding the advertised capability length, a stack buffer overflow reachable from a Bluetooth peer within range. Fixed upstream in BlueZ (commit 912f5efb0dd9, 'a2dp: Fix handling of codec capability storage').
Co-reported (with ZDI / Team H4C). The upstream fix carries a public 'Reported-by: Michael Bommarito' trailer. No CVE assigned.
-
usbip: vudc: Fix use after free bug in vudc_remove due to race condition
Linux kernel - usb driver (drivers/usb)
This patch follows up Zheng Wang's 2023 report of a use-after-free in vudc_remove(). The original thread stalled on Shuah Khan's request for runtime testing of the unplug/unbind path. This patch supplies that testing and keeps Zheng's original fix shape. In vudc_probe(), v_init_timer() binds udc->tr_timer.timer to v_timer(). usbip_sockfd_store() starts the timer via v_start_timer()/v_kick_timer(). vudc_remove() can then free the containing struct vudc while the timer is still pending or executing.
- CVE-2026-64105 5.5 MEDIUM
KVM: arm64: vgic: Free private_irqs when init fails after allocation
Linux kernel - arm64 arch (arch/arm64)
Companion to commit 250f25367b58 ("KVM: arm64: Tear down vGIC on failed vCPU creation"), which added the missing kvm_vgic_vcpu_destroy() call to the kvm_share_hyp() failure path in kvm_arch_vcpu_create(). The kvm_vgic_vcpu_init() failure path immediately above it has the same shape and still needs the same cleanup. Call kvm_vgic_vcpu_destroy() when kvm_vgic_vcpu_init() fails so private IRQs allocated before a redistributor iodev registration failure are released before the failed vCPU is freed
- CVE-2026-64119 5.5 MEDIUM
l2tp: use list_del_rcu in l2tp_session_unhash
Linux kernel - l2tp networking (net/l2tp)
An unprivileged local user can pin a host CPU indefinitely in l2tp_session_get_by_ifname() by issuing L2TP_CMD_SESSION_GET on L2TP_ATTR_IFNAME concurrently with L2TP_CMD_SESSION_CREATE and L2TP_CMD_SESSION_DELETE on the same tunnel. All three commands take GENL_UNS_ADMIN_PERM, so CAP_NET_ADMIN in the netns user namespace suffices; on any host that has l2tp_core loaded the trigger is reachable from a standard `unshare -Urn` sandbox.
- CVE-2026-64127 5.5 MEDIUM
Bluetooth: L2CAP: ecred_reconfigure: send packed pdu, not stack pointer
Linux kernel - bluetooth networking (net/bluetooth)
Commit 1c08108f3014 ("Bluetooth: L2CAP: Avoid -Wflex-array-member-not-at-end warnings") converted the on-stack request PDU in l2cap_ecred_reconfigure() from an explicit packed struct to DEFINE_RAW_FLEX(), but did not adjust the size and source-pointer arguments to l2cap_send_cmd(): - struct { - struct l2cap_ecred_reconf_req req; - __le16 scid; - } pdu; + DEFINE_RAW_FLEX(struct l2cap_ecred_reconf_req, pdu, scid, 1); ...
- CVE-2026-15174 5.5 MEDIUM
Wireshark: Catapult DCT2000 dissector crash (E-DCH DDI count overrun)
Wireshark - Wireshark (Catapult DCT2000 / UMTS FP dissector) [CWE-787, CWE-129]
The Catapult DCT2000 dissector decoded an E-DCH DDI count that could exceed the fixed UMTS FP arrays and overran them into wmem allocator metadata. A crafted DCT2000 capture, or a malformed packet injected on the wire, crashes Wireshark/tshark. Fixed in Wireshark 4.6.7 and 4.4.17.
Fix commit authored by us; the wnpa-sec advisory does not name a reporter.
- CVE-2026-53150 5.5 MEDIUM
thunderbolt: Reject zero-length property entries in validator
Linux kernel - Thunderbolt/USB4 XDomain (drivers/thunderbolt) [CWE-191]
tb_property_entry_valid() accepts entries with length == 0 for DIRECTORY, DATA, and TEXT types. A zero-length TEXT entry passes validation but causes an underflow in the null-termination logic: property->value.text[property->length * 4 - 1] = '\0'; When property->length is 0 this writes to offset -1 relative to the allocation. Reject zero-length entries early in the validator since they have no valid representation in the XDomain property protocol. The Linux kernel CVE team has assigned CVE-2026-53150 to this issue.
- CVE-2026-53208 5.5 MEDIUM
Bluetooth: L2CAP: reject BR/EDR signaling packets over MTUsig
Linux kernel - Bluetooth L2CAP (net/bluetooth) [NVD-CWE-noinfo]
net/bluetooth/l2cap_core.c:l2cap_sig_channel() accepts BR/EDR signaling packets up to the channel MTU and dispatches each command without enforcing the signaling MTU (MTUsig). A Bluetooth BR/EDR peer within radio range can send a fixed-channel CID 0x0001 packet that is larger than MTUsig and contains many L2CAP_ECHO_REQ commands before pairing. In a real-radio stock-kernel run, one 681-byte signaling packet containing 168 zero-length ECHO_REQ commands made the target transmit 168 ECHO_RSP frames over about 220 ms. Impact: a Bluetooth BR/EDR peer within radio range, before pairing, can force 168 ECHO_RSP frames from one 681-byte fixed-channel signaling packet containing packed ECHO_REQ commands.
- CVE-2026-52995 5.5 MEDIUM
net/rds: zero per-item info buffer before handing it to visitors
Linux kernel - RDS (net/rds)
rds_for_each_conn_info() and rds_walk_conn_path_info() both hand a caller-allocated on-stack u64 buffer to a per-connection visitor and then copy the full item_len bytes back to user space via rds_info_copy() regardless of how much of the buffer the visitor actually wrote. rds_ib_conn_info_visitor() and rds6_ib_conn_info_visitor() only write a subset of their output struct when the underlying rds_connection is not in state RDS_CONN_UP (src/dst addr, tos, sl and the two GIDs via explicit memsets).
- CVE-2026-46186 5.5 MEDIUM
Bluetooth: virtio_bt: validate rx pkt_type header length
Linux kernel - Bluetooth virtio_bt (drivers/bluetooth) [CWE-908]
The virtio Bluetooth transport read the leading pkt_type byte from a received skb and forwarded the remainder to hci_recv_frame() for every event/ACL/SCO/ISO type, without checking that the remaining payload met the fixed HCI header length for that type. After the length of the backend-supplied buffer is bounded, a one-byte completion could still reach hci_recv_frame() with an undersized buffer.
Second of a two-patch virtio_bt receive-path hardening series; CVE-2026-46123 is the first.
- CVE-2026-46193 5.5 MEDIUM
xfrm: ah: account for ESN high bits in async callbacks
Linux kernel - xfrm AH (net/ipv4, net/ipv6) [NVD-CWE-noinfo]
When ESN was enabled, the IPsec AH async hash setup appended a 4-byte sequence-high slot before the ICV or auth-data area, but the async completion callbacks reconstructed the temporary layout as if that slot were absent. With an async AH implementation selected, AH copied or compared the wrong bytes on both the IPv4 and IPv6 paths, corrupting authentication handling.
Direct assignment for the AH ESN async-callback layout fix across the IPv4 and IPv6 AH paths.
- CVE-2026-57962 5.3 MEDIUM
Thunderbird: denial-of-service via malicious LDAP address-book server
Mozilla - Thunderbird (LDAP address-book client) [CWE-400]
A malicious LDAP server, which a Thunderbird user is configured to query for address-book autocomplete, can stash arbitrarily large amounts of attacker-supplied data into the Thunderbird LDAP client until it crashes due to memory exhaustion.
Reported to Mozilla; credited in MFSA 2026-63 for the LDAP address-book memory-exhaustion denial of service.
-
thunderbolt: property: Reject dir_len < 4 to prevent size_t underflow
Linux kernel - thunderbolt driver (drivers/thunderbolt)
On the non-root path, __tb_property_parse_dir() takes dir_len from entry->length (u16 widened to size_t). Two distinct OOB conditions follow when entry->length < 4: 1. The non-root path begins with kmemdup(&block[dir_offset], sizeof(*dir->uuid), ...) which always reads 4 dwords from dir_offset.
-
thunderbolt: property: Cap recursion depth in __tb_property_parse_dir()
Linux kernel - thunderbolt driver (drivers/thunderbolt)
A DIRECTORY entry's value field is used as the dir_offset for a recursive call into __tb_property_parse_dir() with no depth counter. A crafted peer that chains DIRECTORY entries into a back-reference loop drives the parser until the kernel stack is exhausted and the guard page fires. Any untrusted XDomain peer (cable, dock, in-line inspector, adjacent host) that reaches the PROPERTIES_REQUEST control-plane exchange can trigger this without authentication.
-
libbpf: USDT /proc maps path parsed into PATH_MAX stack buffer without width limit
libbpf - libbpf (USDT attach / VMA parser) [CWE-120, CWE-787]
libbpf's USDT attach path parsed /proc/<pid>/maps pathnames into a PATH_MAX stack buffer using a width-less scanf conversion, so an overlong mapping path could overflow the buffer. Hardened upstream in parse_vma_segs() (commit fee9a38174f4c, 'libbpf: Harden parse_vma_segs() path parsing').
Fix commit authored by us. No CVE assigned.
-
Wireshark: pcapng NRB writer over-copies custom string options (heap over-read)
Wireshark - Wireshark (pcapng writer) [CWE-125, CWE-126]
The pcapng writer over-copied custom UTF-8 string options when emitting a Name Resolution Block, a heap buffer over-read. Fixed upstream (commit 4162912cac).
Fix commit authored by us. No CVE/advisory assigned.
- CVE-2026-61477 2.3 LOW
libvirt: line-break injection from DNS TXT/SRV records into the generated dnsmasq configuration
libvirt - network driver (src/conf, src/network) [CWE-93]
A libvirt virtual network can define typed DNS records through the <dns><txt> and <dns><srv> elements. The TXT value and the SRV domain and target attributes accepted XML numeric character references for line breaks ( for LF, for CR), which survive XML attribute-value normalization. The network driver later wrote those values verbatim into dnsmasq's line-oriented configuration file as txt-record= and srv-host= lines, so an embedded line break ended the intended directive and started a new one of the submitter's choosing (for example an injected dhcp-script= directive). Direct read-write access to the libvirt socket is already root-equivalent, so this is defense-in-depth for a default deployment; the meaningful boundary is a management layer that lets a less privileged user edit typed DNS records while withholding raw <dnsmasq:options> passthrough, where the injected directive escapes that restriction.
Reported the issue to the libvirt security team and prepared the fix, which rejects line breaks in the affected DNS fields at XML parse time and adds a defensive check in the dnsmasq configuration emitter. CVE assigned by Red Hat Product Security; rated low severity.
- CVE-2026-72014 unscored
drbd: reject data replies with an out-of-range payload size
Linux kernel - Linux kernel (drivers/block/drbd/drbd_receiver.c)
drbd: reject data replies with an out-of-range payload size recv_dless_read() receives a P_DATA_REPLY from a peer into the bio of an outstanding read request. The peer-supplied payload length reaches it as the signed int data_size, and two peer-controlled inputs can make it negative. With a negotiated data-integrity-alg the digest length is subtracted first, so a reply whose payload is smaller than the digest underflows data_size. With no integrity algorithm (the default) data_size is assigned from the unsigned h95/h100 wire length and drbdd() never bounds it for a payload-carrying command, so a length above INT_MAX casts it negative; this path needs no non-default feature. The bio receive loop then computes expect = min_t(int, data_size, bv_len), which is negative, and drbd_recv_all_warn(mapped, expect) receives with a size_t of SIZE_MAX into the first mapped page. The sibling receive path read_in_block() is not affected: it uses an unsigned size and rejects it against DRBD_MAX_BIO_SIZE before receiving. Reject a data reply whose size is negative after the optional digest subtraction, covering both triggers. Impact: a malicious or man-in-the-middle DRBD peer copies attacker-chosen bytes past a bio page in the receiver, corrupting kernel memory. A node that reads from its peer (a diskless node, or read-balancing to the peer) is exposed in the default configuration; data-integrity-alg is not required.
Reported and fixed by us; matched against the published Linux CNA advisory record.
- CVE-2026-72049 unscored
ieee802154: admin-gate legacy LLSEC dump operations
Linux kernel - Linux kernel (net/ieee802154/ieee802154.h, net/ieee802154/netlink.c)
ieee802154: admin-gate legacy LLSEC dump operations In net/ieee802154/netlink.c, the legacy IEEE802154_NL family ops table builds the LLSEC dump entries (LLSEC_LIST_KEY, LLSEC_LIST_DEV, LLSEC_LIST_DEVKEY, LLSEC_LIST_SECLEVEL) with IEEE802154_DUMP() which sets no .flags, so generic netlink runs them ungated. The modern nl802154 family admin-gates the equivalent reads via NL802154_CMD_GET_SEC_KEY and friends with .flags = GENL_ADMIN_PERM. Any local uid that can open AF_NETLINK / NETLINK_GENERIC can resolve the "802.15.4 MAC" family and dump LLSEC_LIST_KEY on any wpan netdev that has an LLSEC key installed; the dump handler writes the raw 16-byte AES-128 key bytes (IEEE802154_ATTR_LLSEC_KEY_BYTES, copied verbatim from struct ieee802154_llsec_key.key) into the reply. Recovering the AES key compromises 802.15.4 LLSEC link confidentiality and authenticity, since LLSEC uses CCM* and the same key authenticates and encrypts frames. Impact: any local uid with no capabilities can read the raw 16-byte AES-128 LLSEC key from the kernel keytable on any wpan netdev that has an administrator-installed LLSEC key, by issuing an LLSEC_LIST_KEY dump on the legacy IEEE802154_NL generic-netlink family. Introduce IEEE802154_DUMP_PRIV() mirroring IEEE802154_DUMP() but setting .flags = GENL_ADMIN_PERM, and use it for the four LLSEC dump entries. LIST_PHY and LIST_IFACE retain IEEE802154_DUMP() because the modern nl802154 family exposes their equivalents to unprivileged readers by design (NL802154_CMD_GET_WPAN_PHY and NL802154_CMD_GET_INTERFACE carry "can be retrieved by unprivileged users" annotations).
Reported and fixed by us; matched against the published Linux CNA advisory record.
- CVE-2026-72071 unscored
tracing/user_events: Fix use-after-free in user_event_mm_dup()
Linux kernel - Linux kernel (kernel/trace/trace_events_user.c)
tracing/user_events: Fix use-after-free in user_event_mm_dup() user_event_mm_dup() walks the parent mm's enabler list locklessly under rcu_read_lock() during fork() (from copy_process()); it does not take event_mutex: rcu_read_lock(); list_for_each_entry_rcu(enabler, &old_mm->enablers, mm_enablers_link) enabler->event = user_event_get(orig->event); user_event_enabler_destroy() removes an enabler from that list with list_del_rcu() and then, without waiting for a grace period, drops the enabler's user_event reference with user_event_put() and frees the enabler with kfree(). A reader that loaded the enabler before the list_del_rcu() can still be walking it, which leads to two use-after-frees: - kfree(enabler) frees the enabler while that reader dereferences enabler->event. - user_event_put() may drop the last reference to the user_event, which is then freed (via delayed_destroy_user_event() on a work queue), while the same reader does user_event_get(orig->event) on it. Both are reachable by an unprivileged task that can open user_events_data: one multithreaded process that registers an enabler and then concurrently unregisters it and calls fork() triggers the race. KASAN reports a slab-use-after-free in user_event_mm_dup() during clone(), with a "refcount_t: addition on 0" warning when the user_event is freed. The enabler use-after-free was found first; the user_event one was reported by XIAO WU, and the earlier enabler-only fix did not address it. Defer both the user_event_put() and the kfree(enabler) to a work item queued with queue_rcu_work(), so they run only after an RCU grace period, once all readers walking the enabler list have finished. The put must run in process context because user_event_put() takes event_mutex on the last reference, so a work queue is used rather than call_rcu(). The now-unlocked put lets the locked argument of user_event_enabler_destroy() be removed; all callers are updated.
Reported and fixed by us; matched against the published Linux CNA advisory record.
- CVE-2026-72130 unscored
nvmet-auth: reject short AUTH_RECEIVE buffers
Linux kernel - Linux kernel (drivers/nvme/target/fabrics-cmd-auth.c)
nvmet-auth: reject short AUTH_RECEIVE buffers nvmet_execute_auth_receive() trusts the AUTH_RECEIVE allocation length after checking only that it is nonzero and matches the transfer length. In the SUCCESS1 and FAILURE1/default states, that lets a remote NVMe-oF initiator reach the fixed-size DH-HMAC-CHAP response builders with a kmalloc() buffer shorter than the response, so nvmet_auth_success1() and nvmet_auth_failure1() write past the allocation; both only WARN_ON the short length and then format the message anyway. Impact: A remote NVMe-oF initiator with access to an auth-enabled target can trigger a 16-byte heap out-of-bounds write via a one-byte AUTH_RECEIVE allocation length. Compute the minimum response length for the current DH-HMAC-CHAP step in nvmet_auth_receive_data_len() and report a zero data length when the host-supplied allocation length is shorter, so the existing zero-length check in nvmet_execute_auth_receive() rejects the command before any builder runs. The SUCCESS1 minimum is sizeof(struct nvmf_auth_dhchap_success1_data) plus the HMAC hash length, because the response hash is written into the rval[] flexible-array tail, so the minimum is state dependent rather than a flat sizeof. CHALLENGE keeps its existing variable-length guard in nvmet_auth_challenge(). This is reachable only when in-band DH-HMAC-CHAP authentication is configured on the target.
Reported and fixed by us; matched against the published Linux CNA advisory record.
- CVE-2026-72139 unscored
tcp: defer md5sig_info kfree past RCU grace period in tcp_connect
Linux kernel - Linux kernel (net/ipv4/tcp_ipv4.c, net/ipv4/tcp_output.c)
tcp: defer md5sig_info kfree past RCU grace period in tcp_connect The md5+ao reconciliation in tcp_connect() (net/ipv4/tcp_output.c) has two symmetric branches: if (needs_md5) { tcp_ao_destroy_sock(sk, false); } else if (needs_ao) { tcp_clear_md5_list(sk); kfree(rcu_replace_pointer(tp->md5sig_info, NULL, ...)); } Both branches free a per-socket auth-info object while the socket is in TCP_SYN_SENT and is already on the inet ehash (inserted by inet_hash_connect() in tcp_v4_connect()). Both branches are reachable by softirq RX-path readers that load the corresponding info pointer via implicit RCU before bh_lock_sock_nested() is taken. The needs_md5 branch is fixed in the prior patch by re-introducing the call_rcu() free in tcp_ao_destroy_sock(): the equivalent per-key loop runs inside tcp_ao_info_free_rcu(), the RCU callback, so by the time it frees each tcp_ao_key all softirq readers that captured the container have already completed rcu_read_unlock(). The needs_ao branch is not symmetric in the same way. The container free can be deferred via kfree_rcu(md5sig, rcu) -- struct tcp_md5sig_info already has the required rcu member (include/net/tcp.h:1999-2002), and the rest of the tree already does this in the tcp_md5sig_info_add() rollback paths (net/ipv4/tcp_ipv4.c:1410, 1436). But the per-key teardown is done by tcp_clear_md5_list() in process context BEFORE the container's RCU grace period: it walks &md5sig->head and frees each tcp_md5sig_key with bare hlist_del + kfree. A concurrent softirq reader in __tcp_md5_do_lookup() / __tcp_md5_do_lookup_exact() (tcp_ipv4.c:1253, 1298) walks the same list via hlist_for_each_entry_rcu() and races with that bare kfree on the keys themselves -- a per-key slab use-after-free of the same class as the TCP-AO bug, on the same race window. Fix this in two halves: 1. Convert the bare kfree() in tcp_connect() to kfree_rcu() so the md5sig_info container joins the rest of the md5sig lifecycle. The local-variable lift is mechanical and required because kfree_rcu() is a macro that expects an lvalue. 2. Make tcp_clear_md5_list() RCU-safe by replacing hlist_del + kfree(key) with hlist_del_rcu + kfree_rcu(key, rcu). struct tcp_md5sig_key already carries the rcu member (include/net/tcp.h:1995) and tcp_md5_do_del() (net/ipv4/tcp_ipv4.c:1456) already uses kfree_rcu, so this restores the lifecycle invariant the rest of the file follows rather than introducing a one-off. The other caller of tcp_clear_md5_list() is tcp_md5_destruct_sock() (net/ipv4/tcp.c:412), which runs from the sock destructor when the socket is already unhashed and unreachable; the extra grace period there is unnecessary but harmless. Making the helper unconditionally RCU-safe is the cleaner contract. The needs_ao branch is not reachable by the userns reproducer used to demonstrate the AO-side splat (the repro installs both keys but ends up in the needs_md5 branch because the connect peer matches the MD5 key, not the AO key); however the symmetric race exists and a maintainer touching this code should not have to think about which branch escapes RCU and which one does not. [also credits to Qihang, who found that this races with tcp-diag]
Reported and fixed by us; matched against the published Linux CNA advisory record.
- CVE-2026-72151 unscored
tpm: tpm2-sessions: wait for async KPP completion in tpm_buf_append_salt
Linux kernel - Linux kernel (drivers/char/tpm/tpm2-sessions.c)
tpm: tpm2-sessions: wait for async KPP completion in tpm_buf_append_salt tpm_buf_append_salt() in drivers/char/tpm/tpm2-sessions.c calls crypto_kpp_generate_public_key() and crypto_kpp_compute_shared_secret() without installing a completion callback, discards both return values, and immediately frees the kpp_request via kpp_request_free(). When the resolved ecdh-nist-p256 KPP backend is asynchronous (atmel-ecc, HPRE, keembay-ocs), either operation returns -EINPROGRESS and the deferred completion worker dereferences the freed request. The path fires automatically from the hwrng_fillfn kernel thread via tpm_get_random -> tpm2_get_random -> tpm2_start_auth_session -> tpm_buf_append_salt on every entropy poll, without any userland action. Install crypto_req_done as the completion callback, wrap both KPP operations in crypto_wait_req(), and propagate errors to the caller. The wait is a no-op for synchronous backends.
Reported and fixed by us; matched against the published Linux CNA advisory record.
- CVE-2026-72159 unscored
ocfs2: reject non-inline dinodes with i_size and zero i_clusters
Linux kernel - Linux kernel (fs/ocfs2/inode.c)
ocfs2: reject non-inline dinodes with i_size and zero i_clusters On a volume mounted without OCFS2_FEATURE_INCOMPAT_SPARSE_ALLOC, a non-inline regular file with non-zero i_size and zero i_clusters is structurally malformed: the extent map declares no allocated clusters yet the size header claims content exists. Keep rejecting that shape, but express it through a shared predicate so the same invariant is available to normal inode reads and online filecheck. The same zero-cluster shape is also malformed for non-inline directories. ocfs2 directory growth allocates backing storage before advancing i_size, and ocfs2_dir_foreach_blk_el() later walks until ctx->pos reaches i_size_read(inode). A forged directory dinode with a huge i_size and no clusters would repeatedly fail on holes while advancing through the claimed size. Sparse regular files remain exempt: on sparse-alloc volumes, truncate can legitimately grow i_size without allocating clusters. System inodes and inline-data dinodes also retain their separate storage rules. Mirror the check in ocfs2_filecheck_validate_inode_block() as well. filecheck reports through its own error namespace, so malformed size/cluster state is logged as a filecheck invalid-inode result rather than via ocfs2_error(), but it must not proceed into ocfs2_populate_inode().
Reported and fixed by us; matched against the published Linux CNA advisory record.
- CVE-2026-72160 unscored
ocfs2: reject dinodes with non-canonical i_mode type
Linux kernel - Linux kernel (fs/ocfs2/inode.c)
ocfs2: reject dinodes with non-canonical i_mode type Patch series "ocfs2: harden inode validators against forged metadata", v2. This series adds three structural checks to OCFS2 dinode validation so malformed on-disk fields are rejected before ocfs2_populate_inode() copies them into the in-core inode. The checks cover: - i_mode values whose type bits do not name a canonical POSIX file type; - non-device dinodes whose id1.dev1.i_rdev field is non-zero; and - non-inline dinodes that claim non-zero i_size while i_clusters is zero, covering directories unconditionally and regular files on non-sparse volumes. The normal read path reports these through ocfs2_error(), matching the existing suballoc-slot, inline-data, chain-list, and refcount checks. The online filecheck path uses the same structural predicates but keeps its own reporting contract, returning OCFS2_FILECHECK_ERR_INVALIDINO instead of calling ocfs2_error(). This patch (of 3): ocfs2_validate_inode_block() currently accepts any non-zero i_mode value. ocfs2_populate_inode() then copies that mode verbatim into inode->i_mode and dispatches on i_mode & S_IFMT to the file/dir/symlink/special_file iops; an unrecognised type falls through to ocfs2_special_file_iops and init_special_inode(). Reject dinodes whose type bits do not name one of the seven canonical POSIX file types. Use fs_umode_to_ftype(), the same generic file-type conversion helper OCFS2 already uses for directory entries, so the accepted inode type set matches the kernel file-type vocabulary instead of open-coding a local switch. Apply the same structural check to the online filecheck read path. filecheck keeps its own error namespace, so it reports malformed i_mode through the filecheck logger and OCFS2_FILECHECK_ERR_INVALIDINO instead of calling ocfs2_error(), but it must not allow a malformed dinode to proceed into ocfs2_populate_inode().
Reported and fixed by us; matched against the published Linux CNA advisory record.
- CVE-2026-72193 unscored
ntfs3: cap RESTART_TABLE free-chain walker at rt->used
Linux kernel - Linux kernel (fs/ntfs3/fslog.c)
ntfs3: cap RESTART_TABLE free-chain walker at rt->used A crafted NTFS3 disk image triggers an in-kernel infinite loop at mount time, hanging the mounting thread and firing the soft-lockup watchdog within ~22s on multi-CPU hosts (panic with kernel.softlockup_panic=1). The bug is reachable from desktop USB auto-mount on distributions where udisks2 routes the NTFS signature to the in-tree ntfs3 driver (Arch family and an increasing fraction of Fedora / openSUSE / RHEL deployments); CAP_SYS_ADMIN-class manual mount elsewhere. check_rstbl()'s second walker iterates the free-entry singly-linked list headed by rt->first_free with no upper bound on iteration count: for (off = ff; off;) { if (off == RESTART_ENTRY_ALLOCATED) return false; off = le32_to_cpu(*(__le32 *)Add2Ptr(rt, off)); if (off > ts - sizeof(__le32)) return false; } The existing guards cover three exits: end-of-list (off == 0), the in-use marker (off == RESTART_ENTRY_ALLOCATED), and out-of-bounds (off > ts - sizeof(__le32)). None of the three prevents an in-bounds cycle. A crafted on-disk RESTART_TABLE whose free chain contains a self-loop or A->B->A cycle whose offsets satisfy: - in range [sizeof(struct RESTART_TABLE), ts - sizeof(__le32)] - (off - sizeof(struct RESTART_TABLE)) % rsize == 0 passes all existing guards and spins the mount-time thread forever. Reproduced in UML by hand-forging a 2 MB NTFS3 image whose journal RESTART_TABLE first_free = 0x18 and whose entry at offset 0x18 stores 0x18 as its next pointer; mount of the forged image with the in-tree ntfs3 driver never returns. Bound the walker by rt->used. Each entry on a legitimate free chain is unique, and the total slot count is ne = le16_to_cpu (rt->used). A traversal that visits more than ne slots is by construction malformed; reject it as a corrupt RESTART_TABLE. After this patch, mount of the forged image returns with -EINVAL and a log_replay failure message, and mkntfs-produced legitimate images mount cleanly (verified in the same UML harness).
Reported and fixed by us; matched against the published Linux CNA advisory record.
- CVE-2026-72195 unscored
fs/ntfs3: bound attr_off in UpdateResidentValue against data_off
Linux kernel - Linux kernel (fs/ntfs3/fslog.c)
fs/ntfs3: bound attr_off in UpdateResidentValue against data_off In do_action()'s UpdateResidentValue case (fslog.c:3307), lrh->attr_off and lrh->redo_len come from the on-disk LRH. When they satisfy aoff + dlen < attr->res.data_off, the assignment attr->res.data_size = cpu_to_le32(aoff + dlen - data_off); underflows to ~4 GiB (e.g. 0xFFFFFFF9 when aoff=0x10, dlen=1, data_off=0x18). Subsequent code that reads attr->res.data_size to walk the resident attribute payload would then read up to 4 GiB past the 1024-byte MFT record allocation. The existing mi_enum_attr() defense in fs/ntfs3/record.c:287 catches the corrupted data_size on the next attribute walk and fails the mount, but only on the path that walks all attributes. A read site that picks an attribute by name and reads its data_size without re-validating is not covered. Validate aoff against data_off and asize at the source. Reproduced under UML+KASAN on mainline 8d90b09e6741 via pr_warn-only probe: with aoff=0x10 and data_off=0x18, the post-assignment data_size is 0xfffffff9 (mount then fails at -22 from mi_enum_attr). [almaz.alexandrovich@paragon-software.com: clang-formatted the changes]
Reported and fixed by us; matched against the published Linux CNA advisory record.
- CVE-2026-72196 unscored
fs/ntfs3: bound copy_lcns dp->page_lcns[] index in analysis pass
Linux kernel - Linux kernel (fs/ntfs3/fslog.c)
fs/ntfs3: bound copy_lcns dp->page_lcns[] index in analysis pass In log_replay()'s analysis pass, after find_dp() returns a valid DIR_PAGE_ENTRY for the (target_attr, target_vcn) tuple, the copy_lcns block walks lrh->lcns_follow further entries: t16 = le16_to_cpu(lrh->lcns_follow); for (i = 0; i < t16; i++) { size_t j = (size_t)(le64_to_cpu(lrh->target_vcn) - le64_to_cpu(dp->vcn)); dp->page_lcns[j + i] = lrh->page_lcns[i]; } find_dp() only validates that target_vcn falls within [dp->vcn, dp->vcn + dp->lcns_follow), i.e., that the FIRST cluster is covered. The walk through the further entries is not bounded against dp->lcns_follow. For a malformed LRH where target_vcn = dp->vcn + dp->lcns_follow - 1 and lrh->lcns_follow > 1, the i > 0 writes overflow the dp's allocated page_lcns[] array. Add the missing j + lrh->lcns_follow <= dp->lcns_follow guard. Reproduced under UML+KASAN on mainline 8d90b09e6741 as a slab-out-of-bounds write of size 8 from log_replay+0x68d4 on the mount path. This is distinct from Pavitra Jha's 2026-05-02 patch ("fs/ntfs3: validate lcns_follow in log_replay conversion", <20260502154252.164586-1-jhapavitra98@gmail.com>) which addresses the separate version-0 dirty-page-table conversion path's memmove(&dp->vcn, ...) call. The two fixes are complementary; both should land. [almaz.alexandrovich@paragon-software.com: clang-formatted the changes, fixed conflicts]
Reported and fixed by us; matched against the published Linux CNA advisory record.
- CVE-2026-72197 unscored
fs/ntfs3: bound DeleteIndexEntryAllocation memmove length
Linux kernel - Linux kernel (fs/ntfs3/fslog.c)
fs/ntfs3: bound DeleteIndexEntryAllocation memmove length In do_action()'s DeleteIndexEntryAllocation case, e->size comes from an on-disk INDEX_BUFFER entry. When e->size makes e + e->size point past hdr + hdr->used, PtrOffset(e1, Add2Ptr(hdr, used)) returns a negative ptrdiff_t that is silently cast to a quasi-infinite size_t when passed to memmove(). The memmove then walks past the destination buffer. The sibling DeleteIndexEntryRoot case at fslog.c:3540-3543 already carries the corresponding guard: if (PtrOffset(e1, Add2Ptr(hdr, used)) < esize || Add2Ptr(e, esize) > Add2Ptr(lrh, rec_len) || used + esize > le32_to_cpu(hdr->total)) { goto dirty_vol; } Apply the same shape to the allocation-path case. Also reject esize == 0: memmove(e, e, ...) is a no-op and leaves hdr->used unchanged, hiding a malformed entry from the existing check_index_header() walk. Reproduced under UML+KASAN on mainline 8d90b09e6741 by mounting a crafted NTFS image: the unguarded memmove takes a length of 0xffffffffffffff00 and the kernel oopses in memmove+0x81/0x1a0 on the do_action+0x36a2 frame. [almaz.alexandrovich@paragon-software.com: clang-formatted the changes]
Reported and fixed by us; matched against the published Linux CNA advisory record.
- CVE-2026-72298 unscored
net: qrtr: fix 32-bit integer overflow in qrtr_endpoint_post()
Linux kernel - Linux kernel (net/qrtr/af_qrtr.c)
net: qrtr: fix 32-bit integer overflow in qrtr_endpoint_post() qrtr_endpoint_post() validates an incoming packet with if (!size || len != ALIGN(size, 4) + hdrlen) goto err; where size comes from the wire. On 32-bit, size_t is 32 bits and ALIGN(size, 4) wraps to 0 for size >= 0xfffffffd, so the check passes and skb_put_data(skb, data + hdrlen, size) writes past the hdrlen-sized skb and oopses the kernel. 64-bit is unaffected. This is the 32-bit residual of ad9d24c9429e2 ("net: qrtr: fix OOB Read in qrtr_endpoint_post"), which fixed only the 64-bit case. Reject any size that cannot fit the buffer before the ALIGN.
Reported and fixed by us; matched against the published Linux CNA advisory record.
- CVE-2026-72369 unscored
minix: avoid overflow in bitmap block count calculation
Linux kernel - Linux kernel (fs/minix/minix.h)
minix: avoid overflow in bitmap block count calculation minix_check_superblock() uses minix_blocks_needed() to verify that the on-disk imap and zmap block counts are large enough for the advertised inode and zone counts. The helper currently performs DIV_ROUND_UP() in unsigned int arithmetic. A Minix v3 image can set s_ninodes or s_zones near UINT_MAX so the addition inside DIV_ROUND_UP() wraps to zero. That makes a zero imap/zmap block count look valid, after which minix_fill_super() can dereference s_imap[0] or s_zmap[0] even though no bitmap buffers were allocated. Impact: mounting a crafted Minix v3 image whose s_ninodes or s_zones is near UINT_MAX makes minix_check_superblock() accept a zero bitmap-block count and minix_fill_super() dereference s_imap[0]/s_zmap[0], panicking the kernel. The divisor is the bitmap capacity in bits, blocksize * 8, which is always a power of two: minix_fill_super() obtains the block size through sb_set_blocksize(), and blk_validate_block_size() rejects any size that is not a power of two. Use DIV_ROUND_UP_POW2(), which divides before adding the round-up term and so cannot overflow for a power-of-two divisor.
Reported and fixed by us; matched against the published Linux CNA advisory record.
- CVE-2026-72380 unscored
xen/pvcalls: bound backend response req_id before indexing rsp[]
Linux kernel - Linux kernel (drivers/xen/pvcalls-front.c)
xen/pvcalls: bound backend response req_id before indexing rsp[] pvcalls_front_event_handler() takes req_id directly from the backend-supplied ring response and uses it to index the fixed-size bedata->rsp[] array for a memcpy() and a store, with no range check. A malicious or buggy backend can set req_id past PVCALLS_NR_RSP_PER_RING and drive an out-of-bounds write past the bedata allocation. req_id was also declared int while the wire field rsp->req_id is u32, so a range check on the signed value alone is insufficient: a backend req_id of 0xffffffff becomes -1, passes a >= PVCALLS_NR_RSP_PER_RING test and indexes bedata->rsp[-1]. Declare req_id as u32 so a single bound covers both ends. A backend that sends an out-of-range req_id has violated the wire protocol, so rather than silently dropping the response, log once and stop trusting the backend: set bedata->disabled. The event handler then ignores further responses, and the request paths that wait for a response return -EIO instead of blocking forever. This mirrors the fatal-error handling xen-netback uses (xenvif_fatal_tx_err()). The pvcalls frontend currently trusts its backend, so this is not a classic-Xen security issue, but it matters for hardening PV frontends against malicious backends (confidential and disaggregated deployments).
Reported and fixed by us; matched against the published Linux CNA advisory record.
- CVE-2026-72430 unscored
net/sched: act_ct: fix nf_connlabels leak on two error paths
Linux kernel - Linux kernel (net/sched/act_ct.c)
net/sched: act_ct: fix nf_connlabels leak on two error paths tcf_ct_fill_params() calls nf_connlabels_get() (setting put_labels) when TCA_CT_LABELS is present, but two later error sites use a bare return instead of "goto err", skipping the err: nf_connlabels_put() cleanup. They also precede the "p->put_labels = put_labels" assignment, so the tcf_ct_params_free() fallback does not release the count either. Each failed RTM_NEWACTION on these paths leaks one nf_connlabels reference: net->ct.labels_used is incremented and never released. The action is reachable with CAP_NET_ADMIN over the netns, i.e. from an unprivileged user namespace on default-userns kernels. Impact: an unprivileged user with CAP_NET_ADMIN over a network namespace (e.g. via user namespaces) leaks one nf_connlabels reference per failed RTM_NEWACTION on the two error paths; net->ct.labels_used is never released. The err: label is safe to reach from both sites: p->tmpl is still NULL there (kzalloc'd, not yet assigned) and nf_ct_put(NULL) is a no-op, so no inline release is needed.
Reported and fixed by us; matched against the published Linux CNA advisory record.
- CVE-2026-72445 unscored
ALSA: usb-audio: qcom: clear opened when stream enable fails
Linux kernel - Linux kernel (sound/usb/qcom/qc_audio_offload.c)
ALSA: usb-audio: qcom: clear opened when stream enable fails On enable, subs->opened is set before the service_interval is validated; an invalid interval jumps to the response label without clearing it, so the substream is wedged at -EBUSY until a disable or disconnect. Clear subs->opened on the enable error path.
Reported and fixed by us; matched against the published Linux CNA advisory record.
- CVE-2026-72446 unscored
ALSA: usb-audio: qcom: reject stream disable with no active interface
Linux kernel - Linux kernel (sound/usb/qcom/qc_audio_offload.c)
ALSA: usb-audio: qcom: reject stream disable with no active interface handle_uaudio_stream_req() resolves an interface index with info_idx_from_ifnum(), which returns -EINVAL when no interface matches. The enable branch and the response: cleanup label both guard against a negative index, but the disable branch does not: it forms info = &uadev[pcm_card_num].info[info_idx] and dereferences it. uadev[].info is a pointer allocated only when a stream is first enabled, so a negative info_idx on the disable path is unsafe in two ways: - If the card was never enabled, .info is NULL and &info[-EINVAL] is a wild pointer; reading info->data_ep_pipe faults (kernel oops). - If the card was enabled at least once (.info allocated) and the disable names an interface that does not match, &info[-EINVAL] points before the allocation; info->data_ep_pipe / info->sync_ep_pipe are an out-of-bounds slab read and, when non-zero, an out-of-bounds 4-byte write (both pipe fields are cleared to 0). That is memory corruption, not just a NULL dereference. The request is reachable from unprivileged local userspace over AF_QIPCRTR. Reject a disable request with no resolved interface, matching the guard the enable path already has.
Reported and fixed by us; matched against the published Linux CNA advisory record.
- CVE-2026-74281 unscored
tipc: reject inverted service ranges from peer bindings
Linux kernel - Linux kernel (net/tipc/name_distr.c)
tipc: reject inverted service ranges from peer bindings tipc_update_nametbl() inserts a binding advertised by a peer node using the lower and upper service-range bounds taken directly from the wire, without checking that lower <= upper. The local bind path validates the ordering (tipc_uaddr_valid()), but the name-distribution path does not. A binding with lower > upper is inserted at the far end of the service-range rbtree (keyed on lower) where no lookup or withdrawal can ever match it (service_range_foreach_match() requires sr->lower <= end). The publication, its service_range node and the augmented rbtree entry are then leaked for the lifetime of the namespace, and there is no per-peer cap equivalent to TIPC_MAX_PUBL on locally created bindings. Reject inverted ranges in the network path as well. A peer node can otherwise leak unbounded binding-table memory by sending PUBLICATION items with lower > upper.
Reported and fixed by us; matched against the published Linux CNA advisory record.
- CVE-2026-74282 unscored
tipc: prevent snt_unacked underflow on CONN_ACK
Linux kernel - Linux kernel (net/tipc/socket.c)
tipc: prevent snt_unacked underflow on CONN_ACK tipc_sk_conn_proto_rcv() subtracts the peer-supplied connection ack count from the unsigned 16-bit send counter snt_unacked without checking that it does not exceed the number of messages actually outstanding: tsk->snt_unacked -= msg_conn_ack(hdr); msg_conn_ack() is read straight from a received CONN_MANAGER/CONN_ACK message. If the ack count is larger than snt_unacked, the subtraction wraps to a near-maximum value, leaving tsk_conn_cong() permanently true and starving the connection of further transmits. Validate the ACK count at the start of the CONN_ACK block and drop the message if it acknowledges more messages than are outstanding. A peer (or, for a local connection, the connected peer socket) can otherwise wedge a TIPC connection's send side by sending an oversized connection ack.
Reported and fixed by us; matched against the published Linux CNA advisory record.
- CVE-2026-74283 unscored
tipc: require net admin for TIPCv2 netlink mutators
Linux kernel - Linux kernel (net/tipc/netlink.c)
tipc: require net admin for TIPCv2 netlink mutators TIPCv2 registers mutating generic-netlink operations without admin permission flags. Generic netlink only checks CAP_NET_ADMIN when an operation sets GENL_ADMIN_PERM or GENL_UNS_ADMIN_PERM, so a local unprivileged process can currently change TIPC state through commands such as TIPC_NL_NET_SET, TIPC_NL_KEY_SET, TIPC_NL_KEY_FLUSH, and bearer enable/disable. The legacy TIPC netlink API already checks netlink_net_capable(..., CAP_NET_ADMIN) for administrative commands. Give the TIPCv2 mutators the equivalent generic-netlink gate. Use GENL_UNS_ADMIN_PERM, which maps to the same namespace-aware CAP_NET_ADMIN check that netlink_net_capable() performs, so the behaviour matches the legacy path and keeps working for CAP_NET_ADMIN holders in a non-initial user namespace (containers). A QEMU/KASAN repro run as uid/gid 65534 with zero effective capabilities previously succeeded in changing the network id and node identity, setting and flushing key material, and enabling/disabling a UDP bearer. With this patch applied the same operations fail with -EPERM.
Reported and fixed by us; matched against the published Linux CNA advisory record.
- CVE-2026-74439 unscored
iommu/vt-d: Clear Present bit before tearing down scalable-mode context entry
Linux kernel - Linux kernel (drivers/iommu/intel/pasid.c)
iommu/vt-d: Clear Present bit before tearing down scalable-mode context entry device_pasid_table_teardown() zeroes the 128-bit scalable-mode context entry with context_clear_entry() while the Present bit is still set. This creates a window where the hardware can fetch a torn entry, with some fields already zeroed while Present is still set, leading to unpredictable behavior or spurious faults. The context-cache invalidation is issued only after the entry has been zeroed, and intel_pasid_free_table() then frees the PASID directory pages, so the IOMMU can keep walking a stale Present=1 entry that points at freed memory. While x86 provides strong write ordering, the compiler may reorder the two 64-bit writes to the entry, and the hardware fetch is not guaranteed to be atomic with respect to multiple CPU writes. Commit c1e4f1dccbe9d ("iommu/vt-d: Clear Present bit before tearing down context entry") fixed this exact pattern in domain_context_clear_one() and the copied-context path, but device_pasid_table_teardown() was not converted. Align it with the "Guidance to Software for Invalidations" in the VT-d spec, Section 6.5.3.3, using the same ownership handshake as the sibling fix: clear only the Present bit, flush it to the IOMMU, perform the context-cache invalidation, and only then zero the rest of the entry.
Reported and fixed by us; matched against the published Linux CNA advisory record.
- CVE-2026-63880 unscored
drm/amdgpu: fix lock leak on ENOMEM in AMDGPU_GEM_OP_GET_MAPPING_INFO
Linux kernel - gpu driver (drivers/gpu)
The AMDGPU_GEM_OP_GET_MAPPING_INFO branch of amdgpu_gem_op_ioctl() holds three cleanup-tracked resources before calling kvcalloc(): the drm_gem_object reference from drm_gem_object_lookup(), the drm_exec lock on the looked-up GEM via drm_exec_lock_obj(), and the drm_exec lock on the per-process VM root page directory via amdgpu_vm_lock_pd(). All three are released by the out_exec label that every other error path in this function jumps to.
- CVE-2026-63895 unscored
usb: gadget: f_fs: copy only received bytes on short ep0 read
Linux kernel - usb driver (drivers/usb)
ffs_ep0_read() allocates its control-OUT data buffer with kmalloc() (not kzalloc) at the Length value from the Setup packet, then copies that full len to userspace regardless of how many bytes were actually received: data = kmalloc(len, GFP_KERNEL); ... ret = __ffs_ep0_queue_wait(ffs, data, len); if ((ret > 0) && (copy_to_user(buf, data, len))) ret = -EFAULT; __ffs_ep0_queue_wait() returns req->actual, which on a short control OUT transfer is strictly less than len.
- GStreamer-SA-2026-0057 unscored
GStreamer: out-of-bounds read in the RTP JPEG depayloader quantization-table handling (rtpjpegdepay)
GStreamer - gst-plugins-good (rtpjpegdepay) [CWE-125]
The rtpjpegdepay element in gst-plugins-good copies quantization-table data whose byte count is derived from the JPEG precision field, while the packet-supplied length field is only validated against the total RTP payload size. A crafted RTP/JPEG packet with a short payload and a precision value implying a larger table causes the depayloader to read past the end of the received buffer. Reproduced on the shipping gst-plugins-good 1.28.2 binary: a crafted packet (precision=3, length=4) pushed through the real rtpjpegdepay triggers an invalid read under valgrind, while a well-formed 256-byte-table control is clean. Any pipeline that depayloads RTP JPEG is reachable by a malicious RTP sender. Fixed in gst-plugins-good 1.28.5; the deprecated element is superseded by rtpjpegdepay2.
Reported privately to the GStreamer security team as a confidential GitLab work item with a reproduction on the shipping 1.28.2 binary and a proposed bounds check; fixed in gst-plugins-good 1.28.5. GStreamer publishes security advisories without CVE identifiers, so no CVE was assigned.
- GStreamer-SA-2026-0064 unscored
GStreamer: NULL pointer dereference in the WAV parser adtl chunk handling in streaming mode (wavparse)
GStreamer - gst-plugins-good (wavparse) [CWE-476]
In streaming (push) mode the wavparse element in gst-plugins-good maps a LIST/adtl chunk buffer using the attacker-declared chunk size without first verifying that enough data is available. When the buffer is short the map returns NULL, which is then dereferenced during adtl chunk parsing, crashing the pipeline. Reproduced on the shipping gst-plugins-good 1.28.2 binary with a 48-byte crafted WAV pushed through appsrc ! wavparse ! fakesink, producing a SIGSEGV (invalid read of size 4 inside libgstwavparse). The bug is remote and unauthenticated wherever a WAV is auto-fetched, for example an HTTP or RTSP source feeding wavparse. It is distinct from CVE-2026-1940 (GST-SA-2026-0001), which hardened out-of-bounds arithmetic inside the adtl parser but did not add the availability guard on the streaming caller. Fixed in gst-plugins-good 1.28.5.
Reported privately to the GStreamer security team as a confidential GitLab work item with a reproduction on the shipping 1.28.2 binary and a proposed availability guard; fixed in gst-plugins-good 1.28.5. GStreamer publishes security advisories without CVE identifiers, so no CVE was assigned.
- n2n-register-super-token-oob-write unscored
n2n: REGISTER_SUPER token/count decoded into fixed buffers without bounds (stack OOB write)
ntop - n2n (edge wire decoder) [CWE-787, CWE-121, CWE-120]
The n2n edge decoded a supernode REGISTER_SUPER response's auth token_size and num_sn fields into fixed destination buffers without bounding them against the destination sizes, a stack out-of-bounds write drivable by a malicious or spoofed supernode. Fixed in n2n (PR #1243 / commit 854fbbe01bbf, 'wire: bound decoded auth.token_size and num_sn to destination sizes').
Fix authored by us (merged PR #1243). No CVE assigned.
- gpac-mp4box-stack-oob-3623-3626 unscored
GPAC / MP4Box: stack buffer overflows in meta-item, MPD, SVG-SAF and XMT parsing
GPAC - GPAC / MP4Box (isomedia, MPD, SVG, XMT) [CWE-787, CWE-121]
Several GPAC parsers copied attacker-controlled strings into fixed stack buffers (for example szPath[1024]) without bounds checks: MP4/HEIF meta item names (gf_isom_extract_meta_item), MPD format width, SVG SAF stream ids, and XMT URLs. Each is a stack buffer overflow on a crafted input. Reported as GitHub issues #3623-#3626 and fixed upstream (commit ba6482cf). GPAC is not a CNA, so no CVE is issued.
Reported by us (issues #3623-#3626, filed as mjbommar); fixed by the maintainer. No CVE (GPAC is not a CNA).
- MC-308703 unscored
Minecraft: Java Edition: chunk-batch acknowledgement counter has no lower bound, letting a joined client defeat server send-side flow control (DoS)
Mojang (Microsoft) - Minecraft: Java Edition server (net.minecraft.server.network.PlayerChunkSender) [CWE-400, CWE-770]
Since 1.20.2 the Java Edition server paces terrain to each client with a batching flow-control loop: PlayerChunkSender sends a chunk batch, increments unacknowledgedBatches, and keeps sending only while unacknowledgedBatches < maxUnacknowledgedBatches, decrementing when the client sends ServerboundChunkBatchReceived. The decrement in onChunkBatchReceivedByClient had no lower bound and did not check that a batch was actually outstanding, so a joined client that sends more acknowledgements than batches it received drives the counter negative and holds the send-gate permanently open. The server then streams chunk data with no backpressure: encoded bytes accumulate in Netty's off-heap outbound buffers (growing past -Xmx without a Java heap error) and the main thread burns its per-tick budget on a client that is not draining, stalling the whole server. Reachable by any authenticated player with an unmodified client sending a stock packet more often than the protocol expects; no permissions required. Reproduced live on stock 26.1.2 and Fabric with a controlled A/B isolating the counter from ordinary connection load. Paper/Spigot mitigate via player-max-chunk-send-rate; vanilla and Fabric had no such cap.
Reported privately to Mojang as Mojira security ticket MC-308703 on 2026-06-09 with a live reproduction and the counter-floor fix; shipped in Minecraft: Java Edition 26.2 on 2026-06-16. Mojang does not assign CVEs for server-side security fixes and does not describe them in patch notes, so there is no CVE, advisory, or changelog entry; the write-up below is the public record.
no disclosures match these filters.