Threats Tagged 'cve-2026-43065'
View all threats tagged with 'cve-2026-43065'. 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-2026-43065'
Click on any threat for detailed analysis and mitigation recommendations
0 Multiple vulnerabilities have been identified in the Linux kernel, which is the core component of the Linux operating system. These vulnerabilities are cataloged under CVE-2026-43059 and are associated with the CWE-416 category (Use After Free). The affected products include various Linux distributions such as Amazon Linux 2 and Debian Linux, as well as Google-related Linux environments. No specific technical details or CVSS scores are provided, and there are no known exploits in the wild at this time. Join the discussion | GCVE Database | 05/05/2026, 22:00:00 UTC Added: 06/10/2026, 11:42:20 UTC |
In the Linux kernel, the following vulnerability has been resolved: ext4: always drain queued discard work in ext4_mb_release() While reviewing recent ext4 patch[1], Sashiko raised the following concern[2]: > If the filesystem is initially mounted with the discard option, > deleting files will populate sbi->s_discard_list and queue > s_discard_work. If it is then remounted with nodiscard, the > EXT4_MOUNT_DISCARD flag is cleared, but the pending s_discard_work is > neither cancelled nor flushed. [1] https://lore.kernel.org/r/[email protected]/ [2] https://sashiko.dev/#/patchset/20260319094545.19291-1-qiang.zhang%40linux.dev The concern was valid, but it had nothing to do with the patch[1]. One of the problems with Sashiko in its current (early) form is that it will detect pre-existing issues and report it as a problem with the patch that it is reviewing. In practice, it would be hard to hit deliberately (unless you are a malicious syzkaller fuzzer), since it would involve mounting the file system with -o discard, and then deleting a large number of files, remounting the file system with -o nodiscard, and then immediately unmounting the file system before the queued discard work has a change to drain on its own. Fix it because it's a real bug, and to avoid Sashiko from raising this concern when analyzing future patches to mballoc.c. Join the discussion | GCVE Database | 05/05/2026, 16:16:00 UTC Added: 07/17/2026, 10:26:42 UTC |
In the Linux kernel, the following vulnerability has been resolved: efivarfs: Fix memory leak of efivarfs_fs_info in fs_context error paths When processing mount options, efivarfs allocates efivarfs_fs_info (sfi) early in fs_context initialization. However, sfi is associated with the superblock and typically freed when the superblock is destroyed. If the fs_context is released (final put) before fill_super is called—such as on error paths or during reconfiguration—the sfi structure would leak, as ownership never transfers to the superblock. Implement the .free callback in efivarfs_context_ops to ensure any allocated sfi is properly freed if the fs_context is torn down before fill_super, preventing this memory leak. Join the discussion | GCVE Database | 08/16/2025, 12:15:00 UTC Added: 06/24/2026, 17:00:23 UTC |
Showing 1 to 3 of 3 results