Out-of-bounds Read Affecting kernel-obs-build package, versions <6.4.0-150600.23.50.1
Threat Intelligence
The probability is the direct output of the EPSS model, and conveys an overall sense of the threat of exploitation in the wild. The percentile measures the EPSS probability relative to all known EPSS scores. Note: This data is updated daily, relying on the latest available EPSS model version. Check out the EPSS documentation for more details.
Do your applications use this vulnerable package?
In a few clicks we can analyze your entire application and see what components are vulnerable in your application, and suggest you quick fixes.
Test your applications- Snyk IDSNYK-SLES156-KERNELOBSBUILD-10227376
- published22 May 2025
- disclosed21 May 2025
Introduced: 21 May 2025
NewCVE-2025-22003 (opens in a new tab)How to fix?
Upgrade SLES:15.6 kernel-obs-build to version 6.4.0-150600.23.50.1 or higher.
NVD Description
Note: Versions mentioned in the description apply only to the upstream kernel-obs-build package and not the kernel-obs-build package as distributed by SLES.
See How to fix? for SLES:15.6 relevant fixed versions and status.
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.
References
- https://www.suse.com/security/cve/CVE-2025-22003.html
- https://bugzilla.suse.com/1240825
- 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