Bug 2451223 (CVE-2026-23313)

Summary: CVE-2026-23313 kernel: i40e: Fix preempt count leak in napi poll tracepoint
Product: [Other] Security Response Reporter: OSIDB Bzimport <bzimport>
Component: vulnerabilityAssignee: Product Security <prodsec-ir-bot>
Status: NEW --- QA Contact:
Severity: low Docs Contact:
Priority: low    
Version: unspecifiedKeywords: Security
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: ---
Doc Text:
A flaw was found in the i40e network driver within the Linux kernel. This vulnerability, a preemption count leak, occurs in the NAPI (New API) poll tracepoint due to incorrect handling of CPU preemption counts. This issue could lead to an imbalanced preemption count, potentially causing kernel warnings, system instability, or a denial of service.
 Story Points: ---
Clone Of: Environment:
Last Closed: Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description OSIDB Bzimport 2026-03-25 11:05:32 UTC 
In the Linux kernel, the following vulnerability has been resolved:

i40e: Fix preempt count leak in napi poll tracepoint

Using get_cpu() in the tracepoint assignment causes an obvious preempt
count leak because nothing invokes put_cpu() to undo it:

  softirq: huh, entered softirq 3 NET_RX with preempt_count 00000100, exited with 00000101?

This clearly has seen a lot of testing in the last 3+ years...

Use smp_processor_id() instead.
Comment 1 Alexander B 2026-03-25 15:00:45 UTC 
Upstream advisory:
https://lore.kernel.org/linux-cve-announce/2026032529-CVE-2026-23313-925e@gregkh/T