CVE-2022-49073

In the Linux kernel, the following vulnerability has been resolved:

ata: satadwc460ex: Fix crash due to OOB write

the driver uses libata's "tag" values from in various arrays. Since the mentioned patch bumped the ATATAGINTERNAL to 32, the value of the SATADWCQCMD_MAX needs to account for that.

Otherwise ATATAGINTERNAL 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 PAGESIZE=4K PowerPC 44x Platform | CPU: 0 PID: 362 Comm: scsieh1 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] satadwcqcissue+0x14c/0x254 | LR [c03d27e8] ataqcissue+0x1c8/0x2dc | Call Trace: | [cfa59a08] [c003f4e0] _cancelworktimer+0x124/0x194 (unreliable) | [cfa59a78] [c03d27e8] ataqcissue+0x1c8/0x2dc | [cfa59a98] [c03d2b3c] ataexecinternalsg+0x240/0x524 | [cfa59b08] [c03d2e98] ataexecinternal+0x78/0xe0 | [cfa59b58] [c03d30fc] atareadlogpage.part.38+0x1dc/0x204 | [cfa59bc8] [c03d324c] ataidentifypagesupported+0x68/0x130 | [...]

This is because satadwcdmaxfercomplete() NULLs the dmapending's next neighbour "chan" (a *dmachan struct) in this '32' case right here (line ~735):

hsdevp->dmapending[tag] = SATADWCDMAPENDING_NONE;

Then the next time, a dma gets issued; dmadwcxfersetup() passes the NULL'd hsdevp->chan to the dmaengineslave_config() which then causes the crash.

With this patch, SATADWCQCMDMAX is now set to ATAMAXQUEUE + 1. This avoids the OOB. But please note, there was a worthwhile discussion on what ATATAGINTERNAL and ATAMAX_QUEUE is. And why there should not be a "fake" 33 command-long queue size.

Ideally, the dw driver should account for the ATATAGINTERNAL. 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