Описание
Important: kernel security, bug fix, and enhancement update
The kernel packages contain the Linux kernel, the core of any Linux operating system.
Security Fix(es):
-
kernel: ipvlan: Make the addrs_lock be per port (CVE-2026-23103)
-
kernel: KVM: SEV: Require in-GHCB scratch area if GHCB v2+ is in use (CVE-2026-53360)
-
kernel: vsock/virtio: fix zerocopy completion for multi-skb sends (CVE-2026-53365)
-
kernel: NFSD: Fix SECINFO_NO_NAME decode error cleanup (CVE-2026-53398)
-
kernel: vsock/virtio: bind uarg before filling zerocopy skb (CVE-2026-63970)
-
kernel: igc: set tx buffer type for SMD frames (CVE-2026-64035)
-
kernel: idpf: fix read_dev_clk_lock spinlock init in idpf_ptp_init() (CVE-2026-64162)
-
kernel: vsock/vmci: fix UAF when peer resets connection during handshake (CVE-2026-64115)
-
kernel: SUNRPC: pin upper rpc_clnt across the TLS connect_worker (CVE-2026-72317)
-
kernel: ipvlan: inherit needed_headroom and needed_tailroom from phy_dev (CVE-2026-74744)
-
kernel: nfsd: defer vfree of compound ops to fix rpc_status UAF (CVE-2026-89690)
-
kernel: nfsd: initialize copy-notify stateid before publishing it (CVE-2026-89669)
-
kernel: svcrdma: Reject inline replies that overflow the pull-up buffer (CVE-2026-89530)
-
kernel: nfsd: revoke copy-notify stateids before dropping their reference (CVE-2026-89663)
Bug Fix(es) and Enhancement(s):
-
"iavf: refactor iavf_clean_rx_irq to support legacy and flex descriptors" broke rx-vlan-offload on rhel-9.7 [rhel-9.8.z] (JIRA:Rocky Linux-169480)
-
[GNR-D] missing interfaces tspll_cfg (JIRA:Rocky Linux-183201)
-
Rocky Linux9.8z KVM guest panicked in vmmouse driver (JIRA:Rocky Linux-186577)
-
Add Epson RX8111 support to Rocky Linux9.9 [rhel-9.8.z] (JIRA:Rocky Linux-212014)
-
RT scheduler livelock: migrate-disabled task at pushable-list head causes repeated RT push/stopper retries, starving a critical RT task (remaining issue after CVE-2026-45919 fix in 94894c9c477e) [rhel-9.8.z] (JIRA:Rocky Linux-256279)
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.
Затронутые продукты
Rocky Linux 9
Ссылки на источники
Исправления
- Red Hat - 2436771
- Red Hat - 2497032
- Red Hat - 2499742
- Red Hat - 2502222
- Red Hat - 2502411
- Red Hat - 2502476
- Red Hat - 2502521
- Red Hat - 2502593
- Red Hat - 2516705
- Red Hat - 2524431
- Red Hat - 2532103
- Red Hat - 2532111
- Red Hat - 2532218
- Red Hat - 2532231
Связанные уязвимости
In the Linux kernel, the following vulnerability has been resolved: ipvlan: Make the addrs_lock be per port Make the addrs_lock be per port, not per ipvlan dev. Initial code seems to be written in the assumption, that any address change must occur under RTNL. But it is not so for the case of IPv6. So 1) Introduce per-port addrs_lock. 2) It was needed to fix places where it was forgotten to take lock (ipvlan_open/ipvlan_close) This appears to be a very minor problem though. Since it's highly unlikely that ipvlan_add_addr() will be called on 2 CPU simultaneously. But nevertheless, this could cause: 1) False-negative of ipvlan_addr_busy(): one interface iterated through all port->ipvlans + ipvlan->addrs under some ipvlan spinlock, and another added IP under its own lock. Though this is only possible for IPv6, since looks like only ipvlan_addr6_event() can be called without rtnl_lock. 2) Race since ipvlan_ht_addr_add(port) is called under different ipvlan->addrs_lock locks This should n...
In the Linux kernel, the following vulnerability has been resolved: ipvlan: Make the addrs_lock be per port Make the addrs_lock be per port, not per ipvlan dev. Initial code seems to be written in the assumption, that any address change must occur under RTNL. But it is not so for the case of IPv6. So 1) Introduce per-port addrs_lock. 2) It was needed to fix places where it was forgotten to take lock (ipvlan_open/ipvlan_close) This appears to be a very minor problem though. Since it's highly unlikely that ipvlan_add_addr() will be called on 2 CPU simultaneously. But nevertheless, this could cause: 1) False-negative of ipvlan_addr_busy(): one interface iterated through all port->ipvlans + ipvlan->addrs under some ipvlan spinlock, and another added IP under its own lock. Though this is only possible for IPv6, since looks like only ipvlan_addr6_event() can be called without rtnl_lock. 2) Race since ipvlan_ht_addr_add(port) is called under different ipvlan->addrs_lock locks This should n...
In the Linux kernel, the following vulnerability has been resolved: ipvlan: Make the addrs_lock be per port Make the addrs_lock be per port, not per ipvlan dev. Initial code seems to be written in the assumption, that any address change must occur under RTNL. But it is not so for the case of IPv6. So 1) Introduce per-port addrs_lock. 2) It was needed to fix places where it was forgotten to take lock (ipvlan_open/ipvlan_close) This appears to be a very minor problem though. Since it's highly unlikely that ipvlan_add_addr() will be called on 2 CPU simultaneously. But nevertheless, this could cause: 1) False-negative of ipvlan_addr_busy(): one interface iterated through all port->ipvlans + ipvlan->addrs under some ipvlan spinlock, and another added IP under its own lock. Though this is only possible for IPv6, since looks like only ipvlan_addr6_event() can be called without rtnl_lock. 2) Race since ipvlan_ht_addr_add(port) is called under different ipvlan->addrs_lock locks This sh
In the Linux kernel, the following vulnerability has been resolved: i ...