{"uuid": "6fa5a680-221f-452e-8b0c-f9c7fc86880a", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "2a075640-a300-48a4-bb44-bc6130783b9b", "vulnerability": "CVE-2025-22003", "type": "seen", "source": "https://t.me/cvedetector/21962", "content": "{\n  \"Source\": \"CVE FEED\",\n  \"Title\": \"CVE-2025-22003 - Linux Kernel CAN Ucan Out-of-Bound Read Vulnerability\", \n  \"Content\": \"CVE ID : CVE-2025-22003 \nPublished : April 3, 2025, 8:15 a.m. | 38\u00a0minutes ago \nDescription : In the Linux kernel, the following vulnerability has been resolved:  \n  \ncan: ucan: fix out of bound read in strscpy() source  \n  \nCommit 7fdaf8966aae (\"can: ucan: use strscpy() to instead of strncpy()\")  \nunintentionally introduced a one byte out of bound read on strscpy()'s  \nsource argument (which is kind of ironic knowing that strscpy() is meant  \nto be a more secure alternative :)).  \n  \nLet's consider below buffers:  \n  \n  dest[len + 1]; /* will be NUL terminated */  \n  src[len]; /* may not be NUL terminated */  \n  \nWhen doing:  \n  \n  strncpy(dest, src, len);  \n  dest[len] = '\\0';  \n  \nstrncpy() will read up to len bytes from src.  \n  \nOn the other hand:  \n  \n  strscpy(dest, src, len + 1);  \n  \nwill read up to len + 1 bytes from src, that is to say, an out of bound  \nread of one byte will occur on src if it is not NUL terminated. Note  \nthat the src[len] byte is never copied, but strscpy() still needs to  \nread it to check whether a truncation occurred or not.  \n  \nThis exact pattern happened in ucan.  \n  \nThe root cause is that the source is not NUL terminated. Instead of  \ndoing a copy in a local buffer, directly NUL terminate it as soon as  \nusb_control_msg() returns. With this, the local firmware_str[] variable  \ncan be removed.  \n  \nOn top of this do a couple refactors:  \n  \n  - ucan_ctl_payload->raw is only used for the firmware string, so  \n    rename it to ucan_ctl_payload->fw_str and change its type from u8 to  \n    char.  \n  \n  - ucan_device_request_in() is only used to retrieve the firmware  \n    string, so rename it to ucan_get_fw_str() and refactor it to make it  \n    directly handle all the string termination logic. \nSeverity: 0.0 | NA \nVisit the link for more details, such as CVSS details, affected products, timeline, and more...\",\n  \"Detection Date\": \"03 Apr 2025\",\n  \"Type\": \"Vulnerability\"\n}\n\ud83d\udd39 t.me/cvedetector \ud83d\udd39", "creation_timestamp": "2025-04-03T11:03:21.000000Z"}