In the Linux kernel, the following vulnerability has been resolved:
nouveau/dpcd: return EBUSY for aux xfer if the device is asleep
If we have runtime suspended, and userspace wants to use /dev/drm_dp_*
then just tell it the device is busy instead of crashing in the GSP
code.
WARNING: CPU: 2 PID: 565741 at drivers/gpu/drm/nouveau/nvkm/subdev/gsp/rm/r535/rpc.c:164 r535_gsp_msgq_wait+0x9a/0xb0 [nouveau]
CPU: 2 UID: 0 PID: 565741 Comm: fwupd Not tainted 6.18.10-200.fc43.x86_64 #1 PREEMPT(lazy)
Hardware name: LENOVO 20QTS0PQ00/20QTS0PQ00, BIOS N2OET65W (1.52 ) 08/05/2024
RIP: 0010:r535_gsp_msgq_wait+0x9a/0xb0 [nouveau]
This is a simple fix to get backported. We should probably engineer a
proper power domain solution to wake up devices and keep them awake
while fw updates are happening.
CVSS
5.5 MEDIUM (v3.1, NVD)CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
8894f4919bc43f821775db2cfff4b917871b2102 builds before 178df7c91e6c202579284df9f79d1592a514cdcf; 8894f4919bc43f821775db2cfff4b917871b2102 builds before 4df518aa196085909fd7e32518ecd27fba60ed69; from 8894f4919bc43f821775db2cfff4b917871b2102 before cd24cab2023aa46b595bc6b9cc39d8973d9d0a8c; from 8894f4919bc43f821775db2cfff4b917871b2102 before fad178ae894930520519ead3c8e0150641466360; 8894f4919bc43f821775db2cfff4b917871b2102 builds before 6bdd2d70c338d52c387d3b3aadc596784ae81b01; from 8894f4919bc43f821775db2cfff4b917871b2102 before ad8fa5bff53f5d1f8394f996850da8ce070eaee3; from 8894f4919bc43f821775db2cfff4b917871b2102 before 24639553a016578222ac597db924dfb6fa5ec8b5; 8894f4919bc43f821775db2cfff4b917871b2102 builds before 8f3c6f08ababad2e3bdd239728cf66a9949446b4
from 3.16 before 5.10.253; from 5.11 before 5.15.203; from 5.16 before 6.1.167; from 6.2 before 6.6.130; from 6.7 before 6.12.78; from 6.13 before 6.18.19; from 6.19 before 6.19.9; 7.0; and 1 more ranges
The CVE record is authoritative. Products marked “from the name” were identified from the CNA's free-text names, not a CPE, and are matched less certainly. This product uses the NVD API but is not endorsed or certified by the NVD.
Printed from infosecsignals.com. Every record links back to the agency that published it.
Your cookie choices
We use essential cookies to run this site, and, only with your consent, an advertising cookie from Google to measure whether our ads lead to sign-ups and subscriptions. See our for details.