Описание
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: 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: udp: fix potential use-after-free in tunnel segmentation (CVE-2026-74705)
-
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: fix stale s2s_cp_stateids IDR entry for async COPY (CVE-2026-89676)
-
kernel: nfsd: revoke copy-notify stateids before dropping their reference (CVE-2026-89663)
-
kernel: nfsd: fix UAF in async copy cancel and shutdown (CVE-2026-89675)
Bug Fix(es) and Enhancement(s):
-
mlxbf_bootctl: driver update to Linux v6.16 [Nvidia 10.2.z FEAT] (JIRA:Rocky Linux-212709)
-
[GNR-D] missing interfaces tspll_cfg [rhel-10.2] (JIRA:Rocky Linux-273805)
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 10
Ссылки на источники
Исправления
- Red Hat - 2436771
- Red Hat - 2497032
- Red Hat - 2499742
- Red Hat - 2502222
- Red Hat - 2502411
- Red Hat - 2502476
- Red Hat - 2502593
- Red Hat - 2516705
- Red Hat - 2521498
- Red Hat - 2524431
- Red Hat - 2532103
- Red Hat - 2532111
- Red Hat - 2532218
- Red Hat - 2532219
- Red Hat - 2532231
- Red Hat - 2532272
Связанные уязвимости
ELSA-2026-77690: kernel security, bug fix, and enhancement update (IMPORTANT)
ELSA-2026-77689: kernel security, bug fix, and enhancement update (IMPORTANT)
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...