CVE-2022-48644

MEDIUMNVD 5.55.5
EchelonGraph scoreMEDIUM confidence

Score 5.5 from GitHub Security Advisory published 2024-04-28. NVD baseline CVSS 5.5; sources differ by 0.0.

Triggered by: GitHub Security Advisory CVSS
Sources: epss, ghsa, nvd
5.5EG
EchelonGraph verdictMonitorLow exploitation likelihood right now — keep watching.
  • Lower severity and no public exploit yet
CISA-KEV: Not listedEPSS PROB: 0%CVSS: 5.5Exploit: None knownExposed: 0

No vendor fix yet — apply a workaround or compensating control (WAF / firewall / segmentation) and watch for a patch.

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) --- */

CVSS v3
5.5
EG Score
5.5(medium)
EG Risk
25(Track)
EG Risk 25/100SSVC: Track

EG Risk is EchelonGraph's 0–100 priority score: it fuses intrinsic severity with real-world exploitation and automatability so you can rank equal-severity CVEs and fix the most dangerous first. Higher = act sooner. Distinct from the 0–10 EG Score (severity).

How it’s computed
Severity55% × 45%
Exploitation0% × 40%
Automatability0% × 15%
Action: Routine — remediate on your standard cadence.
EPSS PROB
0%
EPSS %ILE
14%
KEV
Not listed

Published

April 28, 2024

Last Modified

September 19, 2025

Patch Availability(1)

Vendor / EcosystemFixed in / PatchReleasedSource
linuxKernel @ 5.4.215osv

Patches are aggregated from vendor advisories (Red Hat, Microsoft, Cisco, GitHub) and package ecosystems (OSV, GHSA). Multiple rows for the same upstream release have been deduplicated.

Weakness Classification(1)

MITRE Common Weakness Enumeration — the root-cause categories this CVE belongs to.

Data Freshness Timeline

(refreshed 12× in last 7d / 44× in last 30d)

Each row is a source pipeline that fetched or updated this CVE on that date, with what changed. For example, "NVD update" means NVD published or revised its analysis for this CVE; "MITRE cvelistV5" means we ingested or refreshed it from the CNA feed. Most recent first.

Showing the most recent 100 of 108 total refreshes for this CVE.

  1. 2026-07-26 14:52 UTCEPSS rescore
  2. 2026-07-26 14:52 UTCEPSS rescore
  3. 2026-07-25 14:16 UTCEPSS rescore
  4. 2026-07-24 14:15 UTCEPSS rescore
  5. 2026-07-23 14:16 UTCEPSS rescore
  6. 2026-07-23 14:16 UTCEPSS rescore
  7. 2026-07-23 02:16 UTCEG score recompute
  8. 2026-07-22 23:03 UTCEG score recompute
  9. 2026-07-22 14:06 UTCEPSS rescore
  10. 2026-07-22 14:06 UTCEPSS rescore
  11. 2026-07-21 15:23 UTCEPSS rescore
  12. 2026-07-21 15:23 UTCEPSS rescore
  13. 2026-07-20 17:05 UTCEPSS rescore
  14. 2026-07-19 14:29 UTCEPSS rescore
  15. 2026-07-19 14:29 UTCEPSS rescore
  16. 2026-07-19 02:27 UTCEPSS rescore
  17. 2026-07-19 02:27 UTCEPSS rescore
  18. 2026-07-18 10:03 UTCEPSS rescore
  19. 2026-07-18 10:03 UTCEPSS rescore
  20. 2026-07-16 17:00 UTCEPSS rescore
  21. 2026-07-15 16:56 UTCEPSS rescore
  22. 2026-07-15 16:56 UTCEPSS rescore
  23. 2026-07-15 01:58 UTCEPSS rescore
  24. 2026-07-15 01:58 UTCEPSS rescore
  25. 2026-07-14 12:40 UTCOSV refresh
Show 75 more
  1. 2026-07-13 22:28 UTCEPSS rescore
  2. 2026-07-13 22:28 UTCEPSS rescore
  3. 2026-07-13 06:11 UTCEPSS rescore
  4. 2026-07-13 06:11 UTCEPSS rescore
  5. 2026-07-12 05:44 UTCEPSS rescore
  6. 2026-07-11 08:25 UTCEPSS rescore
  7. 2026-07-11 08:25 UTCEPSS rescore
  8. 2026-07-09 19:08 UTCEPSS rescore
  9. 2026-07-08 15:13 UTCEPSS rescore
  10. 2026-07-07 13:44 UTCEPSS rescore
  11. 2026-07-06 16:25 UTCEPSS rescore
  12. 2026-07-06 02:21 UTCEPSS rescore
  13. 2026-07-05 02:28 UTCEPSS rescore
  14. 2026-07-04 06:29 UTCEPSS rescore
  15. 2026-07-01 15:04 UTCEPSS rescore
  16. 2026-06-30 23:21 UTCEPSS rescore
  17. 2026-06-30 23:20 UTCEPSS rescore
  18. 2026-06-29 14:04 UTCEPSS rescore
  19. 2026-06-28 14:06 UTCEPSS rescore
  20. 2026-06-28 04:54 UTCEPSS rescore
  21. 2026-06-28 04:54 UTCEPSS rescore
  22. 2026-06-27 03:07 UTCEPSS rescore
  23. 2026-06-27 03:07 UTCEPSS rescore
  24. 2026-06-26 13:37 UTCOSV refresh
  25. 2026-06-25 13:48 UTCEPSS rescore
  26. 2026-06-25 13:48 UTCEPSS rescore
  27. 2026-06-24 14:03 UTCEPSS rescore
  28. 2026-06-24 14:03 UTCEPSS rescore
  29. 2026-06-23 21:31 UTCEPSS rescore
  30. 2026-06-23 21:31 UTCEPSS rescore
  31. 2026-06-22 14:24 UTCEPSS rescore
  32. 2026-06-21 14:55 UTCEPSS rescore
  33. 2026-06-21 14:55 UTCEPSS rescore
  34. 2026-06-21 01:58 UTCEPSS rescore
  35. 2026-06-21 01:58 UTCEPSS rescore
  36. 2026-06-19 19:24 UTCEPSS rescore
  37. 2026-06-19 19:24 UTCEPSS rescore
  38. 2026-06-18 17:51 UTCEPSS rescore
  39. 2026-06-18 17:51 UTCEPSS rescore
  40. 2026-06-17 17:51 UTCEPSS rescore
  41. 2026-06-17 17:51 UTCEPSS rescore
  42. 2026-06-16 17:51 UTCEPSS rescore
  43. 2026-06-16 17:51 UTCEPSS rescore
  44. 2026-06-15 17:47 UTCEPSS rescore
  45. 2026-06-14 23:16 UTCEPSS rescore
  46. 2026-06-13 22:59 UTCEPSS rescore
  47. 2026-06-12 23:10 UTCEPSS rescore
  48. 2026-06-12 23:10 UTCEPSS rescore
  49. 2026-06-11 13:58 UTCEPSS rescore
  50. 2026-06-11 13:58 UTCEPSS rescore
  51. 2026-06-10 13:21 UTCEPSS rescore
  52. 2026-06-10 13:21 UTCEPSS rescore
  53. 2026-06-08 20:11 UTCOSV refresh
  54. 2026-06-08 14:15 UTCEPSS rescore
  55. 2026-06-08 14:15 UTCEPSS rescore
  56. 2026-06-07 15:23 UTCEPSS rescore
  57. 2026-06-07 15:23 UTCEPSS rescore
  58. 2026-06-06 13:46 UTCEPSS rescore
  59. 2026-06-06 13:46 UTCEPSS rescore
  60. 2026-06-05 22:46 UTCEPSS rescore
  61. 2026-06-05 22:46 UTCEPSS rescore
  62. 2026-06-05 06:09 UTCEPSS rescore
  63. 2026-06-05 06:09 UTCEPSS rescore
  64. 2026-06-04 13:11 UTCEPSS rescore
  65. 2026-06-02 20:12 UTCEPSS rescore
  66. 2026-06-02 20:12 UTCEPSS rescore
  67. 2026-06-01 13:50 UTCEPSS rescore
  68. 2026-06-01 13:50 UTCEPSS rescore
  69. 2026-05-31 00:15 UTCEPSS rescore
  70. 2026-05-31 00:15 UTCEPSS rescore
  71. 2026-05-29 13:43 UTCEPSS rescore
  72. 2026-05-28 13:43 UTCEPSS rescore
  73. 2026-05-28 13:43 UTCEPSS rescore
  74. 2026-05-27 13:39 UTCEPSS rescore
  75. 2026-05-27 13:39 UTCEPSS rescore

Frequently asked(5)

What is CVE-2022-48644?
CVE-2022-48644 is a medium vulnerability published on April 28, 2024. 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…
When was CVE-2022-48644 disclosed?
CVE-2022-48644 was first published in the National Vulnerability Database on April 28, 2024, with the most recent update on September 19, 2025. EchelonGraph re-ingests CVE updates from NVD on a 2-hour cycle, so this page reflects the latest published state.
Is CVE-2022-48644 actively exploited?
CVE-2022-48644 is not currently on CISA's Known Exploited Vulnerabilities catalog. FIRST EPSS estimates a 0% probability of exploitation in the next 30 days, which ranks it in the top 85.8% of all scored CVEs.
What is the CVSS score of CVE-2022-48644?
CVE-2022-48644 has a CVSS v3 base score of 5.5 (NVD).
How do I remediate CVE-2022-48644?
Patch to the fixed version published by the affected vendor. Where vendor advisories exist for CVE-2022-48644, EchelonGraph cross-links them in the Vendor Advisories panel below — those typically contain the canonical remediation steps, fixed version numbers, and any vendor-specific mitigations.

Dependency Blast Radius

Explore the affected products and dependency analysis for CVE-2022-48644

Explore →

Is Your Infrastructure Affected by CVE-2022-48644?

EchelonGraph automatically scans your cloud infrastructure and maps CVE exposure using blast radius analysis.