Описание
Important: kernel security update
The kernel packages contain the Linux kernel, the core of any Linux operating system.
Security Fix(es):
-
kernel: HID: multitouch: fix slab out-of-bounds access in mt_report_fixup() (CVE-2025-39806)
-
kernel: audit: fix out-of-bounds read in audit_compare_dname_path() (CVE-2025-39840)
-
kernel: mm: slub: avoid wake up kswapd in set_track_prepare (CVE-2025-39843)
-
kernel: net: phylink: add lock for serializing concurrent pl->phydev writes with resolver (CVE-2025-39905)
-
kernel: iommufd: Fix race during abort for file descriptors (CVE-2025-39966)
-
kernel: tls: wait for pending async decryptions if tls_strp_msg_hold fails (CVE-2025-40176)
-
kernel: sctp: avoid NULL dereference when chunk data buffer is missing (CVE-2025-40240)
-
kernel: drm/vmwgfx: Validate command header size against SVGA_CMD_MAX_DATASIZE (CVE-2025-40277)
-
kernel: usb: dwc3: Fix race condition between concurrent dwc3_remove_requests() call paths (CVE-2025-68287)
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 - 2396941
- Red Hat - 2418832
- Red Hat - 2422788
- Red Hat - 2419954
- Red Hat - 2400611
- Red Hat - 2414524
- Red Hat - 2396936
- Red Hat - 2395807
- Red Hat - 2404107
Связанные уязвимости
In the Linux kernel, the following vulnerability has been resolved: net: phylink: add lock for serializing concurrent pl->phydev writes with resolver Currently phylink_resolve() protects itself against concurrent phylink_bringup_phy() or phylink_disconnect_phy() calls which modify pl->phydev by relying on pl->state_mutex. The problem is that in phylink_resolve(), pl->state_mutex is in a lock inversion state with pl->phydev->lock. So pl->phydev->lock needs to be acquired prior to pl->state_mutex. But that requires dereferencing pl->phydev in the first place, and without pl->state_mutex, that is racy. Hence the reason for the extra lock. Currently it is redundant, but it will serve a functional purpose once mutex_lock(&phy->lock) will be moved outside of the mutex_lock(&pl->state_mutex) section. Another alternative considered would have been to let phylink_resolve() acquire the rtnl_mutex, which is also held when phylink_bringup_phy() and phylink_disconnect_phy() are called. But since...
In the Linux kernel, the following vulnerability has been resolved: net: phylink: add lock for serializing concurrent pl->phydev writes with resolver Currently phylink_resolve() protects itself against concurrent phylink_bringup_phy() or phylink_disconnect_phy() calls which modify pl->phydev by relying on pl->state_mutex. The problem is that in phylink_resolve(), pl->state_mutex is in a lock inversion state with pl->phydev->lock. So pl->phydev->lock needs to be acquired prior to pl->state_mutex. But that requires dereferencing pl->phydev in the first place, and without pl->state_mutex, that is racy. Hence the reason for the extra lock. Currently it is redundant, but it will serve a functional purpose once mutex_lock(&phy->lock) will be moved outside of the mutex_lock(&pl->state_mutex) section. Another alternative considered would have been to let phylink_resolve() acquire the rtnl_mutex, which is also held when phylink_bringup_phy() and phylink_disconnect_phy() are called. But sin
net: phylink: add lock for serializing concurrent pl->phydev writes with resolver
In the Linux kernel, the following vulnerability has been resolved: n ...