Total
398612 CVE
| CVE | Vendors | Products | Updated | CVSS v2 | CVSS v3 |
|---|---|---|---|---|---|
| CVE-2026-72259 | 2026-08-17 | N/A | N/A | ||
| In the Linux kernel, the following vulnerability has been resolved: ASoC: mediatek: mt8192: Release reserved memory on cleanup The MT8192 AFE probe calls of_reserved_mem_device_init() and falls back to preallocated buffers when no reserved memory region is available. When the reserved memory assignment succeeds, however, the driver never releases it. Register a devm cleanup action after a successful reserved-memory assignment so the assignment is released on probe failure and driver unbind. | |||||
| CVE-2026-72258 | 2026-08-17 | N/A | N/A | ||
| In the Linux kernel, the following vulnerability has been resolved: ASoC: mediatek: mt8183: Release reserved memory on cleanup The MT8183 AFE probe can assign reserved memory with of_reserved_mem_device_init(), but the assignment is never released on driver removal or later probe failures. Register a devm cleanup action so the reserved memory assignment is released consistently, matching newer Mediatek AFE drivers. | |||||
| CVE-2026-72257 | 2026-08-17 | N/A | N/A | ||
| In the Linux kernel, the following vulnerability has been resolved: ASoC: qcom: q6apm: fix NULL pointer dereference in graph_callback When q6apm_free_fragments() is called it frees rx_data.buf/tx_data.buf and sets them to NULL under graph->lock. A late DSP buffer-done response can race with this: graph_callback() passes the !graph->ar_graph guard (not yet NULL), acquires the lock, but then dereferences a now-NULL buf pointer to read buf[token].phys, crashing at virtual address 0x10. Add a NULL check for buf inside the mutex-protected section in both the write-done (DATA_CMD_RSP_WR_SH_MEM_EP_DATA_BUFFER_DONE_V2) and read-done (DATA_CMD_RSP_RD_SH_MEM_EP_DATA_BUFFER_V2) handlers and bail out cleanly if buffers have already been freed. This problem is only shown up recently while apr bus was updated to process the commands per service rather from single global queue. | |||||
| CVE-2026-72256 | 2026-08-17 | N/A | N/A | ||
| In the Linux kernel, the following vulnerability has been resolved: netfilter: xt_cluster: reject template conntracks in hash match xt_cluster_mt() treats any non-NULL nf_ct_get() result as a fully initialized conntrack and passes it to xt_cluster_hash(). This causes a state confusion bug when the raw table CT target attaches a template conntrack to skb->_nfct before normal conntrack processing. Templates carry IPS_TEMPLATE status but do not have a valid tuple for hashing yet, so xt_cluster_hash() can hit its WARN_ON() path on the zeroed l3num field. Reject template conntracks before hashing them. This matches existing netfilter handling for template objects and avoids hashing incomplete conntrack state. | |||||
| CVE-2026-72254 | 2026-08-17 | N/A | 7.5 HIGH | ||
| In the Linux kernel, the following vulnerability has been resolved: netfilter: nft_fib: reject fib expression on the netdev egress hook A fib expression in a netdev egress base chain dereferences nft_in(pkt), NULL on the transmit path, causing a NULL pointer dereference at eval. nft_fib_validate() masks the hook with NF_INET_* values, but netdev hook numbers are a separate enum that aliases them (NF_NETDEV_EGRESS == NF_INET_LOCAL_IN), so an egress chain passes validation and then faults. Add nft_fib_netdev_validate() that limits each result/flag to the netdev hook where the device it reads exists: the input-device cases (OIF, OIFNAME, ADDRTYPE with F_IIF) to ingress, the output-device case (ADDRTYPE with F_OIF) to egress, ADDRTYPE with no device flag to both. Also restrict nft_fib_validate() to NFPROTO_IPV4/IPV6/INET so its NF_INET_* masks are not applied to another family's hooks. | |||||
| CVE-2026-72251 | 2026-08-17 | N/A | 9.8 CRITICAL | ||
| In the Linux kernel, the following vulnerability has been resolved: netfilter: nf_nat_sip: reload possible stale data pointer quoting sashiko: ------------------------------------------------------------------------ [..] noticed a potential memory bug and header corruption involving the SIP NAT helper. In net/netfilter/nf_nat_sip.c:nf_nat_sip(): if (skb_ensure_writable(skb, skb->len)) { nf_ct_helper_log(skb, ct, "cannot mangle packet"); return NF_DROP; } uh = (void *)skb->data + protoff; uh->dest = ct_sip_info->forced_dport; if (!nf_nat_mangle_udp_packet(skb, ct, ctinfo, protoff, 0, 0, NULL, 0)) { If a cloned or fragmented SKB is reallocated by skb_ensure_writable(), the old data buffer is freed. However, nf_nat_sip() fails to update *dptr to point to the new buffer. It also appears to use nf_nat_mangle_udp_packet() on what could be a TCP packet, which would overwrite the sequence number with a checksum update. ------------------------------------------------------------------------ nf_conntrack_sip linerizes skbs, hence no fragmented skb can be seen. But clones are possible, so rebuild dptr. Disable nf_nat_mangle_udp_packet() branch for TCP streams. It doesn't look like this can ever happen, else we should have received bug reports about this, so just check the conntrack is UDP and drop otherwise. The calling conntrack_sip set ->forced_dport for SIP_HDR_VIA_UDP messages, so I don't think this is ever expected to be true for a TCP stream. | |||||
| CVE-2026-72250 | 2026-08-17 | N/A | 7.8 HIGH | ||
| In the Linux kernel, the following vulnerability has been resolved: netfilter: nf_conntrack_reasm: guard mac_header adjustment after IPv6 defrag nf_ct_frag6_reasm() slides the packet head forward to drop the IPv6 fragment header and then unconditionally advances skb->mac_header: skb->mac_header += sizeof(struct frag_hdr); On the NF_INET_LOCAL_OUT defrag path the skb has no link-layer header yet, so skb->mac_header is still the "not set" sentinel (u16)~0U. Adding sizeof(struct frag_hdr) wraps it to a small value (0xffff + 8 == 7), after which skb_mac_header_was_set() wrongly reports a MAC header is present and skb_mac_header() points into the headroom. The reassembler has done this unconditional add since it was introduced; it was harmless while mac_header was a bare pointer, but wrong once mac_header became a u16 offset whose unset state is the ~0U sentinel tested by skb_mac_header_was_set(). The sibling net/ipv6/reassembly.c does the same relocation and does guard the adjustment; mirror the guard here. | |||||
| CVE-2026-72249 | 2026-08-17 | N/A | 9.8 CRITICAL | ||
| In the Linux kernel, the following vulnerability has been resolved: netfilter: flowtable: use dst in this direction when pushing IPIP header When pushing the IPIP header, the route of the other direction is used to calculate the headroom, use the route in this direction. Accessing the other tuple to set the IP source and destination is fine because this tuple does not provide such information to avoid storing redundant information. However, this tuple already provides the dst for this direction, this went unnoticed because this bug affects headroom and iph->frag_off only at this stage. | |||||
| CVE-2026-72248 | 2026-08-17 | N/A | 9.8 CRITICAL | ||
| In the Linux kernel, the following vulnerability has been resolved: netfilter: flowtable: support IPIP tunnel with direct xmit The combination of IPIP tunnel with direct xmit, eg. bridge device, breaks because no dst_entry is provided to check the skb headroom and to set the iph->frag_off field. This leads to invalid dst usage and can trigger a crash in the tunnel transmit path. Fix this by moving dst_cache and dst_cookie out of the runtime union so that they can be shared by neighbour, xfrm, and direct tunnel flows. For FLOW_OFFLOAD_XMIT_DIRECT tuples carrying tunnel metadata, preserve route state in these shared fields and release it through the common dst release path. Since dst_entry is now available to the three supported xmit modes and dst_release() already deals with NULL dst, remove the xmit type check in nft_flow_dst_release(). Moreover, skip the check if the dst entry is NULL in nf_flow_dst_check() which is now the case for the direct xmit case. Based on patch from Rein Wei <n05ec@lzu.edu.cn>. | |||||
| CVE-2026-72247 | 2026-08-17 | N/A | 7.5 HIGH | ||
| In the Linux kernel, the following vulnerability has been resolved: netfilter: nf_conncount: fix zone comparison in tuple dedup The "already exists" dedup logic in __nf_conncount_add() decides whether a connection has already been counted and can be skipped instead of incrementing the connlimit count. It compares the conntrack zone of a list entry with the zone of the connection being added using nf_ct_zone_id() and nf_ct_zone_equal(), passing conn->zone.dir or zone->dir as the direction argument. Those helpers take enum ip_conntrack_dir values: IP_CT_DIR_ORIGINAL is 0 and IP_CT_DIR_REPLY is 1. However, zone->dir is a u8 bitmask: NF_CT_ZONE_DIR_ORIG is 1, NF_CT_ZONE_DIR_REPL is 2 and NF_CT_DEFAULT_ZONE_DIR is 3. Passing that bitmask as the enum direction shifts the meaning of every non-zero value. An ORIG-only zone passes 1 and is tested as REPLY, while REPL-only and default zones pass 2 or 3 and test bits beyond the valid direction range. In those cases nf_ct_zone_id() can fall back to NF_CT_DEFAULT_ZONE_ID instead of using the real zone id, so different zones can be treated as equal and dedup collapses to tuple equality alone. nf_conncount stores and compares the original-direction tuple for a connection. If an skb already has an attached conntrack entry, get_ct_or_tuple_from_skb() explicitly copies ct->tuplehash[IP_CT_DIR_ORIGINAL].tuple, regardless of the packet's ctinfo. Therefore the zone comparison in the tuple dedup path must use IP_CT_DIR_ORIGINAL as well; the zone direction bitmask describes where a zone id applies, not which direction this conncount tuple represents. Fix the two dedup comparisons by passing IP_CT_DIR_ORIGINAL directly. Do not special-case NF_CT_DEFAULT_ZONE_DIR and do not compare raw zone ids: using the existing helpers with IP_CT_DIR_ORIGINAL preserves the direction-aware NF_CT_DEFAULT_ZONE_ID fallback. A default bidirectional zone contains the ORIG bit, so it naturally returns the real zone id; reply-only zones continue to fall back for original-direction tuple comparisons. | |||||
| CVE-2026-72246 | 2026-08-17 | N/A | N/A | ||
| Rejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority. | |||||
| CVE-2026-72245 | 2026-08-17 | N/A | N/A | ||
| In the Linux kernel, the following vulnerability has been resolved: gpu: host1x: Fix device reference leak in host1x_device_parse_dt() error path After device_initialize(), the embedded struct device in struct host1x_device should be released through the device core with put_device(). In host1x_device_add(), if host1x_device_parse_dt() fails, the current error path frees the object directly with kfree(device). That bypasses the normal device lifetime handling and leaks the reference held on the embedded struct device. The issue was identified by a static analysis tool I developed and confirmed by manual review. Fix this by using put_device() in the host1x_device_parse_dt() failure path. | |||||
| CVE-2026-72244 | 2026-08-17 | N/A | 7.8 HIGH | ||
| In the Linux kernel, the following vulnerability has been resolved: gpu/buddy: bail out of try_harder when alignment cannot be honoured The try_harder contiguous fallback could return a range whose start offset did not match the caller's min_block_size. When a candidate's start is misaligned, realign it: free the misaligned run and reallocate exactly @size at the next lower min_block_size boundary. This keeps the returned size unchanged with no surplus to trim, and rejects the request only when no aligned candidate fits. v2: align misaligned candidates down to min_block_size instead of bailing out, for both the RHS and LHS paths (Matthew). | |||||
| CVE-2026-72241 | 2026-08-17 | N/A | N/A | ||
| In the Linux kernel, the following vulnerability has been resolved: leds: uleds: Fix potential buffer overread The name string supplied by userspace is not guaranteed to be null-terminated, so using strchr() on it might result in a buffer overread. The same thing will happen when said string is used by the LED class device. Fix this by using strnchr() instead and explicitly check that the name string is properly null-terminated. | |||||
| CVE-2026-72240 | 2026-08-17 | N/A | N/A | ||
| In the Linux kernel, the following vulnerability has been resolved: mfd: sm501: Fix reference leak on failed device registration When platform_device_register() fails in sm501_register_device(), the embedded struct device in pdev has already been initialized by device_initialize(), but the failure path only reports the error and returns without dropping the device reference for the current platform device: sm501_register_device() -> platform_device_register(pdev) -> device_initialize(&pdev->dev) -> setup_pdev_dma_masks(pdev) -> platform_device_add(pdev) This leads to a reference leak when platform_device_register() fails. Fix this by calling platform_device_put() before returning the error. The issue was identified by a static analysis tool I developed and confirmed by manual review. | |||||
| CVE-2026-72239 | 2026-08-17 | N/A | 9.3 CRITICAL | ||
| In the Linux kernel, the following vulnerability has been resolved: x86/virt/sev: Revert "Drop WBINVD before setting MSR_AMD64_SYSCFG_SNP_EN" Revert 99cf1fb58e68 ("x86/virt/sev: Drop WBINVD before setting MSR_AMD64_SYSCFG_SNP_EN"). Section 8.8 of the SNP spec says: Before invoking SNP_INIT_EX with INIT_RMP set to 1, software must ensure that no CPUs contain dirty cache lines for the memory containing the RMP. Cachelines can be moved from cache to cache in a dirty state. The wbinvd_on_all_cpus() before SNP_INIT_EX flushes the caches for each CPU, but if the IPIs for WBINVD race with this dirty cacheline movement, it is possible that they may not get flushed, violating the firmware requirement. Doing wbinvd_on_all_cpus() before setting SNPEn is safer since the RMP table is not yet in use. [ Heroically bisected by Srikanth. ] [ bp: Massage commit message. ] | |||||
| CVE-2026-72238 | 2026-08-17 | N/A | N/A | ||
| In the Linux kernel, the following vulnerability has been resolved: x86/boot: Validate console=uart8250 baud rate to fix early boot hang When the baud rate is empty, 0, invalid, or overflows to 0 when stored as an int, the system will hang during early boot because of a division by zero in early_serial_init(). Fall back to DEFAULT_BAUD when the resulting baud rate is 0 to prevent an early system hang. | |||||
| CVE-2026-72235 | 2026-08-17 | N/A | 8.8 HIGH | ||
| In the Linux kernel, the following vulnerability has been resolved: batman-adv: retrieve ethhdr after potential skb realloc on RX pskb_may_pull() in batadv_interface_rx() could reallocate the buffer behind the skb. Variables which were pointing to the old buffer need to be reassigned to avoid an use-after-free. This was done correctly for the VLAN header but missed for the ethernet header which is later used for the TT and AP isolation handling. | |||||
| CVE-2026-72234 | 2026-08-17 | N/A | 9.8 CRITICAL | ||
| In the Linux kernel, the following vulnerability has been resolved: batman-adv: access unicast_ttvn skb->data only after skb realloc The pskb_may_pull() called by batadv_get_vid() could reallocate the buffer behind the skb. Variables which were pointing to the old buffer need to be reassigned to avoid an use-after-free. This was done correctly for the ethernet header but missed for the unicast_packet pointer. | |||||
| CVE-2026-72233 | 2026-08-17 | N/A | 8.8 HIGH | ||
| In the Linux kernel, the following vulnerability has been resolved: batman-adv: bla: reacquire gw address after skb realloc The pskb_may_pull() called by batadv_bla_is_backbone_gw() could reallocate the buffer behind the skb. Variables which were pointing to the old buffer need to be reassigned to avoid an use-after-free. | |||||