https://cve.radiocsirt.org Contains only the most 10 recent entries. http://www.rssboard.org/rss-specification python-feedgen en Wed, 14 Oct 2026 23:02:49 +0000 https://cve.radiocsirt.org/vuln/cve-2025-39682 <p><strong>Affected:</strong> Linux, Siemens SIMATIC CN 4100</p> <p>In the Linux kernel, the following vulnerability has been resolved:</p> <p>tls: fix handling of zero-length records on the rx_list</p> <p>Each recvmsg() call must process either - only contiguous DATA records (any number of them) - one non-DATA record</p> <p>If the next record has different type than what has already been processed we break out of the main processing loop. If the record has already been decrypted (which may be the case for TLS 1.3 where we don&#39;t know type until decryption) we queue the pending record to the rx_list. Next recvmsg() will pick it up from there.</p> <p>Queuing the skb to rx_list after zero-copy decrypt is not possible, since in that case we decrypted directly to the user space buffer, and we don&#39;t have an skb to queue (darg.skb points to the ciphertext skb for access to metadata like length).</p> <p>Only data records are allowed zero-copy, and we break the processing loop after each non-data record. So we should never zero-copy and then find out that the record type has changed. The corner case we missed is when the initial record comes from rx_list, and it&#39;s zero length.</p> <p><strong>Affected:</strong> Linux, Siemens SIMATIC CN 4100</p> <p>In the Linux kernel, the following vulnerability has been resolved:</p> <p>tls: fix handling of zero-length records on the rx_list</p> <p>Each recvmsg() call must process either - only contiguous DATA records (any number of them) - one non-DATA record</p> <p>If the next record has different type than what has already been processed we break out of the main processing loop. If the record has already been decrypted (which may be the case for TLS 1.3 where we don&#39;t know type until decryption) we queue the pending record to the rx_list. Next recvmsg() will pick it up from there.</p> <p>Queuing the skb to rx_list after zero-copy decrypt is not possible, since in that case we decrypted directly to the user space buffer, and we don&#39;t have an skb to queue (darg.skb points to the ciphertext skb for access to metadata like length).</p> <p>Only data records are allowed zero-copy, and we break the processing loop after each non-data record. So we should never zero-copy and then find out that the record type has changed. The corner case we missed is when the initial record comes from rx_list, and it&#39;s zero length.</p> https://cve.radiocsirt.org/vuln/cve-2025-39682 https://cve.radiocsirt.org/vuln/usn-7833-1 <p><strong>Affected:</strong> Ubuntu:24.04:LTS: linux-oem-6.14, Ubuntu:24.04:LTS: linux-oracle-6.14</p> <p>Oleksii Oleksenko, Cedric Fournet, Jana Hofmann, Boris Köpf, Stavros Volos, and Flavien Solt discovered that some AMD processors may allow an attacker to infer data from previous stores, potentially resulting in the leakage of privileged information. A local attacker could possibly use this to expose sensitive information. (CVE-2024-36350, CVE-2024-36357)</p> <p>Several security issues were discovered in the Linux kernel. An attacker could possibly use these to compromise the system. This update corrects flaws in the following subsystems: - ARM64 architecture; - PowerPC architecture; - RISC-V architecture; - S390 architecture; - x86 architecture; - ACPI drivers; - Serial ATA and Parallel ATA drivers; - Drivers core; - ATA over ethernet (AOE) driver; - Ublk userspace block driver; - Bus devices; - DMA engine subsystem; - Arm Firmware Framework for ARMv8-A(FFA); - Cirrus firmware drivers; - GPU drivers; - HID subsystem; - Hardware monitoring drivers; - I2C subsystem; - InfiniBand drivers; - Input Device (Miscellaneous) drivers; - Multiple devices driver; - Media drivers; - TI TPS6594 PFSM driver; - MMC subsystem; - MTD block device drivers; - Network drivers; - NVME drivers; - x86 platform drivers; - RapidIO drivers; - Voltage and Current Regulator drivers; - Remote Processor subsystem; - S/390 drivers; - SCSI subsystem; - TCM subsystem; - Trusted Execution Environment drivers; - TTY drivers; - ChipIdea USB dr…</p> <p><strong>Affected:</strong> Ubuntu:24.04:LTS: linux-oem-6.14, Ubuntu:24.04:LTS: linux-oracle-6.14</p> <p>Oleksii Oleksenko, Cedric Fournet, Jana Hofmann, Boris Köpf, Stavros Volos, and Flavien Solt discovered that some AMD processors may allow an attacker to infer data from previous stores, potentially resulting in the leakage of privileged information. A local attacker could possibly use this to expose sensitive information. (CVE-2024-36350, CVE-2024-36357)</p> <p>Several security issues were discovered in the Linux kernel. An attacker could possibly use these to compromise the system. This update corrects flaws in the following subsystems: - ARM64 architecture; - PowerPC architecture; - RISC-V architecture; - S390 architecture; - x86 architecture; - ACPI drivers; - Serial ATA and Parallel ATA drivers; - Drivers core; - ATA over ethernet (AOE) driver; - Ublk userspace block driver; - Bus devices; - DMA engine subsystem; - Arm Firmware Framework for ARMv8-A(FFA); - Cirrus firmware drivers; - GPU drivers; - HID subsystem; - Hardware monitoring drivers; - I2C subsystem; - InfiniBand drivers; - Input Device (Miscellaneous) drivers; - Multiple devices driver; - Media drivers; - TI TPS6594 PFSM driver; - MMC subsystem; - MTD block device drivers; - Network drivers; - NVME drivers; - x86 platform drivers; - RapidIO drivers; - Voltage and Current Regulator drivers; - Remote Processor subsystem; - S/390 drivers; - SCSI subsystem; - TCM subsystem; - Trusted Execution Environment drivers; - TTY drivers; - ChipIdea USB dr…</p> https://cve.radiocsirt.org/vuln/usn-7833-1