ghsa-2659-557q-cph8
Vulnerability from github
In the Linux kernel, the following vulnerability has been resolved:
ata: sata_dwc_460ex: Fix crash due to OOB write
the driver uses libata's "tag" values from in various arrays. Since the mentioned patch bumped the ATA_TAG_INTERNAL to 32, the value of the SATA_DWC_QCMD_MAX needs to account for that.
Otherwise ATA_TAG_INTERNAL usage cause similar crashes like this as reported by Tice Rex on the OpenWrt Forum and reproduced (with symbols) here:
| BUG: Kernel NULL pointer dereference at 0x00000000 | Faulting instruction address: 0xc03ed4b8 | Oops: Kernel access of bad area, sig: 11 [#1] | BE PAGE_SIZE=4K PowerPC 44x Platform | CPU: 0 PID: 362 Comm: scsi_eh_1 Not tainted 5.4.163 #0 | NIP: c03ed4b8 LR: c03d27e8 CTR: c03ed36c | REGS: cfa59950 TRAP: 0300 Not tainted (5.4.163) | MSR: 00021000 CR: 42000222 XER: 00000000 | DEAR: 00000000 ESR: 00000000 | GPR00: c03d27e8 cfa59a08 cfa55fe0 00000000 0fa46bc0 [...] | [..] | NIP [c03ed4b8] sata_dwc_qc_issue+0x14c/0x254 | LR [c03d27e8] ata_qc_issue+0x1c8/0x2dc | Call Trace: | [cfa59a08] [c003f4e0] __cancel_work_timer+0x124/0x194 (unreliable) | [cfa59a78] [c03d27e8] ata_qc_issue+0x1c8/0x2dc | [cfa59a98] [c03d2b3c] ata_exec_internal_sg+0x240/0x524 | [cfa59b08] [c03d2e98] ata_exec_internal+0x78/0xe0 | [cfa59b58] [c03d30fc] ata_read_log_page.part.38+0x1dc/0x204 | [cfa59bc8] [c03d324c] ata_identify_page_supported+0x68/0x130 | [...]
This is because sata_dwc_dma_xfer_complete() NULLs the dma_pending's next neighbour "chan" (a *dma_chan struct) in this '32' case right here (line ~735):
hsdevp->dma_pending[tag] = SATA_DWC_DMA_PENDING_NONE;
Then the next time, a dma gets issued; dma_dwc_xfer_setup() passes the NULL'd hsdevp->chan to the dmaengine_slave_config() which then causes the crash.
With this patch, SATA_DWC_QCMD_MAX is now set to ATA_MAX_QUEUE + 1. This avoids the OOB. But please note, there was a worthwhile discussion on what ATA_TAG_INTERNAL and ATA_MAX_QUEUE is. And why there should not be a "fake" 33 command-long queue size.
Ideally, the dw driver should account for the ATA_TAG_INTERNAL. In Damien Le Moal's words: "... having looked at the driver, it is a bigger change than just faking a 33rd "tag" that is in fact not a command tag at all."
BugLink: https://github.com/openwrt/openwrt/issues/9505
{
"affected": [],
"aliases": [
"CVE-2022-49073"
],
"database_specific": {
"cwe_ids": [
"CWE-787"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-02-26T07:00:44Z",
"severity": "HIGH"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nata: sata_dwc_460ex: Fix crash due to OOB write\n\nthe driver uses libata\u0027s \"tag\" values from in various arrays.\nSince the mentioned patch bumped the ATA_TAG_INTERNAL to 32,\nthe value of the SATA_DWC_QCMD_MAX needs to account for that.\n\nOtherwise ATA_TAG_INTERNAL usage cause similar crashes like\nthis as reported by Tice Rex on the OpenWrt Forum and\nreproduced (with symbols) here:\n\n| BUG: Kernel NULL pointer dereference at 0x00000000\n| Faulting instruction address: 0xc03ed4b8\n| Oops: Kernel access of bad area, sig: 11 [#1]\n| BE PAGE_SIZE=4K PowerPC 44x Platform\n| CPU: 0 PID: 362 Comm: scsi_eh_1 Not tainted 5.4.163 #0\n| NIP: c03ed4b8 LR: c03d27e8 CTR: c03ed36c\n| REGS: cfa59950 TRAP: 0300 Not tainted (5.4.163)\n| MSR: 00021000 \u003cCE,ME\u003e CR: 42000222 XER: 00000000\n| DEAR: 00000000 ESR: 00000000\n| GPR00: c03d27e8 cfa59a08 cfa55fe0 00000000 0fa46bc0 [...]\n| [..]\n| NIP [c03ed4b8] sata_dwc_qc_issue+0x14c/0x254\n| LR [c03d27e8] ata_qc_issue+0x1c8/0x2dc\n| Call Trace:\n| [cfa59a08] [c003f4e0] __cancel_work_timer+0x124/0x194 (unreliable)\n| [cfa59a78] [c03d27e8] ata_qc_issue+0x1c8/0x2dc\n| [cfa59a98] [c03d2b3c] ata_exec_internal_sg+0x240/0x524\n| [cfa59b08] [c03d2e98] ata_exec_internal+0x78/0xe0\n| [cfa59b58] [c03d30fc] ata_read_log_page.part.38+0x1dc/0x204\n| [cfa59bc8] [c03d324c] ata_identify_page_supported+0x68/0x130\n| [...]\n\nThis is because sata_dwc_dma_xfer_complete() NULLs the\ndma_pending\u0027s next neighbour \"chan\" (a *dma_chan struct) in\nthis \u002732\u0027 case right here (line ~735):\n\u003e hsdevp-\u003edma_pending[tag] = SATA_DWC_DMA_PENDING_NONE;\n\nThen the next time, a dma gets issued; dma_dwc_xfer_setup() passes\nthe NULL\u0027d hsdevp-\u003echan to the dmaengine_slave_config() which then\ncauses the crash.\n\nWith this patch, SATA_DWC_QCMD_MAX is now set to ATA_MAX_QUEUE + 1.\nThis avoids the OOB. But please note, there was a worthwhile discussion\non what ATA_TAG_INTERNAL and ATA_MAX_QUEUE is. And why there should not\nbe a \"fake\" 33 command-long queue size.\n\nIdeally, the dw driver should account for the ATA_TAG_INTERNAL.\nIn Damien Le Moal\u0027s words: \"... having looked at the driver, it\nis a bigger change than just faking a 33rd \"tag\" that is in fact\nnot a command tag at all.\"\n\nBugLink: https://github.com/openwrt/openwrt/issues/9505",
"id": "GHSA-2659-557q-cph8",
"modified": "2025-09-23T18:30:20Z",
"published": "2025-09-23T18:30:20Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-49073"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/234c0132f76f0676d175757f61b0025191a3d935"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/3a8751c0d4e24129e72dcec0139e99833b13904a"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/55e1465ba79562a191708a40eeae3f8082a209e3"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/596c7efd69aae94f4b0e91172b075eb197958b99"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/7aa8104a554713b685db729e66511b93d989dd6a"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/8a05a6952ecd59aaa62cbdcdaf523ae2c8f436e8"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/fc629224aa62f23849cae83717932985ac51232d"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/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.
- Published Proof of Concept: A public proof of concept is available for this vulnerability.
- 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.