"value":"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's \"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 <CE,ME> 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's next neighbour \"chan\" (a *dma_chan struct) in\nthis '32' case right here (line ~735):\n> hsdevp->dma_pending[tag] = SATA_DWC_DMA_PENDING_NONE;\n\nThen the next time, a dma gets issued; dma_dwc_xfer_setup() passes\nthe NULL'd hsdevp->chan 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's 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"
"value":"En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ata: sata_dwc_460ex: Se corrige un fallo debido a que el controlador usa valores de \"etiqueta\" de libata en varias matrices debido a que la correcci\u00f3n mencionada aument\u00f3 ATA_TAG_INTERNAL a 32. Por lo tanto, el valor de SATA_DWC_QCMD_MAX debe tenerlo en cuenta. De lo contrario, el uso de ATA_TAG_INTERNAL causa fallos similares a este, seg\u00fan lo informado por Tice Rex en el foro OpenWrt y reproducido (con s\u00edmbolos) aqu\u00ed: | ERROR: Desreferencia de puntero NULL del kernel en 0x00000000 | Direcci\u00f3n de instrucci\u00f3n con error: 0xc03ed4b8 | Vaya: Acceso del kernel a un \u00e1rea incorrecta, firma: 11 [#1] | BE PAGE_SIZE=4K PowerPC 44x Platform | CPU: 0 PID: 362 Comm: scsi_eh_1 No contaminado 5.4.163 #0 | NIP: c03ed4b8 LR: c03d27e8 CTR: c03ed36c | REGS: cfa59950 TRAP: 0300 No contaminado (5.4.163) | MSR: 00021000 CR: 42000222 XER: 00000000 | DEAR: 00000000 ESR: 00000000 | GPR00: c03d27e8 cfa59a08 cfa55fe0 00000000 0fa46bc0 [...] | [..] | Rastreo de llamadas: | [cfa59a08] [c003f4e0] __cancel_work_timer+0x124/0x194 (no confiable) | [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 | [...] Esto se debe a que sata_dwc_dma_xfer_complete() convierte en NULL el pr\u00f3ximo vecino \"chan\" de dma_pending (una estructura *dma_chan) en este caso '32' aqu\u00ed mismo (l\u00ednea ~735): > hsdevp->dma_pending[tag] = SATA_DWC_DMA_PENDING_NONE; Luego, la pr\u00f3xima vez que se emite un dma; dma_dwc_xfer_setup() pasa el hsdevp->chan convertido en NULL a dmaengine_slave_config() que luego causa el bloqueo. Con este parche, SATA_DWC_QCMD_MAX ahora est\u00e1 configurado en ATA_MAX_QUEUE + 1. Esto evita el OOB. Pero tenga en cuenta que hubo una discusi\u00f3n valiosa sobre qu\u00e9 son ATA_TAG_INTERNAL y ATA_MAX_QUEUE. Y por qu\u00e9 no deber\u00eda haber un tama\u00f1o de cola \"falso\" de 33 comandos. Idealmente, el controlador dw deber\u00eda tener en cuenta ATA_TAG_INTERNAL. En palabras de Damien Le Moal: \"... despu\u00e9s de observar el controlador, es un cambio m\u00e1s grande que simplemente falsificar una \"etiqueta\" n\u00famero 33 que, de hecho, no es una etiqueta de comando en absoluto\". Enlace de error: https://github.com/openwrt/openwrt/issues/9505"
