Threats Tagged 'cve-2025-71072'
View all threats tagged with 'cve-2025-71072'. Filter and sort to focus on specific types of threats.
Stop chasing alerts. Route them.
Start free, then upgrade once to turn Radar into an automated delivery engine for your security stack.
Custom feeds / Automations: email, Slack, webhooks, SIEM/MISP / API access (baseline limits)
API access activates after upgrading in Console -> Billing.
Check if your credentials are on the dark web
Instant breach scanning across billions of leaked records. Free tier available.
Filter Threats
Narrow down the results by type, severity, or affected countries
Threats Tagged 'cve-2025-71072'
Click on any threat for detailed analysis and mitigation recommendations
Red Hat Security Advisory: kernel security, bug fix, and enhancement updateCVE-2024-53143 0 This Red Hat security advisory addresses multiple vulnerabilities and bugs in the Linux kernel packages for Red Hat Enterprise Linux 10. The update includes fixes for seven CVEs affecting kernel components such as fsnotify, shmem, futex, AMD display DRM, IPC, slab memory management, and Open vSwitch networking. The advisory emphasizes the importance of applying the update and rebooting systems to ensure the fixes take effect. No CVSS scores are provided, but the overall severity is rated as important by Red Hat. Join the discussion | GCVE Database | 08/11/2026, 10:11:40 UTC Added: 08/11/2026, 18:54:17 UTC |
Linux hwe edge: In the Linux kernel, the following vulnerability has been resolved: shmem: fix recovery on rename failures maple_tree insertions can fail if we are… (CVE-2025-71072)CVE-2025-71072 0 In the Linux kernel, the following vulnerability has been resolved: shmem: fix recovery on rename failures maple_tree insertions can fail if we are seriously short on memory; simple_offset_rename() does not recover well if it runs into that. The same goes for simple_offset_rename_exchange(). Moreover, shmem_whiteout() expects that if it succeeds, the caller will progress to d_move(), i.e. that shmem_rename2() won't fail past the successful call of shmem_whiteout(). Not hard to fix, fortunately - mtree_store() can't fail if the index we are trying to store into is already present in the tree as a singleton. For simple_offset_rename_exchange() that's enough - we just need to be careful about the order of operations. For simple_offset_rename() solution is to preinsert the target into the tree for new_dir; the rest can be done without any potentially failing operations. That preinsertion has to be done in shmem_rename2() rather than in simple_offset_rename() itself - otherwise we'd need to deal with the possibility of failure after successful shmem_whiteout(). Join the discussion | GCVE Database | 01/13/2026, 16:16:00 UTC Added: 07/18/2026, 11:30:54 UTC |
Showing 1 to 2 of 2 results