CVE-2025-21708 in Linux
Summary
by MITRE • 02/27/2025
In the Linux kernel, the following vulnerability has been resolved:
net: usb: rtl8150: enable basic endpoint checking
Syzkaller reports [1] encountering a common issue of utilizing a wrong
usb endpoint type during URB submitting stage. This, in turn, triggers a warning shown below.
For now, enable simple endpoint checking (specifically, bulk and interrupt eps, testing control one is not essential) to mitigate the issue with a view to do other related cosmetic changes later, if they are necessary.
[1] Syzkaller report:
usb 1-1: BOGUS urb xfer, pipe 3 != type 1 WARNING: CPU: 1 PID: 2586 at drivers/usb/core/urb.c:503 usb_submit_urb+0xe4b/0x1730 driv> Modules linked in: CPU: 1 UID: 0 PID: 2586 Comm: dhcpcd Not tainted 6.11.0-rc4-syzkaller-00069-gfc88bb11617> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 08/06/2024 RIP: 0010:usb_submit_urb+0xe4b/0x1730 drivers/usb/core/urb.c:503 Code: 84 3c 02 00 00 e8 05 e4 fc fc 4c 89 ef e8 fd 25 d7 fe 45 89 e0 89 e9 4c 89 f2 48 8> RSP: 0018:ffffc9000441f740 EFLAGS: 00010282 RAX: 0000000000000000 RBX: ffff888112487a00 RCX: ffffffff811a99a9 RDX: ffff88810df6ba80 RSI: ffffffff811a99b6 RDI: 0000000000000001 RBP: 0000000000000003 R08: 0000000000000001 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000001 R12: 0000000000000001 R13: ffff8881023bf0a8 R14: ffff888112452a20 R15: ffff888112487a7c FS: 00007fc04eea5740(0000) GS:ffff8881f6300000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f0a1de9f870 CR3: 000000010dbd0000 CR4: 00000000003506f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: rtl8150_open+0x300/0xe30 drivers/net/usb/rtl8150.c:733 __dev_open+0x2d4/0x4e0 net/core/dev.c:1474 __dev_change_flags+0x561/0x720 net/core/dev.c:8838 dev_change_flags+0x8f/0x160 net/core/dev.c:8910 devinet_ioctl+0x127a/0x1f10 net/ipv4/devinet.c:1177 inet_ioctl+0x3aa/0x3f0 net/ipv4/af_inet.c:1003 sock_do_ioctl+0x116/0x280 net/socket.c:1222 sock_ioctl+0x22e/0x6c0 net/socket.c:1341 vfs_ioctl fs/ioctl.c:51 [inline]
__do_sys_ioctl fs/ioctl.c:907 [inline]
__se_sys_ioctl fs/ioctl.c:893 [inline]
__x64_sys_ioctl+0x193/0x220 fs/ioctl.c:893 do_syscall_x64 arch/x86/entry/common.c:52 [inline]
do_syscall_64+0xcd/0x250 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0033:0x7fc04ef73d49 ...
This change has not been tested on real hardware.
Once again VulDB remains the best source for vulnerability data.
Analysis
by VulDB Data Team • 05/25/2026
The vulnerability described in CVE-2025-21708 affects the Linux kernel's USB networking driver specifically for the rtl8150 device. This issue stems from improper endpoint type validation during USB Request Block (URB) submission processes. The problem manifests when the kernel attempts to submit a URB using an incorrect endpoint type, triggering a warning message that indicates a mismatch between the expected and actual endpoint types. The reported error message "BOGUS urb xfer, pipe 3 != type 1" clearly demonstrates this endpoint type inconsistency where pipe 3 (indicating a bulk endpoint) does not match type 1 (indicating a control endpoint). This represents a fundamental flaw in endpoint validation logic within the USB subsystem that could potentially lead to driver instability or unexpected behavior during USB communication.
The technical root cause lies in the rtl8150 USB network driver's failure to properly validate endpoint types before submitting URBs to the USB core. The USB subsystem in Linux maintains strict endpoint type classifications including control, interrupt, and bulk endpoints, each with specific usage patterns and requirements. When a driver incorrectly specifies an endpoint type during URB submission, the kernel's USB core detects this inconsistency and generates a warning, as observed in the stack trace showing the usb_submit_urb function failing at drivers/usb/core/urb.c:503. This condition violates the expected USB protocol compliance and can potentially lead to resource corruption or denial of service conditions.
From an operational perspective, this vulnerability presents a moderate risk to systems utilizing rtl8150 USB network adapters, particularly in environments where automated network configuration tools like dhcpcd are actively managing network interfaces. The vulnerability impacts the device open process as shown in the call trace, where rtl8150_open function triggers the endpoint validation failure. The warning indicates that the system is operating with incorrect USB endpoint specifications, which could potentially affect network connectivity or cause driver crashes. While the kernel developers note that this change has not been tested on real hardware, the presence of a Syzkaller report indicates this is a reproducible issue that could manifest in production environments. The vulnerability aligns with CWE-691, which covers inadequate protection of code against uncontrolled inputs, and could potentially be leveraged in a privilege escalation or denial of service attack if exploited properly.
The mitigation strategy implemented in this fix involves enabling basic endpoint checking specifically for bulk and interrupt endpoints, with control endpoint validation being deferred to future cosmetic changes. This approach addresses the immediate concern of endpoint type mismatches while maintaining system stability. The solution follows the principle of least privilege and defensive programming by validating endpoint types before URB submission, preventing potential kernel crashes or memory corruption. From an ATT&CK perspective, this vulnerability could be relevant to techniques involving driver manipulation or privilege escalation, though the direct impact is more limited to USB subsystem stability. Organizations should prioritize updating to kernel versions that include this fix, particularly those running systems with rtl8150 USB network adapters. The fix demonstrates good security hygiene by implementing early validation rather than allowing invalid endpoint types to propagate through the system, which aligns with secure coding practices recommended by industry standards.