CVE-2022-49193: Vulnerability in Linux Linux
In the Linux kernel, the following vulnerability has been resolved: ice: fix 'scheduling while atomic' on aux critical err interrupt There's a kernel BUG splat on processing aux critical error interrupts in ice_misc_intr(): [ 2100.917085] BUG: scheduling while atomic: swapper/15/0/0x00010000 ... [ 2101.060770] Call Trace: [ 2101.063229] <IRQ> [ 2101.065252] dump_stack+0x41/0x60 [ 2101.068587] __schedule_bug.cold.100+0x4c/0x58 [ 2101.073060] __schedule+0x6a4/0x830 [ 2101.076570] schedule+0x35/0xa0 [ 2101.079727] schedule_preempt_disabled+0xa/0x10 [ 2101.084284] __mutex_lock.isra.7+0x310/0x420 [ 2101.088580] ? ice_misc_intr+0x201/0x2e0 [ice] [ 2101.093078] ice_send_event_to_aux+0x25/0x70 [ice] [ 2101.097921] ice_misc_intr+0x220/0x2e0 [ice] [ 2101.102232] __handle_irq_event_percpu+0x40/0x180 [ 2101.106965] handle_irq_event_percpu+0x30/0x80 [ 2101.111434] handle_irq_event+0x36/0x53 [ 2101.115292] handle_edge_irq+0x82/0x190 [ 2101.119148] handle_irq+0x1c/0x30 [ 2101.122480] do_IRQ+0x49/0xd0 [ 2101.125465] common_interrupt+0xf/0xf [ 2101.129146] </IRQ> ... As Andrew correctly mentioned previously[0], the following call ladder happens: ice_misc_intr() <- hardirq ice_send_event_to_aux() device_lock() mutex_lock() might_sleep() might_resched() <- oops Add a new PF state bit which indicates that an aux critical error occurred and serve it in ice_service_task() in process context. The new ice_pf::oicr_err_reg is read-write in both hardirq and process contexts, but only 3 bits of non-critical data probably aren't worth explicit synchronizing (and they're even in the same byte [31:24]). [0] https://lore.kernel.org/all/YeSRUVmrdmlUXHDn@lunn.ch
AI Analysis
Technical Summary
CVE-2022-49193 is a vulnerability in the Linux kernel related to the handling of auxiliary critical error interrupts in the Intel Ethernet Controller (ice) driver. Specifically, the issue arises from a kernel BUG triggered by 'scheduling while atomic' during the processing of aux critical error interrupts in the ice_misc_intr() function. The root cause is that the interrupt handler attempts to acquire a mutex lock, which can lead to a sleep operation in an atomic context where sleeping is forbidden. This results in a kernel panic or BUG splat, causing system instability or crashes. The vulnerability stems from the call chain where ice_misc_intr() (executing in hard IRQ context) calls ice_send_event_to_aux(), which attempts to lock a mutex via device_lock() and mutex_lock(), eventually invoking might_sleep() and might_resched(), operations that are invalid in interrupt context. The fix involves deferring the processing of the aux critical error to a process context by introducing a new PF state bit (oicr_err_reg) and handling the event in ice_service_task(), thus avoiding sleeping in atomic context. This correction prevents the kernel BUG and stabilizes the system during such error conditions. The vulnerability affects Linux kernel versions containing the affected ice driver code prior to the patch and is relevant for systems using Intel Ethernet controllers supported by the ice driver. No known exploits are reported in the wild, and no CVSS score has been assigned yet.
Potential Impact
For European organizations, this vulnerability can lead to system crashes or kernel panics on Linux servers or endpoints using Intel Ethernet controllers managed by the ice driver. Such instability can cause denial of service (DoS) conditions, disrupting critical network services, data center operations, or cloud infrastructure relying on affected Linux systems. The impact is primarily on availability, as the kernel BUG leads to system halts or reboots. Confidentiality and integrity impacts are minimal or indirect since the vulnerability does not enable privilege escalation or code execution. However, repeated crashes could lead to operational downtime, affecting business continuity, especially in sectors with high dependency on Linux-based networking equipment or servers, such as telecommunications, finance, and public services. Given the widespread use of Linux in European enterprises and data centers, the vulnerability poses a moderate risk if unpatched, particularly in environments with high network traffic or error rates triggering the aux critical error interrupts.
Mitigation Recommendations
European organizations should prioritize updating their Linux kernels to versions containing the patch that defers aux critical error processing to process context, thereby eliminating the scheduling while atomic issue. Specifically, they should: 1) Identify systems using Intel Ethernet controllers supported by the ice driver and verify kernel versions. 2) Apply vendor-provided kernel updates or patches that address CVE-2022-49193 promptly. 3) For environments where immediate patching is not feasible, consider temporarily disabling or limiting the use of affected network interfaces to reduce the likelihood of triggering the bug. 4) Monitor system logs for kernel BUG messages related to ice_misc_intr or scheduling while atomic errors to detect potential exploitation or system instability. 5) Implement robust system monitoring and automated reboot mechanisms to minimize downtime in case of crashes. 6) Engage with hardware vendors for firmware updates that might mitigate aux critical error interrupts if available. These steps go beyond generic advice by focusing on the specific driver and interrupt handling mechanism involved in this vulnerability.
Affected Countries
Germany, France, United Kingdom, Netherlands, Sweden, Finland, Italy, Spain, Poland
CVE-2022-49193: Vulnerability in Linux Linux
Description
In the Linux kernel, the following vulnerability has been resolved: ice: fix 'scheduling while atomic' on aux critical err interrupt There's a kernel BUG splat on processing aux critical error interrupts in ice_misc_intr(): [ 2100.917085] BUG: scheduling while atomic: swapper/15/0/0x00010000 ... [ 2101.060770] Call Trace: [ 2101.063229] <IRQ> [ 2101.065252] dump_stack+0x41/0x60 [ 2101.068587] __schedule_bug.cold.100+0x4c/0x58 [ 2101.073060] __schedule+0x6a4/0x830 [ 2101.076570] schedule+0x35/0xa0 [ 2101.079727] schedule_preempt_disabled+0xa/0x10 [ 2101.084284] __mutex_lock.isra.7+0x310/0x420 [ 2101.088580] ? ice_misc_intr+0x201/0x2e0 [ice] [ 2101.093078] ice_send_event_to_aux+0x25/0x70 [ice] [ 2101.097921] ice_misc_intr+0x220/0x2e0 [ice] [ 2101.102232] __handle_irq_event_percpu+0x40/0x180 [ 2101.106965] handle_irq_event_percpu+0x30/0x80 [ 2101.111434] handle_irq_event+0x36/0x53 [ 2101.115292] handle_edge_irq+0x82/0x190 [ 2101.119148] handle_irq+0x1c/0x30 [ 2101.122480] do_IRQ+0x49/0xd0 [ 2101.125465] common_interrupt+0xf/0xf [ 2101.129146] </IRQ> ... As Andrew correctly mentioned previously[0], the following call ladder happens: ice_misc_intr() <- hardirq ice_send_event_to_aux() device_lock() mutex_lock() might_sleep() might_resched() <- oops Add a new PF state bit which indicates that an aux critical error occurred and serve it in ice_service_task() in process context. The new ice_pf::oicr_err_reg is read-write in both hardirq and process contexts, but only 3 bits of non-critical data probably aren't worth explicit synchronizing (and they're even in the same byte [31:24]). [0] https://lore.kernel.org/all/YeSRUVmrdmlUXHDn@lunn.ch
AI-Powered Analysis
Technical Analysis
CVE-2022-49193 is a vulnerability in the Linux kernel related to the handling of auxiliary critical error interrupts in the Intel Ethernet Controller (ice) driver. Specifically, the issue arises from a kernel BUG triggered by 'scheduling while atomic' during the processing of aux critical error interrupts in the ice_misc_intr() function. The root cause is that the interrupt handler attempts to acquire a mutex lock, which can lead to a sleep operation in an atomic context where sleeping is forbidden. This results in a kernel panic or BUG splat, causing system instability or crashes. The vulnerability stems from the call chain where ice_misc_intr() (executing in hard IRQ context) calls ice_send_event_to_aux(), which attempts to lock a mutex via device_lock() and mutex_lock(), eventually invoking might_sleep() and might_resched(), operations that are invalid in interrupt context. The fix involves deferring the processing of the aux critical error to a process context by introducing a new PF state bit (oicr_err_reg) and handling the event in ice_service_task(), thus avoiding sleeping in atomic context. This correction prevents the kernel BUG and stabilizes the system during such error conditions. The vulnerability affects Linux kernel versions containing the affected ice driver code prior to the patch and is relevant for systems using Intel Ethernet controllers supported by the ice driver. No known exploits are reported in the wild, and no CVSS score has been assigned yet.
Potential Impact
For European organizations, this vulnerability can lead to system crashes or kernel panics on Linux servers or endpoints using Intel Ethernet controllers managed by the ice driver. Such instability can cause denial of service (DoS) conditions, disrupting critical network services, data center operations, or cloud infrastructure relying on affected Linux systems. The impact is primarily on availability, as the kernel BUG leads to system halts or reboots. Confidentiality and integrity impacts are minimal or indirect since the vulnerability does not enable privilege escalation or code execution. However, repeated crashes could lead to operational downtime, affecting business continuity, especially in sectors with high dependency on Linux-based networking equipment or servers, such as telecommunications, finance, and public services. Given the widespread use of Linux in European enterprises and data centers, the vulnerability poses a moderate risk if unpatched, particularly in environments with high network traffic or error rates triggering the aux critical error interrupts.
Mitigation Recommendations
European organizations should prioritize updating their Linux kernels to versions containing the patch that defers aux critical error processing to process context, thereby eliminating the scheduling while atomic issue. Specifically, they should: 1) Identify systems using Intel Ethernet controllers supported by the ice driver and verify kernel versions. 2) Apply vendor-provided kernel updates or patches that address CVE-2022-49193 promptly. 3) For environments where immediate patching is not feasible, consider temporarily disabling or limiting the use of affected network interfaces to reduce the likelihood of triggering the bug. 4) Monitor system logs for kernel BUG messages related to ice_misc_intr or scheduling while atomic errors to detect potential exploitation or system instability. 5) Implement robust system monitoring and automated reboot mechanisms to minimize downtime in case of crashes. 6) Engage with hardware vendors for firmware updates that might mitigate aux critical error interrupts if available. These steps go beyond generic advice by focusing on the specific driver and interrupt handling mechanism involved in this vulnerability.
Affected Countries
For access to advanced analysis and higher rate limits, contact root@offseq.com
Technical Details
- Data Version
- 5.1
- Assigner Short Name
- Linux
- Date Reserved
- 2025-02-26T01:49:39.287Z
- Cisa Enriched
- false
- Cvss Version
- null
- State
- PUBLISHED
Threat ID: 682d982dc4522896dcbe5209
Added to database: 5/21/2025, 9:09:01 AM
Last enriched: 6/30/2025, 3:56:40 AM
Last updated: 8/12/2025, 12:21:14 PM
Views: 13
Related Threats
Top Israeli Cybersecurity Director Arrested in US Child Exploitation Sting
HighCVE-2025-8878: CWE-94 Improper Control of Generation of Code ('Code Injection') in properfraction Paid Membership Plugin, Ecommerce, User Registration Form, Login Form, User Profile & Restrict Content – ProfilePress
MediumCVE-2025-8143: CWE-79 Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting') in pencidesign Soledad
MediumCVE-2025-8142: CWE-98 Improper Control of Filename for Include/Require Statement in PHP Program ('PHP Remote File Inclusion') in pencidesign Soledad
HighCVE-2025-8105: CWE-94 Improper Control of Generation of Code ('Code Injection') in pencidesign Soledad
HighActions
Updates to AI analysis are available only with a Pro account. Contact root@offseq.com for access.
External Links
Need enhanced features?
Contact root@offseq.com for Pro access with improved analysis and higher rate limits.