Описание
Important: kernel security update
The kernel packages contain the Linux kernel, the core of any Linux operating system.
Security Fix(es):
-
kernel: net: gso: fix ownership in __udp_gso_segment (CVE-2025-21926)
-
kernel: vlan: enforce underlying device type (CVE-2025-21920)
-
kernel: xsk: fix an integer overflow in xp_create_and_assign_umem() (CVE-2025-21997)
-
kernel: net: fix geneve_opt length integer overflow (CVE-2025-22055)
-
kernel: ext4: fix OOB read when checking dotdot dir (CVE-2025-37785)
-
kernel: wifi: ath12k: Fix invalid data access in ath12k_dp_rx_h_undecap_nwifi (CVE-2025-37943)
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 - 2356587
- Red Hat - 2356639
- Red Hat - 2357143
- Red Hat - 2360300
- Red Hat - 2360921
- Red Hat - 2367748
Связанные уязвимости
In the Linux kernel, the following vulnerability has been resolved: vlan: enforce underlying device type Currently, VLAN devices can be created on top of non-ethernet devices. Besides the fact that it doesn't make much sense, this also causes a bug which leaks the address of a kernel function to usermode. When creating a VLAN device, we initialize GARP (garp_init_applicant) and MRP (mrp_init_applicant) for the underlying device. As part of the initialization process, we add the multicast address of each applicant to the underlying device, by calling dev_mc_add. __dev_mc_add uses dev->addr_len to determine the length of the new multicast address. This causes an out-of-bounds read if dev->addr_len is greater than 6, since the multicast addresses provided by GARP and MRP are only 6 bytes long. This behaviour can be reproduced using the following commands: ip tunnel add gretest mode ip6gre local ::1 remote ::2 dev lo ip l set up dev gretest ip link add link gretest name vlantest type vl...
In the Linux kernel, the following vulnerability has been resolved: vlan: enforce underlying device type Currently, VLAN devices can be created on top of non-ethernet devices. Besides the fact that it doesn't make much sense, this also causes a bug which leaks the address of a kernel function to usermode. When creating a VLAN device, we initialize GARP (garp_init_applicant) and MRP (mrp_init_applicant) for the underlying device. As part of the initialization process, we add the multicast address of each applicant to the underlying device, by calling dev_mc_add. __dev_mc_add uses dev->addr_len to determine the length of the new multicast address. This causes an out-of-bounds read if dev->addr_len is greater than 6, since the multicast addresses provided by GARP and MRP are only 6 bytes long. This behaviour can be reproduced using the following commands: ip tunnel add gretest mode ip6gre local ::1 remote ::2 dev lo ip l set up dev gretest ip link add link gretest name vlantest type vl...