CVE-2025-38480 Affecting kernel-source-coco package, versions <6.4.0-15061.28.coco15sp6.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-KERNELSOURCECOCO-12100264
- published21 Aug 2025
- disclosed20 Aug 2025
Introduced: 20 Aug 2025
CVE-2025-38480 (opens in a new tab)How to fix?
Upgrade SLES:15.6 kernel-source-coco to version 6.4.0-15061.28.coco15sp6.1 or higher.
NVD Description
Note: Versions mentioned in the description apply only to the upstream kernel-source-coco package and not the kernel-source-coco 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:
comedi: Fix use of uninitialized data in insn_rw_emulate_bits()
For Comedi INSN_READ and INSN_WRITE instructions on "digital"
subdevices (subdevice types COMEDI_SUBD_DI, COMEDI_SUBD_DO, and
COMEDI_SUBD_DIO), it is common for the subdevice driver not to have
insn_read and insn_write handler functions, but to have an
insn_bits handler function for handling Comedi INSN_BITS
instructions. In that case, the subdevice's insn_read and/or
insn_write function handler pointers are set to point to the
insn_rw_emulate_bits() function by __comedi_device_postconfig().
For INSN_WRITE, insn_rw_emulate_bits() currently assumes that the
supplied data[0] value is a valid copy from user memory. It will at
least exist because do_insnlist_ioctl() and do_insn_ioctl() in
"comedi_fops.c" ensure at lease MIN_SAMPLES (16) elements are
allocated. However, if insn->n is 0 (which is allowable for
INSN_READ and INSN_WRITE instructions, then data[0] may contain
uninitialized data, and certainly contains invalid data, possibly from a
different instruction in the array of instructions handled by
do_insnlist_ioctl(). This will result in an incorrect value being
written to the digital output channel (or to the digital input/output
channel if configured as an output), and may be reflected in the
internal saved state of the channel.
Fix it by returning 0 early if insn->n is 0, before reaching the code
that accesses data[0]. Previously, the function always returned 1 on
success, but it is supposed to be the number of data samples actually
read or written up to insn->n, which is 0 in this case.
References
- https://www.suse.com/security/cve/CVE-2025-38480.html
- https://bugzilla.suse.com/1247274
- https://git.kernel.org/stable/c/10f9024a8c824a41827fff1fefefb314c98e2c88
- https://git.kernel.org/stable/c/2af1e7d389c2619219171d23f5b96dbcbb7f9656
- https://git.kernel.org/stable/c/3050d197d6bc9ef128944a70210f42d2430b3000
- https://git.kernel.org/stable/c/3ab55ffaaf75d0c7b68e332c1cdcc1b0e0044870
- https://git.kernel.org/stable/c/e9cb26291d009243a4478a7ffb37b3a9175bfce9
- https://git.kernel.org/stable/c/16256d7efcf7acc9f39abe21522c4c6b77f67c00
- https://git.kernel.org/stable/c/4c2981bf30401adfcdbfece4ab6f411f7c5875a1
- https://git.kernel.org/stable/c/c53570e62b5b28bdb56bb563190227f8307817a5