https://cve.radiocsirt.org/rss/recent/all/10 Most recent entries from all 2026-10-03T22:14:22.055150+00:00 Vulnerability-Lookup csirt@opendfir.org python-feedgen Contains only the most 10 recent entries. https://cve.radiocsirt.org/vuln/bdu:2026-04559 bdu:2026-04559 2026-10-03T22:14:22.246593+00:00 bdu:2026-04559 https://cve.radiocsirt.org/vuln/certfr-2025-avi-0587 certfr-2025-avi-0587 — De multiples vulnérabilités ont été découvertes dans le noyau Linux de SUSE. Certaines d'entre elles permettent à un at… 2026-10-03T22:14:22.246659+00:00 certfr-2025-avi-0587 https://cve.radiocsirt.org/vuln/euvd-2026-310952 EUVD-2026-310952 2026-10-03T22:14:22.246689+00:00 EUVD-2026-310952 https://cve.radiocsirt.org/vuln/fkie_cve-2022-50008 fkie_cve-2022-50008 2026-10-03T22:14:22.246708+00:00

In the Linux kernel, the following vulnerability has been resolved:

kprobes: don't call disarm_kprobe() for disabled kprobes

The assumption in __disable_kprobe() is wrong, and it could try to disarm an already disarmed kprobe and fire the WARN_ONCE() below. [0] We can easily reproduce this issue.

1. Write 0 to /sys/kernel/debug/kprobes/enabled.

# echo 0 > /sys/kernel/debug/kprobes/enabled

2. Run execsnoop. At this time, one kprobe is disabled.

# /usr/share/bcc/tools/execsnoop & [1] 2460 PCOMM PID PPID RET ARGS

# cat /sys/kernel/debug/kprobes/list ffffffff91345650 r __x64_sys_execve+0x0 [FTRACE] ffffffff91345650 k __x64_sys_execve+0x0 [DISABLED][FTRACE]

3. Write 1 to /sys/kernel/debug/kprobes/enabled, which changes kprobes_all_disarmed to false but does not arm the disabled kprobe.

# echo 1 > /sys/kernel/debug/kprobes/enabled

# cat /sys/kernel/debug/kprobes/list ffffffff91345650 r __x64_sys_execve+0x0 [FTRACE] ffffffff91345650 k __x64_sys_execve+0x0 [DISABLED][FTRACE]

4. Kill execsnoop, when __disable_kprobe() calls disarm_kprobe() for the disabled kprobe and hits the WARN_ONCE() in __disarm_kprobe_ftrace().

# fg /usr/share/bcc/tools/execsnoop ^C

Actually, WARN_ONCE() is fired twice, and __unregister_kprobe_top() misses some cleanups and leaves the aggregated kprobe in the hash table. Then, __unregister_trace_kprobe() initialises tk->rp.kp.list and creates an infinite loop like this.

aggr…

 https://cve.radiocsirt.org/vuln/ghsa-q44m-58pc-8rr7 GHSA-q44m-58pc-8rr7 2026-10-03T22:14:22.246803+00:00

In the Linux kernel, the following vulnerability has been resolved:

kprobes: don't call disarm_kprobe() for disabled kprobes

The assumption in __disable_kprobe() is wrong, and it could try to disarm an already disarmed kprobe and fire the WARN_ONCE() below. [0] We can easily reproduce this issue.

1. Write 0 to /sys/kernel/debug/kprobes/enabled.

# echo 0 > /sys/kernel/debug/kprobes/enabled

2. Run execsnoop. At this time, one kprobe is disabled.

# /usr/share/bcc/tools/execsnoop & [1] 2460 PCOMM PID PPID RET ARGS

# cat /sys/kernel/debug/kprobes/list ffffffff91345650 r __x64_sys_execve+0x0 [FTRACE] ffffffff91345650 k __x64_sys_execve+0x0 [DISABLED][FTRACE]

3. Write 1 to /sys/kernel/debug/kprobes/enabled, which changes kprobes_all_disarmed to false but does not arm the disabled kprobe.

# echo 1 > /sys/kernel/debug/kprobes/enabled

# cat /sys/kernel/debug/kprobes/list ffffffff91345650 r __x64_sys_execve+0x0 [FTRACE] ffffffff91345650 k __x64_sys_execve+0x0 [DISABLED][FTRACE]

4. Kill execsnoop, when __disable_kprobe() calls disarm_kprobe() for the disabled kprobe and hits the WARN_ONCE() in __disarm_kprobe_ftrace().

# fg /usr/share/bcc/tools/execsnoop ^C

Actually, WARN_ONCE() is fired twice, and __unregister_kprobe_top() misses some cleanups and leaves the aggregated kprobe in the hash table. Then, __unregister_trace_kprobe() initialises tk->rp.kp.list and creates an infinite loop like this.

aggr…

 https://cve.radiocsirt.org/vuln/suse-su-2025:02264-1 SUSE-SU-2025:02264-1 — Security update for the Linux Kernel 2026-10-03T22:14:22.246878+00:00

Security update for the Linux Kernel

 https://cve.radiocsirt.org/vuln/ubuntu-cve-2022-50008 UBUNTU-CVE-2022-50008 2026-10-03T22:14:22.247084+00:00

Affected: Ubuntu:Pro:14.04:LTS: linux-azure, Ubuntu:Pro:14.04:LTS: linux-aws, Ubuntu:Pro:14.04:LTS: linux-lts-xenial, 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, Ubuntu:Pro:16.04:LTS: linux-oracle, Ubuntu:Pro:16.04:LTS: linux, Ubuntu:Pro:16.04:LTS: linux-aws and 145 more

In the Linux kernel, the following vulnerability has been resolved: kprobes: don't call disarm_kprobe() for disabled kprobes The assumption in __disable_kprobe() is wrong, and it could try to disarm an already disarmed kprobe and fire the WARN_ONCE() below. [0] We can easily reproduce this issue. 1. Write 0 to /sys/kernel/debug/kprobes/enabled. # echo 0 > /sys/kernel/debug/kprobes/enabled 2. Run execsnoop. At this time, one kprobe is disabled. # /usr/share/bcc/tools/execsnoop & [1] 2460 PCOMM PID PPID RET ARGS # cat /sys/kernel/debug/kprobes/list ffffffff91345650 r __x64_sys_execve+0x0 [FTRACE] ffffffff91345650 k __x64_sys_execve+0x0 [DISABLED][FTRACE] 3. Write 1 to /sys/kernel/debug/kprobes/enabled, which changes kprobes_all_disarmed to false but does not arm the disabled kprobe. # echo 1 > /sys/kernel/debug/kprobes/enabled # cat /sys/kernel/debug/kprobes/list ffffffff91345650 r __x64_sys_execve+0x0 [FTRACE] ffffffff91345650 k __x64_sys_execve+0x0 [DISABLED][FTRACE] 4. Kill execsnoop, when __disable_kprobe() calls disarm_kprobe() for the disabled kprobe and hits the WARN_ONCE() in __disarm_kprobe_ftrace(). # fg /usr/share/bcc/tools/execsnoop ^C Actually, WARN_ONCE() is fired twice, and __unregister_kprobe_top() misses some cleanups and leaves the aggregated kprobe in the hash table. Then, __unregister_trace_kprobe() initialises tk->rp.kp.list and creates an infinite loop like this. aggregated kprobe.…

 https://cve.radiocsirt.org/vuln/wid-sec-w-2025-1350 WID-SEC-W-2025-1350 — Linux Kernel: Mehrere Schwachstellen ermöglichen Denial of Service 2026-10-03T22:14:22.247450+00:00

Ein lokaler Angreifer kann mehrere Schwachstellen in Linux Kernel ausnutzen, um einen Denial of Service Angriff durchzuführen.