CVE-2022-49073
ata: sata_dwc_460ex: Fix crash due to OOB write
- Published
- Updated
- Reserved
- Assigned by
- Linux
Description
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 <CE,ME> 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
Timeline
ID reserved
By Linux
Published
- 18 months later
· 18 months later
Record updated
Changes after publication (a new score, a public exploit, EPSS crossing 1, 10 or 50 %, leaving KEV) are kept since November 2026; earlier ones are not known.
Scores
| Scored by | CVSS | Score | Vector |
|---|---|---|---|
| LinuxCNA (assigner) | 3.1 | High7.8 | CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H |
| NVDNVD · Modified | 3.1 | High7.8 | CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H |
- EPSS (exploitation in 30 days)
- 0.28% · top 80% of all CVEs (7 Nov 2026)
The list uses the assigner's score when there is one, then CISA's, then NVD's: High 7.8.
Weakness
Affected products
- affected 28361c403683c2b00d4f5e76045f3ccd299bf99d – < 596c7efd69aae94f4b0e91172b075eb197958b99
- affected 28361c403683c2b00d4f5e76045f3ccd299bf99d – < 55e1465ba79562a191708a40eeae3f8082a209e3
- affected 28361c403683c2b00d4f5e76045f3ccd299bf99d – < fc629224aa62f23849cae83717932985ac51232d
- affected 28361c403683c2b00d4f5e76045f3ccd299bf99d – < 8a05a6952ecd59aaa62cbdcdaf523ae2c8f436e8
- affected 28361c403683c2b00d4f5e76045f3ccd299bf99d – < 234c0132f76f0676d175757f61b0025191a3d935
- affected 28361c403683c2b00d4f5e76045f3ccd299bf99d – < 3a8751c0d4e24129e72dcec0139e99833b13904a
- affected 28361c403683c2b00d4f5e76045f3ccd299bf99d – < 7aa8104a554713b685db729e66511b93d989dd6a
- affected 4.18
- unaffected < 4.18
- unaffected 4.19.238 – ≤ 4.19.*
- unaffected 5.4.189 – ≤ 5.4.*
- unaffected 5.10.111 – ≤ 5.10.*
- unaffected 5.15.34 – ≤ 5.15.*
- unaffected 5.16.20 – ≤ 5.16.*
- unaffected 5.17.3 – ≤ 5.17.*
- unaffected 5.18 – ≤ *
References (7)
- https://git.kernel.org/stable/c/596c7efd69aae94f4b0e91172b075eb197958b99 (opens in a new tab)
- https://git.kernel.org/stable/c/55e1465ba79562a191708a40eeae3f8082a209e3 (opens in a new tab)
- https://git.kernel.org/stable/c/fc629224aa62f23849cae83717932985ac51232d (opens in a new tab)
- https://git.kernel.org/stable/c/8a05a6952ecd59aaa62cbdcdaf523ae2c8f436e8 (opens in a new tab)
- https://git.kernel.org/stable/c/234c0132f76f0676d175757f61b0025191a3d935 (opens in a new tab)
- https://git.kernel.org/stable/c/3a8751c0d4e24129e72dcec0139e99833b13904a (opens in a new tab)
- https://git.kernel.org/stable/c/7aa8104a554713b685db729e66511b93d989dd6a (opens in a new tab)
Sources
The same CVE in the primary databases and aggregators, to check against.
- CVE.org record (opens in a new tab)
- CVE List JSON (GitHub) (opens in a new tab)
- NVD (opens in a new tab)
- FIRST EPSS (opens in a new tab)
- OSV.dev (opens in a new tab)
- GitHub Advisories (opens in a new tab)
- CIRCL Vulnerability-Lookup (opens in a new tab)
Badge for a README or a ticket
[](https://trackcve.app/cve/CVE-2022-49073)Record last updated .