Описание
Important: kernel security 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: xfrm: hold dev ref until after transport_finish NF_HOOK (CVE-2026-31663)
-
kernel: netfilter: nf_conntrack_h323: fix OOB read in decode_choice() (CVE-2026-43233)
-
kernel: ipv6: prevent possible UaF in addrconf_permanent_addr() (CVE-2026-43339)
-
kernel: inet: RAW sockets using IPPROTO_RAW MUST drop incoming ICMP (CVE-2026-46266)
-
kernel: flow_dissector: do not dissect PPPoE PFC frames (CVE-2026-46306)
-
kernel: netfilter: xt_policy: fix strict mode inbound policy matching (CVE-2026-52920)
-
kernel: ppp: require CAP_NET_ADMIN in target netns for unattached ioctls (CVE-2026-53075)
-
kernel: ipv6: sit: reload inner IPv6 header after GSO offloads (CVE-2026-53228)
-
kernel: IB/isert: Reject login PDUs shorter than ISER_HEADERS_LEN (CVE-2026-53176)
-
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: xfrm: policy: fix use-after-free on inexact bin in xfrm_policy_bysel_ctx() (CVE-2026-53239)
-
kernel: ALSA: timer: Fix UAF at snd_timer_user_params() (CVE-2026-53192)
-
kernel: net: guard timestamp cmsgs to real error queue skbs (CVE-2026-53223)
-
kernel: ipv6: mcast: Fix use-after-free when processing MLD queries (CVE-2026-53275)
-
kernel: ipv4: free net->ipv4.sysctl_local_reserved_ports after unregister_net_sysctl_table() (CVE-2026-64002)
-
kernel: ip6: vti: Use ip6_tnl.net in vti6_siocdevprivate() (CVE-2026-63921)
-
kernel: xfrm: input: hold netns during deferred transport reinjection (CVE-2026-63919)
-
kernel: ip6: vti: Use ip6_tnl.net in vti6_changelink() (CVE-2026-63917)
-
kernel: Linux kernel SLIP: Out-of-bounds write due to race condition during MTU change (CVE-2026-68143)
-
kernel: xfrm: fix stale skb->prev after async crypto steals a GSO segment (CVE-2026-68426)
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 8
Связанные CVE
Ссылки на источники
Исправления
- Red Hat - 2436771
- Red Hat - 2461462
- Red Hat - 2467135
- Red Hat - 2468102
- Red Hat - 2484456
- Red Hat - 2486463
- Red Hat - 2492112
- Red Hat - 2492295
- Red Hat - 2492733
- Red Hat - 2492741
- Red Hat - 2492747
- Red Hat - 2492770
- Red Hat - 2492779
- Red Hat - 2492792
- Red Hat - 2492811
- Red Hat - 2492841
- Red Hat - 2502363
- Red Hat - 2502368
- Red Hat - 2502412
- Red Hat - 2502434
Связанные уязвимости
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 ...