ghsa-5c84-c56q-jq6c
Vulnerability from github
In the Linux kernel, the following vulnerability has been resolved:
usb: dwc2: fix possible NULL pointer dereference caused by driver concurrency
In _dwc2_hcd_urb_enqueue(), "urb->hcpriv = NULL" is executed without holding the lock "hsotg->lock". In _dwc2_hcd_urb_dequeue():
spin_lock_irqsave(&hsotg->lock, flags);
...
if (!urb->hcpriv) {
dev_dbg(hsotg->dev, "## urb->hcpriv is NULL ##\n");
goto out;
}
rc = dwc2_hcd_urb_dequeue(hsotg, urb->hcpriv); // Use urb->hcpriv
...
out: spin_unlock_irqrestore(&hsotg->lock, flags);
When _dwc2_hcd_urb_enqueue() and _dwc2_hcd_urb_dequeue() are concurrently executed, the NULL check of "urb->hcpriv" can be executed before "urb->hcpriv = NULL". After urb->hcpriv is NULL, it can be used in the function call to dwc2_hcd_urb_dequeue(), which can cause a NULL pointer dereference.
This possible bug is found by an experimental static analysis tool developed by myself. This tool analyzes the locking APIs to extract function pairs that can be concurrently executed, and then analyzes the instructions in the paired functions to identify possible concurrency bugs including data races and atomicity violations. The above possible bug is reported, when my tool analyzes the source code of Linux 6.5.
To fix this possible bug, "urb->hcpriv = NULL" should be executed with holding the lock "hsotg->lock". After using this patch, my tool never reports the possible bug, with the kernelconfiguration allyesconfig for x86_64. Because I have no associated hardware, I cannot test the patch in runtime testing, and just verify it according to the code logic.
{
"affected": [],
"aliases": [
"CVE-2023-52855"
],
"database_specific": {
"cwe_ids": [
"CWE-476"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-05-21T16:15:22Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nusb: dwc2: fix possible NULL pointer dereference caused by driver concurrency\n\nIn _dwc2_hcd_urb_enqueue(), \"urb-\u003ehcpriv = NULL\" is executed without\nholding the lock \"hsotg-\u003elock\". In _dwc2_hcd_urb_dequeue():\n\n spin_lock_irqsave(\u0026hsotg-\u003elock, flags);\n ...\n\tif (!urb-\u003ehcpriv) {\n\t\tdev_dbg(hsotg-\u003edev, \"## urb-\u003ehcpriv is NULL ##\\n\");\n\t\tgoto out;\n\t}\n rc = dwc2_hcd_urb_dequeue(hsotg, urb-\u003ehcpriv); // Use urb-\u003ehcpriv\n ...\nout:\n spin_unlock_irqrestore(\u0026hsotg-\u003elock, flags);\n\nWhen _dwc2_hcd_urb_enqueue() and _dwc2_hcd_urb_dequeue() are\nconcurrently executed, the NULL check of \"urb-\u003ehcpriv\" can be executed\nbefore \"urb-\u003ehcpriv = NULL\". After urb-\u003ehcpriv is NULL, it can be used\nin the function call to dwc2_hcd_urb_dequeue(), which can cause a NULL\npointer dereference.\n\nThis possible bug is found by an experimental static analysis tool\ndeveloped by myself. This tool analyzes the locking APIs to extract\nfunction pairs that can be concurrently executed, and then analyzes the\ninstructions in the paired functions to identify possible concurrency\nbugs including data races and atomicity violations. The above possible\nbug is reported, when my tool analyzes the source code of Linux 6.5.\n\nTo fix this possible bug, \"urb-\u003ehcpriv = NULL\" should be executed with\nholding the lock \"hsotg-\u003elock\". After using this patch, my tool never\nreports the possible bug, with the kernelconfiguration allyesconfig for\nx86_64. Because I have no associated hardware, I cannot test the patch\nin runtime testing, and just verify it according to the code logic.",
"id": "GHSA-5c84-c56q-jq6c",
"modified": "2024-11-05T18:31:59Z",
"published": "2024-05-21T18:31:23Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-52855"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/14c9ec34e8118fbffd7f5431814d767726323e72"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/3e851a77a13ce944d703721793f49ee82622986d"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/64c47749fc7507ed732e155c958253968c1d275e"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/6b21a22728852d020a6658d39cd7bb7e14b07790"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/a7bee9598afb38004841a41dd8fe68c1faff4e90"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/bdb3dd4096302d6b87441fdc528439f171b04be6"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/ef307bc6ef04e8c1ea843231db58e3afaafa9fa6"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/fcaafb574fc88a52dce817f039f7ff2f9da38001"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/fed492aa6493a91a77ebd51da6fb939c98d94a0d"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H",
"type": "CVSS_V3"
}
]
}
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.