CVE-2022-49073

Vulnérabilité élevée dans Linux (Linux)

CVSS 7.8 · Élevée
EPSS 0.3%
Linux•Linux•Versions : <=5.17.*, <8a05a6952ecd59aaa62cbdcdaf523ae2c8f436e8, 5.18, 5.15.34, <596c7efd69aae94f4b0e91172b075eb197958b99, 0, <7aa8104a554713b685db729e66511b93d989dd6a, 5.16.20, <=5.10.*, 5.17.3, 28361c403683c2b00d4f5e76045f3ccd299bf99d, 5.4.189, <=5.4.*, <=4.19.*, 5.10.111, <3a8751c0d4e24129e72dcec0139e99833b13904a, <=5.16.*, <55e1465ba79562a191708a40eeae3f8082a209e3, <fc629224aa62f23849cae83717932985ac51232d, <4.18, 4.18, <=*, 4.19.238, <=5.15.*, <234c0132f76f0676d175757f61b0025191a3d935

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

Gravité et risque d'exploitation

CVE-2022-49073 obtient un score CVSS de 7.8/10, soit une gravité élevée. Selon le modèle EPSS, la probabilité qu'elle soit exploitée dans les 30 prochains jours est de 0.28 %, ce qui la place devant 18.9 % des CVE référencées.

Que faire ?

  • Vérifiez si Linux (versions <=5.17.*, <8a05a6952ecd59aaa62cbdcdaf523ae2c8f436e8, 5.18, 5.15.34, <596c7efd69aae94f4b0e91172b075eb197958b99, 0, <7aa8104a554713b685db729e66511b93d989dd6a, 5.16.20, <=5.10.*, 5.17.3, 28361c403683c2b00d4f5e76045f3ccd299bf99d, 5.4.189, <=5.4.*, <=4.19.*, 5.10.111, <3a8751c0d4e24129e72dcec0139e99833b13904a, <=5.16.*, <55e1465ba79562a191708a40eeae3f8082a209e3, <fc629224aa62f23849cae83717932985ac51232d, <4.18, 4.18, <=*, 4.19.238, <=5.15.*, <234c0132f76f0676d175757f61b0025191a3d935) est présent sur votre parc.
  • Appliquez le correctif ou la version corrigée indiqués dans les références de l'éditeur.
  • À défaut de correctif, limitez l'exposition (filtrage réseau, désactivation du composant).
  • Automatisez la détection : les agents CVE Heimdall (gratuits, open source) corrèlent l'inventaire de vos serveurs avec la base CVE.

Références