CVE-2024-56687

Source
https://nvd.nist.gov/vuln/detail/CVE-2024-56687
Import Source
https://storage.googleapis.com/cve-osv-conversion/osv-output/CVE-2024-56687.json
JSON Data
https://api.osv.dev/v1/vulns/CVE-2024-56687
Downstream
Related
Published
2024-12-28T09:46:14Z
Modified
2025-10-15T20:50:50.358655Z
Severity
  • 5.5 (Medium) CVSS_V3 - CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H CVSS Calculator
Summary
usb: musb: Fix hardware lockup on first Rx endpoint request
Details

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

usb: musb: Fix hardware lockup on first Rx endpoint request

There is a possibility that a request's callback could be invoked from usbepqueue() (call trace below, supplemented with missing calls):

req->complete from usbgadgetgivebackrequest (drivers/usb/gadget/udc/core.c:999) usbgadgetgivebackrequest from musbggiveback (drivers/usb/musb/musbgadget.c:147) musbggiveback from rxstate (drivers/usb/musb/musbgadget.c:784) rxstate from musbeprestart (drivers/usb/musb/musbgadget.c:1169) musbeprestart from musbeprestartresumework (drivers/usb/musb/musbgadget.c:1176) musbeprestartresumework from musbqueueresumework (drivers/usb/musb/musbcore.c:2279) musbqueueresumework from musbgadgetqueue (drivers/usb/musb/musbgadget.c:1241) musbgadgetqueue from usbepqueue (drivers/usb/gadget/udc/core.c:300)

According to the docstring of usbepqueue(), this should not happen:

"Note that @req's ->complete() callback must never be called from within usbepqueue() as that can create deadlock situations."

In fact, a hardware lockup might occur in the following sequence:

  1. The gadget is initialized using musbgadgetenable().
  2. Meanwhile, a packet arrives, and the RXPKTRDY flag is set, raising an interrupt.
  3. If IRQs are enabled, the interrupt is handled, but musbgrx() finds an empty queue (next_request() returns NULL). The interrupt flag has already been cleared by the glue layer handler, but the RXPKTRDY flag remains set.
  4. The first request is enqueued using usbepqueue(), leading to the call of req->complete(), as shown in the call trace above.
  5. If the callback enables IRQs and another packet is waiting, step (3) repeats. The request queue is empty because usbggiveback() removes the request before invoking the callback.
  6. The endpoint remains locked up, as the interrupt triggered by hardware setting the RXPKTRDY flag has been handled, but the flag itself remains set.

For this scenario to occur, it is only necessary for IRQs to be enabled at some point during the complete callback. This happens with the USB Ethernet gadget, whose rxcomplete() callback calls netifrx(). If called in the task context, netifrx() disables the bottom halves (BHs). When the BHs are re-enabled, IRQs are also enabled to allow soft IRQs to be processed. The gadget itself is initialized at module load (or at boot if built-in), but the first request is enqueued when the network interface is brought up, triggering rxcomplete() in the task context via ioctl(). If a packet arrives while the interface is down, it can prevent the interface from receiving any further packets from the USB host.

The situation is quite complicated with many parties involved. This particular issue can be resolved in several possible ways:

  1. Ensure that callbacks never enable IRQs. This would be difficult to enforce, as discovering how netifrx() interacts with interrupts was already quite challenging and uether is not the only function driver. Similar "bugs" could be hidden in other drivers as well.
  2. Disable MUSB interrupts in musbggiveback() before calling the callback and re-enable them afterwars (by calling musb{dis,en}ableinterrupts(), for example). This would ensure that MUSB interrupts are not handled during the callback, even if IRQs are enabled. In fact, it would allow IRQs to be enabled when releasing the lock. However, this feels like an inelegant hack.
  3. Modify the interrupt handler to clear the RXPKTRDY flag if the request queue is empty. While this approach also feels like a hack, it wastes CPU time by attempting to handle incoming packets when the software is not ready to process them.
  4. Flush the Rx FIFO instead of calling rxstate() in musbeprestart(). This ensures that the hardware can receive packets when there is at least one request in the queue. Once I ---truncated---
References

Affected packages

Git / git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git

Affected ranges

Type
GIT
Repo
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
Events
Introduced
baebdf48c360080710f80699eea3affbb13d6c65
Fixed
c749500b28cae67410792096133ee7f282439c51
Type
GIT
Repo
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
Events
Introduced
baebdf48c360080710f80699eea3affbb13d6c65
Fixed
5906ee3693674d734177df13a519a21bb03f730d
Type
GIT
Repo
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
Events
Introduced
baebdf48c360080710f80699eea3affbb13d6c65
Fixed
f05ad9755bb294328c3d0f429164ac6d4d08c548
Type
GIT
Repo
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
Events
Introduced
baebdf48c360080710f80699eea3affbb13d6c65
Fixed
0c89445e6d475b78d37b64ae520831cd43af7db4
Type
GIT
Repo
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
Events
Introduced
baebdf48c360080710f80699eea3affbb13d6c65
Fixed
3fc137386c4620305bbc2a216868c53f9245670a

Affected versions

v5.*

v5.17
v5.17-rc4
v5.17-rc5
v5.17-rc6
v5.17-rc7
v5.17-rc8
v5.18
v5.18-rc1
v5.18-rc2
v5.18-rc3
v5.18-rc4
v5.18-rc5
v5.18-rc6
v5.18-rc7
v5.19
v5.19-rc1
v5.19-rc2
v5.19-rc3
v5.19-rc4
v5.19-rc5
v5.19-rc6
v5.19-rc7
v5.19-rc8

v6.*

v6.0
v6.0-rc1
v6.0-rc2
v6.0-rc3
v6.0-rc4
v6.0-rc5
v6.0-rc6
v6.0-rc7
v6.1
v6.1-rc1
v6.1-rc2
v6.1-rc3
v6.1-rc4
v6.1-rc5
v6.1-rc6
v6.1-rc7
v6.1-rc8
v6.1.1
v6.1.10
v6.1.100
v6.1.101
v6.1.102
v6.1.103
v6.1.104
v6.1.105
v6.1.106
v6.1.107
v6.1.108
v6.1.109
v6.1.11
v6.1.110
v6.1.111
v6.1.112
v6.1.113
v6.1.114
v6.1.115
v6.1.116
v6.1.117
v6.1.118
v6.1.119
v6.1.12
v6.1.13
v6.1.14
v6.1.15
v6.1.16
v6.1.17
v6.1.18
v6.1.19
v6.1.2
v6.1.20
v6.1.21
v6.1.22
v6.1.23
v6.1.24
v6.1.25
v6.1.26
v6.1.27
v6.1.28
v6.1.29
v6.1.3
v6.1.30
v6.1.31
v6.1.32
v6.1.33
v6.1.34
v6.1.35
v6.1.36
v6.1.37
v6.1.38
v6.1.39
v6.1.4
v6.1.40
v6.1.41
v6.1.42
v6.1.43
v6.1.44
v6.1.45
v6.1.46
v6.1.47
v6.1.48
v6.1.49
v6.1.5
v6.1.50
v6.1.51
v6.1.52
v6.1.53
v6.1.54
v6.1.55
v6.1.56
v6.1.57
v6.1.58
v6.1.59
v6.1.6
v6.1.60
v6.1.61
v6.1.62
v6.1.63
v6.1.64
v6.1.65
v6.1.66
v6.1.67
v6.1.68
v6.1.69
v6.1.7
v6.1.70
v6.1.71
v6.1.72
v6.1.73
v6.1.74
v6.1.75
v6.1.76
v6.1.77
v6.1.78
v6.1.79
v6.1.8
v6.1.80
v6.1.81
v6.1.82
v6.1.83
v6.1.84
v6.1.85
v6.1.86
v6.1.87
v6.1.88
v6.1.89
v6.1.9
v6.1.90
v6.1.91
v6.1.92
v6.1.93
v6.1.94
v6.1.95
v6.1.96
v6.1.97
v6.1.98
v6.1.99
v6.10
v6.10-rc1
v6.10-rc2
v6.10-rc3
v6.10-rc4
v6.10-rc5
v6.10-rc6
v6.10-rc7
v6.11
v6.11-rc1
v6.11-rc2
v6.11-rc3
v6.11-rc4
v6.11-rc5
v6.11-rc6
v6.11-rc7
v6.11.1
v6.11.10
v6.11.2
v6.11.3
v6.11.4
v6.11.5
v6.11.6
v6.11.7
v6.11.8
v6.11.9
v6.12
v6.12-rc1
v6.12-rc2
v6.12-rc3
v6.12-rc4
v6.12-rc5
v6.12-rc6
v6.12-rc7
v6.12.1
v6.2
v6.2-rc1
v6.2-rc2
v6.2-rc3
v6.2-rc4
v6.2-rc5
v6.2-rc6
v6.2-rc7
v6.2-rc8
v6.3
v6.3-rc1
v6.3-rc2
v6.3-rc3
v6.3-rc4
v6.3-rc5
v6.3-rc6
v6.3-rc7
v6.4
v6.4-rc1
v6.4-rc2
v6.4-rc3
v6.4-rc4
v6.4-rc5
v6.4-rc6
v6.4-rc7
v6.5
v6.5-rc1
v6.5-rc2
v6.5-rc3
v6.5-rc4
v6.5-rc5
v6.5-rc6
v6.5-rc7
v6.6
v6.6-rc1
v6.6-rc2
v6.6-rc3
v6.6-rc4
v6.6-rc5
v6.6-rc6
v6.6-rc7
v6.6.1
v6.6.10
v6.6.11
v6.6.12
v6.6.13
v6.6.14
v6.6.15
v6.6.16
v6.6.17
v6.6.18
v6.6.19
v6.6.2
v6.6.20
v6.6.21
v6.6.22
v6.6.23
v6.6.24
v6.6.25
v6.6.26
v6.6.27
v6.6.28
v6.6.29
v6.6.3
v6.6.30
v6.6.31
v6.6.32
v6.6.33
v6.6.34
v6.6.35
v6.6.36
v6.6.37
v6.6.38
v6.6.39
v6.6.4
v6.6.40
v6.6.41
v6.6.42
v6.6.43
v6.6.44
v6.6.45
v6.6.46
v6.6.47
v6.6.48
v6.6.49
v6.6.5
v6.6.50
v6.6.51
v6.6.52
v6.6.53
v6.6.54
v6.6.55
v6.6.56
v6.6.57
v6.6.58
v6.6.59
v6.6.6
v6.6.60
v6.6.61
v6.6.62
v6.6.63
v6.6.7
v6.6.8
v6.6.9
v6.7
v6.7-rc1
v6.7-rc2
v6.7-rc3
v6.7-rc4
v6.7-rc5
v6.7-rc6
v6.7-rc7
v6.7-rc8
v6.8
v6.8-rc1
v6.8-rc2
v6.8-rc3
v6.8-rc4
v6.8-rc5
v6.8-rc6
v6.8-rc7
v6.9
v6.9-rc1
v6.9-rc2
v6.9-rc3
v6.9-rc4
v6.9-rc5
v6.9-rc6
v6.9-rc7

Linux / Kernel

Package

Name
Kernel

Affected ranges

Type
ECOSYSTEM
Events
Introduced
5.18.0
Fixed
6.1.120
Type
ECOSYSTEM
Events
Introduced
6.2.0
Fixed
6.6.64
Type
ECOSYSTEM
Events
Introduced
6.7.0
Fixed
6.11.11
Type
ECOSYSTEM
Events
Introduced
6.12.0
Fixed
6.12.2