Threats Tagged 'cve-2025-38556'

The kernel packages contain the Linux kernel, the core of any Linux operating system. Security Fix(es): * kernel: HID: core: Harden s32ton() against conversion to 0 bits (CVE-2025-38556) * kernel: sctp: linearize cloned gso packets in sctp_rcv (CVE-2025-38718) * kernel: tls: fix handling of zero-length records on the rx_list (CVE-2025-39682) * kernel: ALSA: hda/ca0132: Fix buffer overflow in add_tuning_control (CVE-2025-39751) For more details about the security issue(s), including the impact, a CVSS score, acknowledgments, and other related information, refer to the CVE page(s) listed in the References section.

The kernel-rt packages provide the Real Time Linux Kernel, which enables fine-tuning for systems with extremely high determinism requirements. Security Fix(es): * kernel: HID: core: Harden s32ton() against conversion to 0 bits (CVE-2025-38556) * kernel: sctp: linearize cloned gso packets in sctp_rcv (CVE-2025-38718) * kernel: tls: fix handling of zero-length records on the rx_list (CVE-2025-39682) * kernel: ALSA: hda/ca0132: Fix buffer overflow in add_tuning_control (CVE-2025-39751) For more details about the security issue(s), including the impact, a CVSS score, acknowledgments, and other related information, refer to the CVE page(s) listed in the References section.

In the Linux kernel, the following vulnerability has been resolved: HID: core: Harden s32ton() against conversion to 0 bits Testing by the syzbot fuzzer showed that the HID core gets a shift-out-of-bounds exception when it tries to convert a 32-bit quantity to a 0-bit quantity. Ideally this should never occur, but there are buggy devices and some might have a report field with size set to zero; we shouldn't reject the report or the device just because of that. Instead, harden the s32ton() routine so that it returns a reasonable result instead of crashing when it is called with the number of bits set to 0 -- the same as what snto32() does.

In the Linux kernel, the following vulnerability has been resolved: vsock: Fix transport_* TOCTOU Transport assignment may race with module unload. Protect new_transport from becoming a stale pointer. This also takes care of an insecure call in vsock_use_local_transport(); add a lockdep assert. BUG: unable to handle page fault for address: fffffbfff8056000 Oops: Oops: 0000 [#1] SMP KASAN RIP: 0010:vsock_assign_transport+0x366/0x600 Call Trace: vsock_connect+0x59c/0xc40 __sys_connect+0xe8/0x100 __x64_sys_connect+0x6e/0xc0 do_syscall_64+0x92/0x1c0 entry_SYSCALL_64_after_hwframe+0x4b/0x53