gsd-2021-47125
Vulnerability from gsd
Modified
2024-03-05 06:03
Details
In the Linux kernel, the following vulnerability has been resolved:
sch_htb: fix refcount leak in htb_parent_to_leaf_offload
The commit ae81feb7338c ("sch_htb: fix null pointer dereference
on a null new_q") fixes a NULL pointer dereference bug, but it
is not correct.
Because htb_graft_helper properly handles the case when new_q
is NULL, and after the previous patch by skipping this call
which creates an inconsistency : dev_queue->qdisc will still
point to the old qdisc, but cl->parent->leaf.q will point to
the new one (which will be noop_qdisc, because new_q was NULL).
The code is based on an assumption that these two pointers are
the same, so it can lead to refcount leaks.
The correct fix is to add a NULL pointer check to protect
qdisc_refcount_inc inside htb_parent_to_leaf_offload.
Aliases
{ "gsd": { "metadata": { "exploitCode": "unknown", "remediation": "unknown", "reportConfidence": "confirmed", "type": "vulnerability" }, "osvSchema": { "aliases": [ "CVE-2021-47125" ], "details": "In the Linux kernel, the following vulnerability has been resolved:\n\nsch_htb: fix refcount leak in htb_parent_to_leaf_offload\n\nThe commit ae81feb7338c (\"sch_htb: fix null pointer dereference\non a null new_q\") fixes a NULL pointer dereference bug, but it\nis not correct.\n\nBecause htb_graft_helper properly handles the case when new_q\nis NULL, and after the previous patch by skipping this call\nwhich creates an inconsistency : dev_queue-\u003eqdisc will still\npoint to the old qdisc, but cl-\u003eparent-\u003eleaf.q will point to\nthe new one (which will be noop_qdisc, because new_q was NULL).\nThe code is based on an assumption that these two pointers are\nthe same, so it can lead to refcount leaks.\n\nThe correct fix is to add a NULL pointer check to protect\nqdisc_refcount_inc inside htb_parent_to_leaf_offload.", "id": "GSD-2021-47125", "modified": "2024-03-05T06:03:55.096372Z", "schema_version": "1.4.0" } }, "namespaces": { "cve.org": { "CVE_data_meta": { "ASSIGNER": "cve@kernel.org", "ID": "CVE-2021-47125", "STATE": "PUBLIC" }, "affects": { "vendor": { "vendor_data": [ { "product": { "product_data": [ { "product_name": "Linux", "version": { "version_data": [ { "version_affected": "\u003c", "version_name": "ae81feb7338c", "version_value": "2411c02d0389" }, { "version_value": "not down converted", "x_cve_json_5_version_data": { "defaultStatus": "affected", "versions": [ { "status": "affected", "version": "5.12" }, { "lessThan": "5.12", "status": "unaffected", "version": "0", "versionType": "custom" }, { "lessThanOrEqual": "5.12.*", "status": "unaffected", "version": "5.12.10", "versionType": "custom" }, { "lessThanOrEqual": "*", "status": "unaffected", "version": "5.13", "versionType": "original_commit_for_fix" } ] } } ] } } ] }, "vendor_name": "Linux" } ] } }, "data_format": "MITRE", "data_type": "CVE", "data_version": "4.0", "description": { "description_data": [ { "lang": "eng", "value": "In the Linux kernel, the following vulnerability has been resolved:\n\nsch_htb: fix refcount leak in htb_parent_to_leaf_offload\n\nThe commit ae81feb7338c (\"sch_htb: fix null pointer dereference\non a null new_q\") fixes a NULL pointer dereference bug, but it\nis not correct.\n\nBecause htb_graft_helper properly handles the case when new_q\nis NULL, and after the previous patch by skipping this call\nwhich creates an inconsistency : dev_queue-\u003eqdisc will still\npoint to the old qdisc, but cl-\u003eparent-\u003eleaf.q will point to\nthe new one (which will be noop_qdisc, because new_q was NULL).\nThe code is based on an assumption that these two pointers are\nthe same, so it can lead to refcount leaks.\n\nThe correct fix is to add a NULL pointer check to protect\nqdisc_refcount_inc inside htb_parent_to_leaf_offload." } ] }, "generator": { "engine": "bippy-8df59b4913de" }, "problemtype": { "problemtype_data": [ { "description": [ { "lang": "eng", "value": "n/a" } ] } ] }, "references": { "reference_data": [ { "name": "https://git.kernel.org/stable/c/2411c02d03892a5057499f8102d0cc1e0f852416", "refsource": "MISC", "url": "https://git.kernel.org/stable/c/2411c02d03892a5057499f8102d0cc1e0f852416" }, { "name": "https://git.kernel.org/stable/c/944d671d5faa0d78980a3da5c0f04960ef1ad893", "refsource": "MISC", "url": "https://git.kernel.org/stable/c/944d671d5faa0d78980a3da5c0f04960ef1ad893" } ] } }, "nvd.nist.gov": { "cve": { "descriptions": [ { "lang": "en", "value": "In the Linux kernel, the following vulnerability has been resolved:\n\nsch_htb: fix refcount leak in htb_parent_to_leaf_offload\n\nThe commit ae81feb7338c (\"sch_htb: fix null pointer dereference\non a null new_q\") fixes a NULL pointer dereference bug, but it\nis not correct.\n\nBecause htb_graft_helper properly handles the case when new_q\nis NULL, and after the previous patch by skipping this call\nwhich creates an inconsistency : dev_queue-\u003eqdisc will still\npoint to the old qdisc, but cl-\u003eparent-\u003eleaf.q will point to\nthe new one (which will be noop_qdisc, because new_q was NULL).\nThe code is based on an assumption that these two pointers are\nthe same, so it can lead to refcount leaks.\n\nThe correct fix is to add a NULL pointer check to protect\nqdisc_refcount_inc inside htb_parent_to_leaf_offload." } ], "id": "CVE-2021-47125", "lastModified": "2024-03-17T22:38:29.433", "metrics": {}, "published": "2024-03-15T21:15:07.307", "references": [ { "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67", "url": "https://git.kernel.org/stable/c/2411c02d03892a5057499f8102d0cc1e0f852416" }, { "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67", "url": "https://git.kernel.org/stable/c/944d671d5faa0d78980a3da5c0f04960ef1ad893" } ], "sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67", "vulnStatus": "Awaiting Analysis" } } } }
Loading...
Loading...
Sightings
Author | Source | Type | Date |
---|
Nomenclature
- Seen: The vulnerability was mentioned, discussed, or seen somewhere by the user.
- Confirmed: The vulnerability is confirmed from an analyst perspective.
- Exploited: This vulnerability was exploited and seen by the user reporting the sighting.
- Patched: This vulnerability was successfully patched by the user reporting the sighting.
- Not exploited: This vulnerability was not exploited or seen by the user reporting the sighting.
- Not confirmed: The user expresses doubt about the veracity of the vulnerability.
- Not patched: This vulnerability was not successfully patched by the user reporting the sighting.