CVE-2024-50302
Is CVE-2024-50302 real, exploitable, or a false positive? Here's the community verdict.
signals
public sources
Confirmed exploited in the wild. Patch this first, regardless of the base score.
baseline read
auto · not a community verdict
Real — exploited in the wild
CISA confirms active exploitation. Treat scanner hits as true positives unless your specific version or config is unaffected.
Based on CISA KEV
Confirm or dispute →CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N
In the Linux kernel, the following vulnerability has been resolved: HID: core: zero-initialize the report buffer Since the report buffer is used by all kinds of drivers in various ways, let's zero-initialize it during allocation to make sure that it can't be ever used to leak kernel memory via specially-crafted report.
References
Published
Embed this verdict
[](https://www.truepositive.app/cve/CVE-2024-50302)<a href="https://www.truepositive.app/cve/CVE-2024-50302"><img src="https://www.truepositive.app/cve/CVE-2024-50302/badge.svg" alt="TruePositive verdict for CVE-2024-50302"></a>Live badge that updates automatically as the community verdict changes.
Community ground truth
Be the first practitioner to weigh in
So far this is only TruePositive's editorial baseline from public sources. Add your real-world verdict below — it becomes the signal the next person triaging this relies on.
🥇 The first 50 practitioners to contribute earn a Founding Contributor badge.
In your experience, is this finding real and exploitable?
awaiting field verdictsCurated baseline: TruePositive's read from public sources is Real & exploitable — a starting point, not a community verdict.
No account needed. Anonymous verdicts post as an unverified signal. Log in to make yours verified and earn reputation.
Field notes & remediation
Verdicts are the quick signal. Notes are the evidence and fixes behind them.
- 0
Linux Kernel Use of Uninitialized Resource Vulnerability — The Linux kernel contains a use of uninitialized resource vulnerability that allows an attacker to leak kernel memory via a specially crafted HID report. Listed in the CISA KEV catalog (added 2025-03-04) — confirmed exploited in the wild, not theoretical. FIRST EPSS puts the chance of exploitation in the next 30 days at ~1%. Treat it as real and prioritize remediation over triage.
- 0
Required action for Linux Kernel: Apply mitigations per vendor instructions, follow applicable BOD 22-01 guidance for cloud services, or discontinue use of the product if mitigations are unavailable. CISA set a federal remediation due date of 2025-03-25. After patching, verify the vulnerable path is no longer reachable before closing the finding.
Add a field note or remediationoptional
Related CVEs
Same weakness: CWE-908.
- CVE-2024-29745MED 5.5KEVEPSS 0%
there is a possible Information Disclosure due to uninitialized data. This could lead to local information disclosure with no additional execution privileges needed. User interaction is not needed for exploitation.
- CVE-2024-50014MED 5.5EPSS 0%
In the Linux kernel, the following vulnerability has been resolved: ext4: fix access to uninitialised lock in fc replay path The following kernel trace can be triggered with fstest generic/629 when executed against a filesystem with fast-commit feature enabled: INFO: trying to register non-static key. The code is fine but needs lockdep annotation, or maybe you didn't initialize this object before use? turning off the locking correctness validator. CPU: 0 PID: 866 Comm: mount Not tainted 6.10.0+ #11 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.2-3-gd478f380-prebuilt.qemu.org 04/01/2014 Call Trace: <TASK> dump_stack_lvl+0x66/0x90 register_lock_class+0x759/0x7d0 __lock_acquire+0x85/0x2630 ? __find_get_block+0xb4/0x380 lock_acquire+0xd1/0x2d0 ? __ext4_journal_get_write_access+0xd5/0x160 _raw_spin_lock+0x33/0x40 ? __ext4_journal_get_write_access+0xd5/0x160 __ext4_journal_get_write_access+0xd5/0x160 ext4_reserve_inode_write+0x61/0xb0 __ext4_mark_inode_dirty+0x79/0x270 ? ext4_ext_replay_set_iblocks+0x2f8/0x450 ext4_ext_replay_set_iblocks+0x330/0x450 ext4_fc_replay+0x14c8/0x1540 ? jread+0x88/0x2e0 ? rcu_is_watching+0x11/0x40 do_one_pass+0x447/0xd00 jbd2_journal_recover+0x139/0x1b0 jbd2_journal_load+0x96/0x390 ext4_load_and_init_journal+0x253/0xd40 ext4_fill_super+0x2cc6/0x3180 ... In the replay path there's an attempt to lock sbi->s_bdev_wb_lock in function ext4_check_bdev_write_error(). Unfortunately, at this point this spinlock has not been initialized yet. Moving it's initialization to an earlier point in __ext4_fill_super() fixes this splat.
- CVE-2026-53082MED 5.5EPSS 0%
In the Linux kernel, the following vulnerability has been resolved: net: hamradio: 6pack: fix uninit-value in sixpack_receive_buf sixpack_receive_buf() does not properly skip bytes with TTY error flags. The while loop iterates through the flags buffer but never advances the data pointer (cp), and passes the original count (including error bytes) to sixpack_decode(). This causes sixpack_decode() to process bytes that should have been skipped due to TTY errors. The TTY layer does not guarantee that cp[i] holds a meaningful value when fp[i] is set, so passing those positions to sixpack_decode() results in KMSAN reporting an uninit-value read. Fix this by processing bytes one at a time, advancing cp on each iteration, and only passing valid (non-error) bytes to sixpack_decode(). This matches the pattern used by slip_receive_buf() and mkiss_receive_buf() for the same purpose.