CVE-2024-46681None▾ Sunlit

pktgen: use cpus_read_lock() in pg_net_init()

In the Linux kernel, the following vulnerability has been resolved: pktgen: use cpus_read_lock() in pg_net_init() I have seen the WARN_ON(smp_processor_id() != cpu) firing in pktgen_thread_worker() during tests. We must use cpus_read_…

▾ Sunlit zone — Low / medium · no exploitation signal

Depth score3/ 100 · Minimal

impact 2.8 · likelihood 0.1 · exploitation 0

⚡ Agent-ready:Raw markdown ↗JSON ↗

Proof of concept

Need a working PoC? Pro members can cast a request and our team develops one — it lands right here.

…

Published

Sep 13, 2024

Updated

Oct 21, 2026

CVSS

—

Vendor

Linux

Product

Linux

CWE

—

Depth score

3 · Minimal

EPSS

0.28% · p20

Platforms

—

Source

CVEORG

Vector

—

CISA SSVC

decided 2024-09-29

Exploitation: none
Automatable: no
Technical impact: partial

Stakeholder-Specific Vulnerability Categorization from CISA's ADP record at CVE.org: whether exploitation is observed, whether an attack can be automated, and how much of the system is at stake.

EPSS history

Exploit-prediction probability, daily snapshots since Oct 21.

0.2% → 0.3%▲ 0.07%

Timeline

Disclosure to exploitation, from the record and what we observed since indexing it.

4 events · 773 days

Sep 13, 2024Published
Disclosed via CVEORG
Oct 21, 2026Record revised
Last analysed / modified upstream
Oct 21, 2026EPSS first tracked
0.2%
Oct 26, 2026EPSS peak
0.2% → 0.3%

Linux #cve.org

Affected

Linux >= 1da177e4c3f41524e886b7f1b8a0c1fc7321cac2 < 7eed5b3115ce9e057bf64c3f6be9ea72f8298e4e
Linux >= 1da177e4c3f41524e886b7f1b8a0c1fc7321cac2 < 5f5f7366dda8ae870e8305d6e7b3c0c2686cd2cf
Linux >= 1da177e4c3f41524e886b7f1b8a0c1fc7321cac2 < 979b581e4c69257acab1af415ddad6b2d78a2fa5
Linux 2.6.12

Full technical detail▾

Overview

In the Linux kernel, the following vulnerability has been resolved:

pktgen: use cpus_read_lock() in pg_net_init()

I have seen the WARN_ON(smp_processor_id() != cpu) firing in pktgen_thread_worker() during tests.

We must use cpus_read_lock()/cpus_read_unlock() around the for_each_online_cpu(cpu) loop.

While we are at it use WARN_ON_ONCE() to avoid a possible syslog flood.

Affected

Linux >= 1da177e4c3f41524e886b7f1b8a0c1fc7321cac2 < 7eed5b3115ce9e057bf64c3f6be9ea72f8298e4e
Linux >= 1da177e4c3f41524e886b7f1b8a0c1fc7321cac2 < 5f5f7366dda8ae870e8305d6e7b3c0c2686cd2cf
Linux >= 1da177e4c3f41524e886b7f1b8a0c1fc7321cac2 < 979b581e4c69257acab1af415ddad6b2d78a2fa5
Linux 2.6.12

Remediation

Refer to the linked advisories for vendor-supplied fixes and affected version ranges.

References

Related vulnerabilities

Connected by shared product, vendor, weakness, or advisory.

#cve.org

pktgen: use cpus_read_lock() in pg_net_init()

▾ Sunlit zone — Low / medium · no exploitation signal

Depth score3/ 100 · Minimal

impact 2.8 · likelihood 0.1 · exploitation 0

Overview

In the Linux kernel, the following vulnerability has been resolved:

pktgen: use cpus_read_lock() in pg_net_init()

I have seen the WARN_ON(smp_processor_id() != cpu) firing in pktgen_thread_worker() during tests.

We must use cpus_read_lock()/cpus_read_unlock() around the for_each_online_cpu(cpu) loop.

While we are at it use WARN_ON_ONCE() to avoid a possible syslog flood.