Vulnerability in Linux kernel
Auto-generated summary
Assembled by SecPulse from the source data (CVSS, CWE, affected versions) using templates — no AI involved. Check the original description and references below for exact details.
A vulnerability tracked as CVE-2024-53044 has been found in Linux kernel.
Successful exploitation can lead to full system takeover. CVSS score: 7.8/10.
What to do: apply the vendor's official patched release.
If unsure, ask your IT team or search "Linux kernel CVE-2024-53044" on the vendor's site.
CVE-2024-53044 (Linux kernel) — CVSS v3 7.8
Attack vector: local / no user interaction
Plan: 1) Audit SBOM/dependencies, 2) Stage→prod upgrade, 3) Add WAF/proxy monitoring on affected endpoints, 4) Hunt IOCs in logs.
Refs: see the GHSA / vendor advisory / patched release linked on this page.
A vulnerability (unclassified) exists in Linux kernel.
Check the vendor advisory for the affected versions of Linux kernel.
Severity: High (CVSS 7.8/10). Successful exploitation can lead to full system takeover.
Update to the patched release per vendor advisory.
Until the patch is applied: disable the affected feature, apply WAF rules, or restrict access via network ACLs.
Search webserver/proxy logs for unusual request patterns matching this CVE's known IOCs. Audit SBOM/dependencies to find affected services.
Response actions
Concrete steps and command examples for SOC/SRE teams to execute in order
-
1
Identify exposureidentify
Audit SBOM/dependencies for affected components.資産台帳・SBOM・依存マニフェストで Linux kernel を使っているサービスとバージョンを洗い出す。
-
2
Post-deployment verificationverify
Confirm patched version is live in productionパッチ適用後、ステージングで PoC または同等の悪用パターンを再現して脆弱性が閉じたことを確認。本番ではアクセスログ・WAF でアラート再発が無いか継続監視。
Affected packages
| Ecosystem | Package | Affected | Fixed |
|---|---|---|---|
| Linux | Kernel |
≥ 6.8.0, < 6.11.7 |
6.11.7 |
Fix status by distribution
Fixed packages published by each distribution for this CVE
- Debian DEBIAN-CVE-2024-53044 linux Fixed in: 6.11.7-1
- Ubuntu UBUNTU-CVE-2024-53044 linux-hwe-edge
Original description The description as published by the source.
In the Linux kernel, the following vulnerability has been resolved:
net/sched: sch_api: fix xa_insert() error path in tcf_block_get_ext()
This command:
$ tc qdisc replace dev eth0 ingress_block 1 egress_block 1 clsact
Error: block dev insert failed: -EBUSY.
fails because user space requests the same block index to be set for
both ingress and egress.
[ side note, I don't think it even failed prior to commit 913b47d3424e
("net/sched: Introduce tc block netdev tracking infra"), because this
is a command from an old set of notes of mine which used to work, but
alas, I did not scientifically bisect this ]
The problem is not that it fails, but rather, that the second time
around, it fails differently (and irrecoverably):
$ tc qdisc replace dev eth0 ingress_block 1 egress_block 1 clsact
Error: dsa_core: Flow block cb is busy.
[ another note: the extack is added by me for illustration purposes.
the context of the problem is that clsact_init() obtains the same
&q->ingress_block pointer as &q->egress_block, and since we call
tcf_block_get_ext() on both of them, "dev" will be added to the
block->ports xarray twice, thus failing the operation: once through
the ingress block pointer, and once again through the egress block
pointer. the problem itself is that when xa_insert() fails, we have
emitted a FLOW_BLOCK_BIND command through ndo_setup_tc(), but the
offload never sees a corresponding FLOW_BLOCK_UNBIND. ]
Even correcting the bad user input, we still cann…
Source: NIST National Vulnerability Database NVD
References
- advisory github.com
- advisory nvd.nist.gov
- package git.kernel.org
- web git.kernel.org
- web git.kernel.org