CVE-2025-21630

See a problem?
Please try reporting it to the source first.
Source
https://nvd.nist.gov/vuln/detail/CVE-2025-21630
Import Source
https://storage.googleapis.com/osv-test-cve-osv-conversion/osv-output/CVE-2025-21630.json
JSON Data
https://api.test.osv.dev/v1/vulns/CVE-2025-21630
Related
Withdrawn
2025-01-17T11:40:32.707169Z
Published
2025-01-15T13:15:15Z
Modified
2025-01-16T05:50:43.354409Z
Summary
[none]
Details

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

iouring/net: always initialize kmsg->msg.msginq upfront

syzbot reports that ->msg_inq may get used uinitialized from the following path:

BUG: KMSAN: uninit-value in iorecvbufselect iouring/net.c:1094 [inline] BUG: KMSAN: uninit-value in iorecv+0x930/0x1f90 iouring/net.c:1158 iorecvbufselect iouring/net.c:1094 [inline] iorecv+0x930/0x1f90 iouring/net.c:1158 ioissuesqe+0x420/0x2130 iouring/iouring.c:1740 ioqueuesqe iouring/iouring.c:1950 [inline] ioreqtasksubmit+0xfa/0x1d0 iouring/iouring.c:1374 iohandletwlist+0x55f/0x5c0 iouring/iouring.c:1057 tctxtaskworkrun+0x109/0x3e0 iouring/iouring.c:1121 tctxtaskwork+0x6d/0xc0 iouring/iouring.c:1139 taskworkrun+0x268/0x310 kernel/taskwork.c:239 ioruntaskwork+0x43a/0x4a0 iouring/iouring.h:343 iocqringwait iouring/iouring.c:2527 [inline] _dosysiouringenter iouring/iouring.c:3439 [inline] _sesysiouringenter+0x204f/0x4ce0 iouring/iouring.c:3330 _x64sysiouringenter+0x11f/0x1a0 iouring/iouring.c:3330 x64syscall+0xce5/0x3c30 arch/x86/include/generated/asm/syscalls64.h:427 dosyscallx64 arch/x86/entry/common.c:52 [inline] dosyscall64+0xcd/0x1e0 arch/x86/entry/common.c:83 entrySYSCALL64after_hwframe+0x77/0x7f

and it is correct, as it's never initialized upfront. Hence the first submission can end up using it uninitialized, if the recv wasn't successful and the networking stack didn't honor ->msggetinq being set and filling in the output value of ->msg_inq as requested.

Set it to 0 upfront when it's allocated, just to silence this KMSAN warning. There's no side effect of using it uninitialized, it'll just potentially cause the next receive to use a recv value hint that's not accurate.

References

Affected packages

Debian:13 / linux

Package

Name
linux
Purl
pkg:deb/debian/linux?arch=source

Affected ranges

Type
ECOSYSTEM
Events
Introduced
0Unknown introduced version / All previous versions are affected
Fixed
6.12.9-1

Affected versions

6.*

6.1.27-1
6.1.37-1
6.1.38-1
6.1.38-2~bpo11+1
6.1.38-2
6.1.38-3
6.1.38-4~bpo11+1
6.1.38-4
6.1.52-1
6.1.55-1~bpo11+1
6.1.55-1
6.1.64-1
6.1.66-1
6.1.67-1
6.1.69-1~bpo11+1
6.1.69-1
6.1.76-1~bpo11+1
6.1.76-1
6.1.82-1
6.1.85-1
6.1.90-1~bpo11+1
6.1.90-1
6.1.94-1~bpo11+1
6.1.94-1
6.1.98-1
6.1.99-1
6.1.106-1
6.1.106-2
6.1.106-3
6.1.112-1
6.1.115-1
6.1.119-1
6.1.123-1
6.1.124-1
6.3.1-1~exp1
6.3.2-1~exp1
6.3.4-1~exp1
6.3.5-1~exp1
6.3.7-1~bpo12+1
6.3.7-1
6.3.11-1
6.4~rc6-1~exp1
6.4~rc7-1~exp1
6.4.1-1~exp1
6.4.4-1~bpo12+1
6.4.4-1
6.4.4-2
6.4.4-3~bpo12+1
6.4.4-3
6.4.11-1
6.4.13-1
6.5~rc4-1~exp1
6.5~rc6-1~exp1
6.5~rc7-1~exp1
6.5.1-1~exp1
6.5.3-1~bpo12+1
6.5.3-1
6.5.6-1
6.5.8-1
6.5.10-1~bpo12+1
6.5.10-1
6.5.13-1
6.6.3-1~exp1
6.6.4-1~exp1
6.6.7-1~exp1
6.6.8-1
6.6.9-1
6.6.11-1
6.6.13-1~bpo12+1
6.6.13-1
6.6.15-1
6.6.15-2
6.7-1~exp1
6.7.1-1~exp1
6.7.4-1~exp1
6.7.7-1
6.7.9-1
6.7.9-2
6.7.12-1~bpo12+1
6.7.12-1
6.8.9-1
6.8.11-1
6.8.12-1~bpo12+1
6.8.12-1
6.9.2-1~exp1
6.9.7-1~bpo12+1
6.9.7-1
6.9.8-1
6.9.9-1
6.9.10-1~bpo12+1
6.9.10-1
6.9.11-1
6.9.12-1
6.10-1~exp1
6.10.1-1~exp1
6.10.3-1
6.10.4-1
6.10.6-1~bpo12+1
6.10.6-1
6.10.7-1
6.10.9-1
6.10.11-1~bpo12+1
6.10.11-1
6.10.12-1
6.11~rc4-1~exp1
6.11~rc5-1~exp1
6.11-1~exp1
6.11.2-1
6.11.4-1
6.11.5-1~bpo12+1
6.11.5-1
6.11.6-1
6.11.7-1
6.11.9-1
6.11.10-1~bpo12+1
6.11.10-1
6.12~rc6-1~exp1
6.12.3-1
6.12.5-1
6.12.6-1
6.12.8-1

Ecosystem specific 

{
    "urgency": "not yet assigned"
}