cve/published/2025/CVE-2025-22003.mbox

From bippy-7c5fe7eed585 Mon Sep 17 00:00:00 2001
From: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
To: <linux-cve-announce@vger.kernel.org>
Reply-to: <cve@kernel.org>, <linux-kernel@vger.kernel.org>
Subject: CVE-2025-22003: can: ucan: fix out of bound read in strscpy() source

Description
===========

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.

The Linux kernel CVE team has assigned CVE-2025-22003 to this issue.


Affected and fixed versions
===========================

	Issue introduced in 6.2 with commit 7fdaf8966aae476deafe11f9a0067ff588615444 and fixed in 6.6.85 with commit cc29775a8a72d7f3b56cc026796ad99bd65804a7
	Issue introduced in 6.2 with commit 7fdaf8966aae476deafe11f9a0067ff588615444 and fixed in 6.12.21 with commit 8cec9e314d3360fc1d8346297c41a6ee45cb45a9
	Issue introduced in 6.2 with commit 7fdaf8966aae476deafe11f9a0067ff588615444 and fixed in 6.13.9 with commit a4994161a61bc8fd71d105c579d847cefee99262
	Issue introduced in 6.2 with commit 7fdaf8966aae476deafe11f9a0067ff588615444 and fixed in 6.14 with commit 1d22a122ffb116c3cf78053e812b8b21f8852ee9

Please see https://www.kernel.org for a full list of currently supported
kernel versions by the kernel community.

Unaffected versions might change over time as fixes are backported to
older supported kernel versions.  The official CVE entry at
	https://cve.org/CVERecord/?id=CVE-2025-22003
will be updated if fixes are backported, please check that for the most
up to date information about this issue.


Affected files
==============

The file(s) affected by this issue are:
	drivers/net/can/usb/ucan.c


Mitigation
==========

The Linux kernel CVE team recommends that you update to the latest
stable kernel version for this, and many other bugfixes.  Individual
changes are never tested alone, but rather are part of a larger kernel
release.  Cherry-picking individual commits is not recommended or
supported by the Linux kernel community at all.  If however, updating to
the latest release is impossible, the individual changes to resolve this
issue can be found at these commits:
	https://git.kernel.org/stable/c/cc29775a8a72d7f3b56cc026796ad99bd65804a7
	https://git.kernel.org/stable/c/8cec9e314d3360fc1d8346297c41a6ee45cb45a9
	https://git.kernel.org/stable/c/a4994161a61bc8fd71d105c579d847cefee99262
	https://git.kernel.org/stable/c/1d22a122ffb116c3cf78053e812b8b21f8852ee9