Skip to main content

CVE-2022-48644: Vulnerability in Linux Linux

High
VulnerabilityCVE-2022-48644cvecve-2022-48644
Published: Sun Apr 28 2024 (04/28/2024, 13:00:07 UTC)
Source: CVE
Vendor/Project: Linux
Product: Linux

Description

In the Linux kernel, the following vulnerability has been resolved: net/sched: taprio: avoid disabling offload when it was never enabled In an incredibly strange API design decision, qdisc->destroy() gets called even if qdisc->init() never succeeded, not exclusively since commit 87b60cfacf9f ("net_sched: fix error recovery at qdisc creation"), but apparently also earlier (in the case of qdisc_create_dflt()). The taprio qdisc does not fully acknowledge this when it attempts full offload, because it starts off with q->flags = TAPRIO_FLAGS_INVALID in taprio_init(), then it replaces q->flags with TCA_TAPRIO_ATTR_FLAGS parsed from netlink (in taprio_change(), tail called from taprio_init()). But in taprio_destroy(), we call taprio_disable_offload(), and this determines what to do based on FULL_OFFLOAD_IS_ENABLED(q->flags). But looking at the implementation of FULL_OFFLOAD_IS_ENABLED() (a bitwise check of bit 1 in q->flags), it is invalid to call this macro on q->flags when it contains TAPRIO_FLAGS_INVALID, because that is set to U32_MAX, and therefore FULL_OFFLOAD_IS_ENABLED() will return true on an invalid set of flags. As a result, it is possible to crash the kernel if user space forces an error between setting q->flags = TAPRIO_FLAGS_INVALID, and the calling of taprio_enable_offload(). This is because drivers do not expect the offload to be disabled when it was never enabled. The error that we force here is to attach taprio as a non-root qdisc, but instead as child of an mqprio root qdisc: $ tc qdisc add dev swp0 root handle 1: \ mqprio num_tc 8 map 0 1 2 3 4 5 6 7 \ queues 1@0 1@1 1@2 1@3 1@4 1@5 1@6 1@7 hw 0 $ tc qdisc replace dev swp0 parent 1:1 \ taprio num_tc 8 map 0 1 2 3 4 5 6 7 \ queues 1@0 1@1 1@2 1@3 1@4 1@5 1@6 1@7 base-time 0 \ sched-entry S 0x7f 990000 sched-entry S 0x80 100000 \ flags 0x0 clockid CLOCK_TAI Unable to handle kernel paging request at virtual address fffffffffffffff8 [fffffffffffffff8] pgd=0000000000000000, p4d=0000000000000000 Internal error: Oops: 96000004 [#1] PREEMPT SMP Call trace: taprio_dump+0x27c/0x310 vsc9959_port_setup_tc+0x1f4/0x460 felix_port_setup_tc+0x24/0x3c dsa_slave_setup_tc+0x54/0x27c taprio_disable_offload.isra.0+0x58/0xe0 taprio_destroy+0x80/0x104 qdisc_create+0x240/0x470 tc_modify_qdisc+0x1fc/0x6b0 rtnetlink_rcv_msg+0x12c/0x390 netlink_rcv_skb+0x5c/0x130 rtnetlink_rcv+0x1c/0x2c Fix this by keeping track of the operations we made, and undo the offload only if we actually did it. I've added "bool offloaded" inside a 4 byte hole between "int clockid" and "atomic64_t picos_per_byte". Now the first cache line looks like below: $ pahole -C taprio_sched net/sched/sch_taprio.o struct taprio_sched { struct Qdisc * * qdiscs; /* 0 8 */ struct Qdisc * root; /* 8 8 */ u32 flags; /* 16 4 */ enum tk_offsets tk_offset; /* 20 4 */ int clockid; /* 24 4 */ bool offloaded; /* 28 1 */ /* XXX 3 bytes hole, try to pack */ atomic64_t picos_per_byte; /* 32 0 */ /* XXX 8 bytes hole, try to pack */ spinlock_t current_entry_lock; /* 40 0 */ /* XXX 8 bytes hole, try to pack */ struct sched_entry * current_entry; /* 48 8 */ struct sched_gate_list * oper_sched; /* 56 8 */ /* --- cacheline 1 boundary (64 bytes) --- */

AI-Powered Analysis

AILast updated: 06/30/2025, 18:11:24 UTC

Technical Analysis

CVE-2022-48644 is a vulnerability in the Linux kernel's network scheduler (net/sched) subsystem, specifically affecting the taprio (Time-Aware Priority Scheduler) queuing discipline (qdisc). The flaw arises from an unusual API design where the qdisc->destroy() function is called even if qdisc->init() never successfully completed. The taprio qdisc initializes its flags field to TAPRIO_FLAGS_INVALID (set to U32_MAX) and later updates it during initialization. However, if an error is forced between setting this invalid flag and enabling offload, the taprio_destroy() function calls taprio_disable_offload(), which checks if full offload is enabled by inspecting a bit in the flags field. Because the flags are invalid (U32_MAX), the check incorrectly returns true, causing the kernel to attempt to disable offload that was never enabled. This leads to a kernel crash due to an invalid memory access (kernel paging fault). The issue can be triggered by attaching the taprio qdisc as a non-root qdisc under an mqprio root qdisc, which is not a supported configuration. The root cause is a lack of proper state tracking to ensure offload is only disabled if it was previously enabled. The patch introduces a boolean 'offloaded' flag to track offload state and prevent erroneous disable calls. This vulnerability can cause a denial of service (DoS) by crashing the kernel, impacting system availability. It does not require user interaction beyond issuing specific tc (traffic control) commands and can be exploited by unprivileged users if they have the ability to configure qdiscs on network interfaces. No known exploits are reported in the wild yet. The vulnerability affects Linux kernel versions containing the specified commit hashes prior to the fix published in April 2024.

Potential Impact

For European organizations, this vulnerability poses a risk primarily to systems running Linux kernels with the affected taprio qdisc implementation, especially in environments where advanced traffic scheduling and offloading are used, such as telecom infrastructure, data centers, and network appliances. The impact is a potential denial of service through kernel crashes, which can disrupt critical network services and degrade availability. Systems that allow non-root users to configure network qdiscs are particularly vulnerable, potentially enabling local attackers to cause system instability. Given the widespread use of Linux in European enterprise servers, cloud infrastructure, and embedded network devices, exploitation could lead to service outages, impacting business continuity and operational reliability. Organizations relying on real-time or time-sensitive networking may experience significant disruptions. However, the lack of known exploits and the requirement for specific qdisc configurations somewhat limit immediate risk. Still, the vulnerability underscores the importance of patching kernel components involved in network scheduling to maintain system stability and security.

Mitigation Recommendations

1. Apply the official Linux kernel patch that introduces the 'offloaded' flag to properly track offload state and prevent erroneous disable calls. Ensure all affected systems are updated to a kernel version including this fix. 2. Restrict permissions to configure qdiscs on network interfaces to trusted administrators only, minimizing the risk of unprivileged users triggering the vulnerability. 3. Audit network device configurations to avoid unsupported qdisc hierarchies, such as attaching taprio as a non-root qdisc under mqprio, which triggers the bug. 4. Implement kernel crash monitoring and automated recovery mechanisms to reduce downtime in case of unexpected crashes. 5. For critical infrastructure, consider isolating systems running vulnerable kernels from untrusted users and networks to reduce attack surface. 6. Engage with Linux distribution vendors for timely updates and backports, especially for long-term support (LTS) kernels commonly used in enterprise environments. 7. Monitor security advisories and threat intelligence feeds for any emerging exploit attempts targeting this vulnerability.

Need more detailed analysis?Get Pro

Technical Details

Data Version
5.1
Assigner Short Name
Linux
Date Reserved
2024-02-25T13:44:28.316Z
Cisa Enriched
true
Cvss Version
null
State
PUBLISHED

Threat ID: 682d982ec4522896dcbe5d8c

Added to database: 5/21/2025, 9:09:02 AM

Last enriched: 6/30/2025, 6:11:24 PM

Last updated: 7/30/2025, 5:33:42 AM

Views: 19

Actions

PRO

Updates to AI analysis are available only with a Pro account. Contact root@offseq.com for access.

Please log in to the Console to use AI analysis features.

Need enhanced features?

Contact root@offseq.com for Pro access with improved analysis and higher rate limits.

Latest Threats