Most recent entries from all

Most recent entries from all https://cve.radiocsirt.org Contains only the most 10 recent entries. http://www.rssboard.org/rss-specification python-feedgen en Sat, 03 Oct 2026 15:16:45 +0000 bdu:2025-10739 https://cve.radiocsirt.org/vuln/bdu:2025-10739 bdu:2025-10739 https://cve.radiocsirt.org/vuln/bdu:2025-10739 BELL-CVE-2025-38305 https://cve.radiocsirt.org/vuln/bell-cve-2025-38305 <p><strong>Affected:</strong> Alpaquita:23: linux-lts, Alpaquita:25: linux-lts, Alpaquita:stream: linux-lts</p> <p><strong>Affected:</strong> Alpaquita:23: linux-lts, Alpaquita:25: linux-lts, Alpaquita:stream: linux-lts</p> https://cve.radiocsirt.org/vuln/bell-cve-2025-38305 certfr-2025-avi-0698 — De multiples vulnérabilités ont été découvertes dans le noyau Linux de Debian. Certaines d'entre elles permettent à un… https://cve.radiocsirt.org/vuln/certfr-2025-avi-0698 certfr-2025-avi-0698 https://cve.radiocsirt.org/vuln/certfr-2025-avi-0698 EUVD-2026-314529 https://cve.radiocsirt.org/vuln/euvd-2026-314529 EUVD-2026-314529 https://cve.radiocsirt.org/vuln/euvd-2026-314529 fkie_cve-2025-38305 https://cve.radiocsirt.org/vuln/fkie_cve-2025-38305 <p>In the Linux kernel, the following vulnerability has been resolved:</p> <p>ptp: remove ptp->n_vclocks check logic in ptp_vclock_in_use()</p> <p>There is no disagreement that we should check both ptp->is_virtual_clock and ptp->n_vclocks to check if the ptp virtual clock is in use.</p> <p>However, when we acquire ptp->n_vclocks_mux to read ptp->n_vclocks in ptp_vclock_in_use(), we observe a recursive lock in the call trace starting from n_vclocks_store().</p> <p>============================================ WARNING: possible recursive locking detected 6.15.0-rc6 #1 Not tainted -------------------------------------------- syz.0.1540/13807 is trying to acquire lock: ffff888035a24868 (&ptp->n_vclocks_mux){+.+.}-{4:4}, at: ptp_vclock_in_use drivers/ptp/ptp_private.h:103 [inline] ffff888035a24868 (&ptp->n_vclocks_mux){+.+.}-{4:4}, at: ptp_clock_unregister+0x21/0x250 drivers/ptp/ptp_clock.c:415</p> <p>but task is already holding lock: ffff888030704868 (&ptp->n_vclocks_mux){+.+.}-{4:4}, at: n_vclocks_store+0xf1/0x6d0 drivers/ptp/ptp_sysfs.c:215</p> <p>other info that might help us debug this: Possible unsafe locking scenario:</p> <p>CPU0 ---- lock(&ptp->n_vclocks_mux); lock(&ptp->n_vclocks_mux);</p> <p>*** DEADLOCK *** .... ============================================</p> <p>The best way to solve this is to remove the logic that checks ptp->n_vclocks in ptp_vclock_in_use().</p> <p>The reason why this is appropriate is that any path that uses ptp->n_vclocks must unconditionally check if ptp->n_vclocks is greater than 0 be…</p> <p>In the Linux kernel, the following vulnerability has been resolved:</p> <p>ptp: remove ptp->n_vclocks check logic in ptp_vclock_in_use()</p> <p>There is no disagreement that we should check both ptp->is_virtual_clock and ptp->n_vclocks to check if the ptp virtual clock is in use.</p> <p>However, when we acquire ptp->n_vclocks_mux to read ptp->n_vclocks in ptp_vclock_in_use(), we observe a recursive lock in the call trace starting from n_vclocks_store().</p> <p>============================================ WARNING: possible recursive locking detected 6.15.0-rc6 #1 Not tainted -------------------------------------------- syz.0.1540/13807 is trying to acquire lock: ffff888035a24868 (&ptp->n_vclocks_mux){+.+.}-{4:4}, at: ptp_vclock_in_use drivers/ptp/ptp_private.h:103 [inline] ffff888035a24868 (&ptp->n_vclocks_mux){+.+.}-{4:4}, at: ptp_clock_unregister+0x21/0x250 drivers/ptp/ptp_clock.c:415</p> <p>but task is already holding lock: ffff888030704868 (&ptp->n_vclocks_mux){+.+.}-{4:4}, at: n_vclocks_store+0xf1/0x6d0 drivers/ptp/ptp_sysfs.c:215</p> <p>other info that might help us debug this: Possible unsafe locking scenario:</p> <p>CPU0 ---- lock(&ptp->n_vclocks_mux); lock(&ptp->n_vclocks_mux);</p> <p>*** DEADLOCK *** .... ============================================</p> <p>The best way to solve this is to remove the logic that checks ptp->n_vclocks in ptp_vclock_in_use().</p> <p>The reason why this is appropriate is that any path that uses ptp->n_vclocks must unconditionally check if ptp->n_vclocks is greater than 0 be…</p> https://cve.radiocsirt.org/vuln/fkie_cve-2025-38305 GHSA-vx82-qc8j-62qx https://cve.radiocsirt.org/vuln/ghsa-vx82-qc8j-62qx <p>In the Linux kernel, the following vulnerability has been resolved:</p> <p>ptp: remove ptp->n_vclocks check logic in ptp_vclock_in_use()</p> <p>There is no disagreement that we should check both ptp->is_virtual_clock and ptp->n_vclocks to check if the ptp virtual clock is in use.</p> <p>However, when we acquire ptp->n_vclocks_mux to read ptp->n_vclocks in ptp_vclock_in_use(), we observe a recursive lock in the call trace starting from n_vclocks_store().</p> <p>============================================ WARNING: possible recursive locking detected 6.15.0-rc6 #1 Not tainted -------------------------------------------- syz.0.1540/13807 is trying to acquire lock: ffff888035a24868 (&ptp->n_vclocks_mux){+.+.}-{4:4}, at: ptp_vclock_in_use drivers/ptp/ptp_private.h:103 [inline] ffff888035a24868 (&ptp->n_vclocks_mux){+.+.}-{4:4}, at: ptp_clock_unregister+0x21/0x250 drivers/ptp/ptp_clock.c:415</p> <p>but task is already holding lock: ffff888030704868 (&ptp->n_vclocks_mux){+.+.}-{4:4}, at: n_vclocks_store+0xf1/0x6d0 drivers/ptp/ptp_sysfs.c:215</p> <p>other info that might help us debug this: Possible unsafe locking scenario:</p> <p>CPU0 ---- lock(&ptp->n_vclocks_mux); lock(&ptp->n_vclocks_mux);</p> <p>*** DEADLOCK *** .... ============================================</p> <p>The best way to solve this is to remove the logic that checks ptp->n_vclocks in ptp_vclock_in_use().</p> <p>The reason why this is appropriate is that any path that uses ptp->n_vclocks must unconditionally check if ptp->n_vclocks is greater than 0 be…</p> <p>In the Linux kernel, the following vulnerability has been resolved:</p> <p>ptp: remove ptp->n_vclocks check logic in ptp_vclock_in_use()</p> <p>There is no disagreement that we should check both ptp->is_virtual_clock and ptp->n_vclocks to check if the ptp virtual clock is in use.</p> <p>However, when we acquire ptp->n_vclocks_mux to read ptp->n_vclocks in ptp_vclock_in_use(), we observe a recursive lock in the call trace starting from n_vclocks_store().</p> <p>============================================ WARNING: possible recursive locking detected 6.15.0-rc6 #1 Not tainted -------------------------------------------- syz.0.1540/13807 is trying to acquire lock: ffff888035a24868 (&ptp->n_vclocks_mux){+.+.}-{4:4}, at: ptp_vclock_in_use drivers/ptp/ptp_private.h:103 [inline] ffff888035a24868 (&ptp->n_vclocks_mux){+.+.}-{4:4}, at: ptp_clock_unregister+0x21/0x250 drivers/ptp/ptp_clock.c:415</p> <p>but task is already holding lock: ffff888030704868 (&ptp->n_vclocks_mux){+.+.}-{4:4}, at: n_vclocks_store+0xf1/0x6d0 drivers/ptp/ptp_sysfs.c:215</p> <p>other info that might help us debug this: Possible unsafe locking scenario:</p> <p>CPU0 ---- lock(&ptp->n_vclocks_mux); lock(&ptp->n_vclocks_mux);</p> <p>*** DEADLOCK *** .... ============================================</p> <p>The best way to solve this is to remove the logic that checks ptp->n_vclocks in ptp_vclock_in_use().</p> <p>The reason why this is appropriate is that any path that uses ptp->n_vclocks must unconditionally check if ptp->n_vclocks is greater than 0 be…</p> https://cve.radiocsirt.org/vuln/ghsa-vx82-qc8j-62qx msrc_CVE-2025-38305 — ptp: remove ptp->n_vclocks check logic in ptp_vclock_in_use() https://cve.radiocsirt.org/vuln/msrc_cve-2025-38305 msrc_CVE-2025-38305 https://cve.radiocsirt.org/vuln/msrc_cve-2025-38305 OESA-2025-2268 — kernel security update https://cve.radiocsirt.org/vuln/oesa-2025-2268 <p><strong>Affected:</strong> openEuler:24.03-LTS: kernel</p> <p>The Linux Kernel, the operating system core itself. Security Fix(es):</p> <p>In the Linux kernel, the following vulnerability has been resolved:</p> <p>rapidio: fix an API misues when rio_add_net() fails</p> <p>rio_add_net() calls device_register() and fails when device_register() fails. Thus, put_device() should be used rather than kfree(). Add &quot;mport-&gt;net = NULL;&quot; to avoid a use after free issue.(CVE-2025-21934)</p> <p>In the Linux kernel, the following vulnerability has been resolved:</p> <p>cifs: Fix integer overflow while processing closetimeo mount option</p> <p>User-provided mount parameter closetimeo of type u32 is intended to have an upper limit, but before it is validated, the value is converted from seconds to jiffies which can lead to an integer overflow.</p> <p>Found by Linux Verification Center (linuxtesting.org) with SVACE.(CVE-2025-21962)</p> <p>In the Linux kernel, the following vulnerability has been resolved:</p> <p>ksmbd: fix use-after-free in ksmbd_free_work_struct</p> <p>-&gt;interim_entry of ksmbd_work could be deleted after oplock is freed. We don&apos;t need to manage it with linked list. The interim request could be immediately sent whenever a oplock break wait is needed.(CVE-2025-21967)</p> <p>In the Linux kernel, the following vulnerability has been resolved:</p> <p>ksmbd: fix use-after-free in kerberos authentication</p> <p>Setting sess-&gt;user = NULL was introduced to fix the dangling pointer created by ksmbd_free_user. However, it is possible another thread could be operating on the session and make us…</p> <p><strong>Affected:</strong> openEuler:24.03-LTS: kernel</p> <p>The Linux Kernel, the operating system core itself. Security Fix(es):</p> <p>In the Linux kernel, the following vulnerability has been resolved:</p> <p>rapidio: fix an API misues when rio_add_net() fails</p> <p>rio_add_net() calls device_register() and fails when device_register() fails. Thus, put_device() should be used rather than kfree(). Add &quot;mport-&gt;net = NULL;&quot; to avoid a use after free issue.(CVE-2025-21934)</p> <p>In the Linux kernel, the following vulnerability has been resolved:</p> <p>cifs: Fix integer overflow while processing closetimeo mount option</p> <p>User-provided mount parameter closetimeo of type u32 is intended to have an upper limit, but before it is validated, the value is converted from seconds to jiffies which can lead to an integer overflow.</p> <p>Found by Linux Verification Center (linuxtesting.org) with SVACE.(CVE-2025-21962)</p> <p>In the Linux kernel, the following vulnerability has been resolved:</p> <p>ksmbd: fix use-after-free in ksmbd_free_work_struct</p> <p>-&gt;interim_entry of ksmbd_work could be deleted after oplock is freed. We don&apos;t need to manage it with linked list. The interim request could be immediately sent whenever a oplock break wait is needed.(CVE-2025-21967)</p> <p>In the Linux kernel, the following vulnerability has been resolved:</p> <p>ksmbd: fix use-after-free in kerberos authentication</p> <p>Setting sess-&gt;user = NULL was introduced to fix the dangling pointer created by ksmbd_free_user. However, it is possible another thread could be operating on the session and make us…</p> https://cve.radiocsirt.org/vuln/oesa-2025-2268 openSUSE-SU-2025:20081-1 — Security update for the Linux Kernel https://cve.radiocsirt.org/vuln/opensuse-su-2025:20081-1 <p>Security update for the Linux Kernel</p> <p>Security update for the Linux Kernel</p> https://cve.radiocsirt.org/vuln/opensuse-su-2025:20081-1 SUSE-SU-2025:02853-1 — Security update for the Linux Kernel https://cve.radiocsirt.org/vuln/suse-su-2025:02853-1 <p>Security update for the Linux Kernel</p> <p>Security update for the Linux Kernel</p> https://cve.radiocsirt.org/vuln/suse-su-2025:02853-1 UBUNTU-CVE-2025-38305 https://cve.radiocsirt.org/vuln/ubuntu-cve-2025-38305 <p><strong>Affected:</strong> Ubuntu:Pro:14.04:LTS: linux, Ubuntu:Pro:14.04:LTS: linux-aws, Ubuntu:Pro:14.04:LTS: linux-azure, Ubuntu:Pro:14.04:LTS: linux-lts-xenial, Ubuntu:Pro:16.04:LTS: linux, Ubuntu:Pro:16.04:LTS: linux-aws, Ubuntu:Pro:16.04:LTS: linux-aws-hwe, Ubuntu:Pro:16.04:LTS: linux-azure, Ubuntu:Pro:16.04:LTS: linux-gcp, Ubuntu:Pro:16.04:LTS: linux-hwe and 213 more</p> <p>In the Linux kernel, the following vulnerability has been resolved: ptp: remove ptp->n_vclocks check logic in ptp_vclock_in_use() There is no disagreement that we should check both ptp->is_virtual_clock and ptp->n_vclocks to check if the ptp virtual clock is in use. However, when we acquire ptp->n_vclocks_mux to read ptp->n_vclocks in ptp_vclock_in_use(), we observe a recursive lock in the call trace starting from n_vclocks_store(). ============================================ WARNING: possible recursive locking detected 6.15.0-rc6 #1 Not tainted -------------------------------------------- syz.0.1540/13807 is trying to acquire lock: ffff888035a24868 (&ptp->n_vclocks_mux){+.+.}-{4:4}, at: ptp_vclock_in_use drivers/ptp/ptp_private.h:103 [inline] ffff888035a24868 (&ptp->n_vclocks_mux){+.+.}-{4:4}, at: ptp_clock_unregister+0x21/0x250 drivers/ptp/ptp_clock.c:415 but task is already holding lock: ffff888030704868 (&ptp->n_vclocks_mux){+.+.}-{4:4}, at: n_vclocks_store+0xf1/0x6d0 drivers/ptp/ptp_sysfs.c:215 other info that might help us debug this: Possible unsafe locking scenario: CPU0 ---- lock(&ptp->n_vclocks_mux); lock(&ptp->n_vclocks_mux); *** DEADLOCK *** .... ============================================ The best way to solve this is to remove the logic that checks ptp->n_vclocks in ptp_vclock_in_use(). The reason why this is appropriate is that any path that uses ptp->n_vclocks must unconditionally check if ptp->n_vclocks is greater than 0 before unreg…</p> <p><strong>Affected:</strong> Ubuntu:Pro:14.04:LTS: linux, Ubuntu:Pro:14.04:LTS: linux-aws, Ubuntu:Pro:14.04:LTS: linux-azure, Ubuntu:Pro:14.04:LTS: linux-lts-xenial, Ubuntu:Pro:16.04:LTS: linux, Ubuntu:Pro:16.04:LTS: linux-aws, Ubuntu:Pro:16.04:LTS: linux-aws-hwe, Ubuntu:Pro:16.04:LTS: linux-azure, Ubuntu:Pro:16.04:LTS: linux-gcp, Ubuntu:Pro:16.04:LTS: linux-hwe and 213 more</p> <p>In the Linux kernel, the following vulnerability has been resolved: ptp: remove ptp->n_vclocks check logic in ptp_vclock_in_use() There is no disagreement that we should check both ptp->is_virtual_clock and ptp->n_vclocks to check if the ptp virtual clock is in use. However, when we acquire ptp->n_vclocks_mux to read ptp->n_vclocks in ptp_vclock_in_use(), we observe a recursive lock in the call trace starting from n_vclocks_store(). ============================================ WARNING: possible recursive locking detected 6.15.0-rc6 #1 Not tainted -------------------------------------------- syz.0.1540/13807 is trying to acquire lock: ffff888035a24868 (&ptp->n_vclocks_mux){+.+.}-{4:4}, at: ptp_vclock_in_use drivers/ptp/ptp_private.h:103 [inline] ffff888035a24868 (&ptp->n_vclocks_mux){+.+.}-{4:4}, at: ptp_clock_unregister+0x21/0x250 drivers/ptp/ptp_clock.c:415 but task is already holding lock: ffff888030704868 (&ptp->n_vclocks_mux){+.+.}-{4:4}, at: n_vclocks_store+0xf1/0x6d0 drivers/ptp/ptp_sysfs.c:215 other info that might help us debug this: Possible unsafe locking scenario: CPU0 ---- lock(&ptp->n_vclocks_mux); lock(&ptp->n_vclocks_mux); *** DEADLOCK *** .... ============================================ The best way to solve this is to remove the logic that checks ptp->n_vclocks in ptp_vclock_in_use(). The reason why this is appropriate is that any path that uses ptp->n_vclocks must unconditionally check if ptp->n_vclocks is greater than 0 before unreg…</p> https://cve.radiocsirt.org/vuln/ubuntu-cve-2025-38305 WID-SEC-W-2025-1522 — Linux Kernel: Mehrere Schwachstellen ermöglichen Denial of Service https://cve.radiocsirt.org/vuln/wid-sec-w-2025-1522 <p>Ein entfernter Angreifer kann mehrere Schwachstellen im Linux Kernel ausnutzen, um einen Denial of Service Angriff durchzuführen oder nicht spezifizierte Auswirkungen zu verursachen.</p> <p>Ein entfernter Angreifer kann mehrere Schwachstellen im Linux Kernel ausnutzen, um einen Denial of Service Angriff durchzuführen oder nicht spezifizierte Auswirkungen zu verursachen.</p> https://cve.radiocsirt.org/vuln/wid-sec-w-2025-1522