UBUNTU-CVE-2025-22003
In the Linux kernel, the following vulnerability has been resolved: can: ucan: fix out of bound read in strscpy() source Commit 7fdaf8966aae ("can: ucan: use strscpy() to instead of strncpy()") unintentionally introduced a one byte out of bound read on strscpy()'s source argument (which is kind of ironic knowing that strscpy() is meant to be a more secure alternative :)). Let's consider below buffers: dest[len + 1]; /* will be NUL terminated */ src[len]; /* may not be NUL terminated */ When doing: strncpy(dest, src, len); dest[len] = '\0'; strncpy() will read up to len bytes from src. On the other hand: strscpy(dest, src, len + 1); will read up to len + 1 bytes from src, that is to say, an out of bound read of one byte will occur on src if it is not NUL terminated. Note that the src[len] byte is never copied, but strscpy() still needs to read it to check whether a truncation occurred or not. This exact pattern happened in ucan. The root cause is that the source is not NUL terminated. Instead of doing a copy in a local buffer, directly NUL terminate it as soon as usb_control_msg() returns. With this, the local firmware_str[] variable can be removed. On top of this do a couple refactors: - ucan_ctl_payload->raw is only used for the firmware string, so rename it to ucan_ctl_payload->fw_str and change its type from u8 to char. - ucan_device_request_in() is only used to retrieve the firmware string, so rename it to ucan_get_fw_str() and refactor it to make it directly handle all the string termination logic.
02 / AFFECTED SOFTWARE
Affected packages
29 explicit affected versions
10 explicit affected versions
11 explicit affected versions
3 explicit affected versions
1 explicit affected versions
3 explicit affected versions
7 explicit affected versions
26 explicit affected versions
26 explicit affected versions
37 explicit affected versions
10 explicit affected versions
10 explicit affected versions
13 explicit affected versions
13 explicit affected versions
8 explicit affected versions
78 explicit affected versions
45 explicit affected versions
37 explicit affected versions
8 explicit affected versions
4 explicit affected versions
8 explicit affected versions
19 explicit affected versions
24 explicit affected versions
23 explicit affected versions
7 explicit affected versions
34 explicit affected versions
10 explicit affected versions
32 explicit affected versions
33 explicit affected versions
31 explicit affected versions
16 explicit affected versions
13 explicit affected versions
4 explicit affected versions
12 explicit affected versions
5 explicit affected versions
38 explicit affected versions
51 explicit affected versions
13 explicit affected versions
6 explicit affected versions
25 explicit affected versions
10 explicit affected versions
10 explicit affected versions
26 explicit affected versions
13 explicit affected versions
25 explicit affected versions
1 explicit affected versions
31 explicit affected versions
10 explicit affected versions
10 explicit affected versions
1 explicit affected versions
19 explicit affected versions
8 explicit affected versions
13 explicit affected versions
21 explicit affected versions
6 explicit affected versions
13 explicit affected versions
12 explicit affected versions
24 explicit affected versions
18 explicit affected versions
7 explicit affected versions
14 explicit affected versions
25 explicit affected versions
21 explicit affected versions
12 explicit affected versions
26 explicit affected versions
1 explicit affected versions
20 explicit affected versions
3 explicit affected versions
23 explicit affected versions
24 explicit affected versions
14 explicit affected versions
5 explicit affected versions
30 explicit affected versions
3 explicit affected versions
26 explicit affected versions
12 explicit affected versions
44 explicit affected versions
4 explicit affected versions
4 explicit affected versions
16 explicit affected versions
9 explicit affected versions
12 explicit affected versions
29 explicit affected versions
13 explicit affected versions
5 explicit affected versions
7 explicit affected versions
6 explicit affected versions
5 explicit affected versions
13 explicit affected versions
7 explicit affected versions
6 explicit affected versions
10 explicit affected versions
14 explicit affected versions
18 explicit affected versions
3 explicit affected versions
16 explicit affected versions
1 explicit affected versions
43 explicit affected versions
30 explicit affected versions
11 explicit affected versions
36 explicit affected versions
35 explicit affected versions
23 explicit affected versions
35 explicit affected versions
12 explicit affected versions
13 explicit affected versions
28 explicit affected versions
4 explicit affected versions
6 explicit affected versions
12 explicit affected versions
15 explicit affected versions
50 explicit affected versions
26 explicit affected versions
11 explicit affected versions
12 explicit affected versions
26 explicit affected versions
27 explicit affected versions
27 explicit affected versions
12 explicit affected versions
7 explicit affected versions
03 / CONNECTIONS
Connected vulnerabilities
04 / EVIDENCE
Source records
In the Linux kernel, the following vulnerability has been resolved: can: ucan: fix out of bound read in strscpy() source Commit 7fdaf8966aae ("can: ucan: use strscpy() to instead of strncpy()") unintentionally introduced a one byte out of bound read on strscpy()'s source argument (which is kind of ironic knowing that strscpy() is meant to be a more secure alternative :)). Let's consider below buffers: dest[len + 1]; /* will be NUL terminated */ src[len]; /* may not be NUL terminated */ When doing: strncpy(dest, src, len); dest[len] = '\0'; strncpy() will read up to len bytes from src. On the other hand: strscpy(dest, src, len + 1); will read up to len + 1 bytes from src, that is to say, an out of bound read of one byte will occur on src if it is not NUL terminated. Note that the src[len] byte is never copied, but strscpy() still needs to read it to check whether a truncation occurred or not. This exact pattern happened in ucan. The root cause is that the source is not NUL terminated. Instead of doing a copy in a local buffer, directly NUL terminate it as soon as usb_control_msg() returns. With this, the local firmware_str[] variable can be removed. On top of this do a couple refactors: - ucan_ctl_payload->raw is only used for the firmware string, so rename it to ucan_ctl_payload->fw_str and change its type from u8 to char. - ucan_device_request_in() is only used to retrieve the firmware string, so rename it to ucan_get_fw_str() and refactor it to make it directly handle all the string termination logic.
05 / REFERENCES
Further evidence
- https://git.kernel.org/linus/1d22a122ffb116c3cf78053e812b8b21f8852ee9
- https://git.kernel.org/stable/c/1d22a122ffb116c3cf78053e812b8b21f8852ee9
- https://git.kernel.org/stable/c/8cec9e314d3360fc1d8346297c41a6ee45cb45a9
- https://git.kernel.org/stable/c/a4994161a61bc8fd71d105c579d847cefee99262
- https://git.kernel.org/stable/c/cc29775a8a72d7f3b56cc026796ad99bd65804a7
- https://ubuntu.com/security/CVE-2025-22003
- https://ubuntu.com/security/notices/USN-7605-1
- https://ubuntu.com/security/notices/USN-7605-2
- https://ubuntu.com/security/notices/USN-7606-1
- https://ubuntu.com/security/notices/USN-7628-1
- https://ubuntu.com/security/notices/USN-7764-1
- https://ubuntu.com/security/notices/USN-7764-2
- https://ubuntu.com/security/notices/USN-7765-1
- https://ubuntu.com/security/notices/USN-7766-1
- https://ubuntu.com/security/notices/USN-7767-1
- https://ubuntu.com/security/notices/USN-7767-2
- https://ubuntu.com/security/notices/USN-7779-1
- https://ubuntu.com/security/notices/USN-7790-1
- https://ubuntu.com/security/notices/USN-7800-1
- https://ubuntu.com/security/notices/USN-7801-1
- https://ubuntu.com/security/notices/USN-7801-2
- https://ubuntu.com/security/notices/USN-7801-3
- https://ubuntu.com/security/notices/USN-7802-1
- https://ubuntu.com/security/notices/USN-7809-1
- https://www.cve.org/CVERecord?id=CVE-2025-22003