Threats Tagged 'cve-2026-46303'

The kernel packages contain the Linux kernel, the core of any Linux operating system. Security Fix(es): * kernel: ksm: use range-walk function to jump over holes in scan_get_next_rmap_item (CVE-2025-68211) * kernel: ip6_tunnel: use skb_vlan_inet_prepare() in __ip6_tnl_rcv() (CVE-2026-23003) * kernel: netfilter: nft_set_pipapo_avx2: don't return non-matching entry on expiry (CVE-2026-43114) * kernel: sctp: purge outqueue on stale COOKIE-ECHO handling (CVE-2026-52924) * kernel: netfilter: xt_policy: fix strict mode inbound policy matching (CVE-2026-52920) * kernel: zram: fix use-after-free in zram_bvec_write_partial() (CVE-2026-53185) * kernel: netfilter: require Ethernet MAC header before using eth_hdr() (CVE-2026-53131) * kernel: netfilter: conntrack_irc: fix possible out-of-bounds read (CVE-2026-53268) * kernel: i2c: stub: Reject I2C block transfers with invalid length (CVE-2026-64191) * kernel: netfilter: ipset: fix race between dump and ip_set_list resize (CVE-2026-64189) * kernel: Input: synaptics-rmi4 - bound the F3A keymap to the GPIO count (CVE-2026-64277) * kernel: Input: synaptics-rmi4 - bound the F30 keymap to the GPIO/LED count (CVE-2026-64276) * kernel: net: ipv6: use-after-free in fib6_rule_suppress due to stale res->rt6 pointer (CVE-2026-74581) Bug Fix(es) and Enhancement(s): * [RHEL-9.8.z] Intel CWF: CPU is unable to obtain cstate1 on idle system (JIRA:RHEL-166118) * ss core dumped when there is an SCTP session [rhel-9.8.z] (JIRA:RHEL-212398) * [IBM 9.9 FEAT] zcrypt driver overwrite function - kernel part [rhel-9.8.z] (JIRA:RHEL-245333) For more details about the security issue(s), including the impact, a CVSS score, acknowledgments, and other related information, refer to the CVE page(s) listed in the References section.

CVE-2025-71315 is a vulnerability affecting the Linux kernel, which is the core component of the Linux operating system. The vulnerability involves multiple issues that can lead to denial of service conditions. It impacts various Linux distributions including Amazon Linux 2 and Debian. No CVSS score is provided for this vulnerability.

In the Linux kernel, the following vulnerability has been resolved: isofs: validate Rock Ridge CE continuation extent against volume size rock_continue() reads rs->cont_extent verbatim from the Rock Ridge CE record and passes it to sb_bread() without checking that the block number is within the mounted ISO 9660 volume. commit e595447e177b ("[PATCH] rock.c: handle corrupted directories") added cont_offset and cont_size rejection for the CE continuation but did not validate the extent block number itself. commit f54e18f1b831 ("isofs: Fix infinite looping over CE entries") later capped the CE chain length at RR_MAX_CE_ENTRIES = 32 but again left the block number unchecked. With a crafted ISO mounted via udisks2 (desktop optical auto-mount) or via CAP_SYS_ADMIN mount, rs->cont_extent can therefore point at an out-of-range block or at blocks belonging to an adjacent filesystem on the same block device. sb_bread() on an out-of-range block returns NULL cleanly via the block layer EIO path, so there is no memory-safety violation. For in-range reads of adjacent- filesystem data, the CE buffer is parsed as Rock Ridge records and only the text of SL sub-records reaches userspace through readlink(), which makes the info-leak channel narrow and difficult to exploit; still, rejecting the malformed CE outright matches the rejection shape already present in the same function for cont_offset and cont_size. Add an ISOFS_SB(sb)->s_nzones bounds check to rock_continue() next to the existing offset/size rejection, printing the same corrupted-directory-entry notice.

To determine the support lifecycle for your software, see the Microsoft Support Lifecycle: https://support.microsoft.com/lifecycle