https://cve.radiocsirt.org Contains only the most 10 recent entries. http://www.rssboard.org/rss-specification python-feedgen en Sun, 04 Oct 2026 09:22:04 +0000 https://cve.radiocsirt.org/vuln/bdu:2024-11585 bdu:2024-11585 https://cve.radiocsirt.org/vuln/bdu:2024-11585 https://cve.radiocsirt.org/vuln/certfr-2024-avi-0578 certfr-2024-avi-0578 https://cve.radiocsirt.org/vuln/certfr-2024-avi-0578 https://cve.radiocsirt.org/vuln/euvd-2026-309841 EUVD-2026-309841 https://cve.radiocsirt.org/vuln/euvd-2026-309841 https://cve.radiocsirt.org/vuln/fkie_cve-2021-47608 <p>In the Linux kernel, the following vulnerability has been resolved:</p> <p>bpf: Fix kernel address leakage in atomic fetch</p> <p>The change in commit 37086bfdc737 (&#34;bpf: Propagate stack bounds to registers in atomics w/ BPF_FETCH&#34;) around check_mem_access() handling is buggy since this would allow for unprivileged users to leak kernel pointers. For example, an atomic fetch/and with -1 on a stack destination which holds a spilled pointer will migrate the spilled register type into a scalar, which can then be exported out of the program (since scalar != pointer) by dumping it into a map value.</p> <p>The original implementation of XADD was preventing this situation by using a double call to check_mem_access() one with BPF_READ and a subsequent one with BPF_WRITE, in both cases passing -1 as a placeholder value instead of register as per XADD semantics since it didn&#39;t contain a value fetch. The BPF_READ also included a check in check_stack_read_fixed_off() which rejects the program if the stack slot is of __is_pointer_value() if dst_regno &lt; 0. The latter is to distinguish whether we&#39;re dealing with a regular stack spill/ fill or some arithmetical operation which is disallowed on non-scalars, see also 6e7e63cbb023 (&#34;bpf: Forbid XADD on spilled pointers for unprivileged users&#34;) for more context on check_mem_access() and its handling of placeholder value -1.</p> <p>One minimally intrusive option to fix the leak is for the BPF_FETCH case to initially check the BPF_READ case via check_mem_access() with -1…</p> <p>In the Linux kernel, the following vulnerability has been resolved:</p> <p>bpf: Fix kernel address leakage in atomic fetch</p> <p>The change in commit 37086bfdc737 (&#34;bpf: Propagate stack bounds to registers in atomics w/ BPF_FETCH&#34;) around check_mem_access() handling is buggy since this would allow for unprivileged users to leak kernel pointers. For example, an atomic fetch/and with -1 on a stack destination which holds a spilled pointer will migrate the spilled register type into a scalar, which can then be exported out of the program (since scalar != pointer) by dumping it into a map value.</p> <p>The original implementation of XADD was preventing this situation by using a double call to check_mem_access() one with BPF_READ and a subsequent one with BPF_WRITE, in both cases passing -1 as a placeholder value instead of register as per XADD semantics since it didn&#39;t contain a value fetch. The BPF_READ also included a check in check_stack_read_fixed_off() which rejects the program if the stack slot is of __is_pointer_value() if dst_regno &lt; 0. The latter is to distinguish whether we&#39;re dealing with a regular stack spill/ fill or some arithmetical operation which is disallowed on non-scalars, see also 6e7e63cbb023 (&#34;bpf: Forbid XADD on spilled pointers for unprivileged users&#34;) for more context on check_mem_access() and its handling of placeholder value -1.</p> <p>One minimally intrusive option to fix the leak is for the BPF_FETCH case to initially check the BPF_READ case via check_mem_access() with -1…</p> https://cve.radiocsirt.org/vuln/fkie_cve-2021-47608 https://cve.radiocsirt.org/vuln/ghsa-v7fm-vjvq-9fg6 <p>In the Linux kernel, the following vulnerability has been resolved:</p> <p>bpf: Fix kernel address leakage in atomic fetch</p> <p>The change in commit 37086bfdc737 (&#34;bpf: Propagate stack bounds to registers in atomics w/ BPF_FETCH&#34;) around check_mem_access() handling is buggy since this would allow for unprivileged users to leak kernel pointers. For example, an atomic fetch/and with -1 on a stack destination which holds a spilled pointer will migrate the spilled register type into a scalar, which can then be exported out of the program (since scalar != pointer) by dumping it into a map value.</p> <p>The original implementation of XADD was preventing this situation by using a double call to check_mem_access() one with BPF_READ and a subsequent one with BPF_WRITE, in both cases passing -1 as a placeholder value instead of register as per XADD semantics since it didn&#39;t contain a value fetch. The BPF_READ also included a check in check_stack_read_fixed_off() which rejects the program if the stack slot is of __is_pointer_value() if dst_regno &lt; 0. The latter is to distinguish whether we&#39;re dealing with a regular stack spill/ fill or some arithmetical operation which is disallowed on non-scalars, see also 6e7e63cbb023 (&#34;bpf: Forbid XADD on spilled pointers for unprivileged users&#34;) for more context on check_mem_access() and its handling of placeholder value -1.</p> <p>One minimally intrusive option to fix the leak is for the BPF_FETCH case to initially check the BPF_READ case via check_mem_access() with -1…</p> <p>In the Linux kernel, the following vulnerability has been resolved:</p> <p>bpf: Fix kernel address leakage in atomic fetch</p> <p>The change in commit 37086bfdc737 (&#34;bpf: Propagate stack bounds to registers in atomics w/ BPF_FETCH&#34;) around check_mem_access() handling is buggy since this would allow for unprivileged users to leak kernel pointers. For example, an atomic fetch/and with -1 on a stack destination which holds a spilled pointer will migrate the spilled register type into a scalar, which can then be exported out of the program (since scalar != pointer) by dumping it into a map value.</p> <p>The original implementation of XADD was preventing this situation by using a double call to check_mem_access() one with BPF_READ and a subsequent one with BPF_WRITE, in both cases passing -1 as a placeholder value instead of register as per XADD semantics since it didn&#39;t contain a value fetch. The BPF_READ also included a check in check_stack_read_fixed_off() which rejects the program if the stack slot is of __is_pointer_value() if dst_regno &lt; 0. The latter is to distinguish whether we&#39;re dealing with a regular stack spill/ fill or some arithmetical operation which is disallowed on non-scalars, see also 6e7e63cbb023 (&#34;bpf: Forbid XADD on spilled pointers for unprivileged users&#34;) for more context on check_mem_access() and its handling of placeholder value -1.</p> <p>One minimally intrusive option to fix the leak is for the BPF_FETCH case to initially check the BPF_READ case via check_mem_access() with -1…</p> https://cve.radiocsirt.org/vuln/ghsa-v7fm-vjvq-9fg6 https://cve.radiocsirt.org/vuln/suse-su-2024:2372-1 <p>Security update for the Linux Kernel</p> <p>Security update for the Linux Kernel</p> https://cve.radiocsirt.org/vuln/suse-su-2024:2372-1 https://cve.radiocsirt.org/vuln/ubuntu-cve-2021-47608 <p><strong>Affected:</strong> Ubuntu:16.04:LTS: linux-hwe-edge, Ubuntu:18.04:LTS: linux-aws-5.0, Ubuntu:18.04:LTS: linux-aws-5.3, Ubuntu:18.04:LTS: linux-azure, Ubuntu:18.04:LTS: linux-azure-5.3, Ubuntu:18.04:LTS: linux-azure-edge, Ubuntu:18.04:LTS: linux-gcp, Ubuntu:18.04:LTS: linux-gcp-5.3, Ubuntu:18.04:LTS: linux-gke-4.15, Ubuntu:18.04:LTS: linux-gke-5.4 and 54 more</p> <p>In the Linux kernel, the following vulnerability has been resolved: bpf: Fix kernel address leakage in atomic fetch The change in commit 37086bfdc737 (&#34;bpf: Propagate stack bounds to registers in atomics w/ BPF_FETCH&#34;) around check_mem_access() handling is buggy since this would allow for unprivileged users to leak kernel pointers. For example, an atomic fetch/and with -1 on a stack destination which holds a spilled pointer will migrate the spilled register type into a scalar, which can then be exported out of the program (since scalar != pointer) by dumping it into a map value. The original implementation of XADD was preventing this situation by using a double call to check_mem_access() one with BPF_READ and a subsequent one with BPF_WRITE, in both cases passing -1 as a placeholder value instead of register as per XADD semantics since it didn&#39;t contain a value fetch. The BPF_READ also included a check in check_stack_read_fixed_off() which rejects the program if the stack slot is of __is_pointer_value() if dst_regno &lt; 0. The latter is to distinguish whether we&#39;re dealing with a regular stack spill/ fill or some arithmetical operation which is disallowed on non-scalars, see also 6e7e63cbb023 (&#34;bpf: Forbid XADD on spilled pointers for unprivileged users&#34;) for more context on check_mem_access() and its handling of placeholder value -1. One minimally intrusive option to fix the leak is for the BPF_FETCH case to initially check the BPF_READ case via check_mem_access() with -1 as…</p> <p><strong>Affected:</strong> Ubuntu:16.04:LTS: linux-hwe-edge, Ubuntu:18.04:LTS: linux-aws-5.0, Ubuntu:18.04:LTS: linux-aws-5.3, Ubuntu:18.04:LTS: linux-azure, Ubuntu:18.04:LTS: linux-azure-5.3, Ubuntu:18.04:LTS: linux-azure-edge, Ubuntu:18.04:LTS: linux-gcp, Ubuntu:18.04:LTS: linux-gcp-5.3, Ubuntu:18.04:LTS: linux-gke-4.15, Ubuntu:18.04:LTS: linux-gke-5.4 and 54 more</p> <p>In the Linux kernel, the following vulnerability has been resolved: bpf: Fix kernel address leakage in atomic fetch The change in commit 37086bfdc737 (&#34;bpf: Propagate stack bounds to registers in atomics w/ BPF_FETCH&#34;) around check_mem_access() handling is buggy since this would allow for unprivileged users to leak kernel pointers. For example, an atomic fetch/and with -1 on a stack destination which holds a spilled pointer will migrate the spilled register type into a scalar, which can then be exported out of the program (since scalar != pointer) by dumping it into a map value. The original implementation of XADD was preventing this situation by using a double call to check_mem_access() one with BPF_READ and a subsequent one with BPF_WRITE, in both cases passing -1 as a placeholder value instead of register as per XADD semantics since it didn&#39;t contain a value fetch. The BPF_READ also included a check in check_stack_read_fixed_off() which rejects the program if the stack slot is of __is_pointer_value() if dst_regno &lt; 0. The latter is to distinguish whether we&#39;re dealing with a regular stack spill/ fill or some arithmetical operation which is disallowed on non-scalars, see also 6e7e63cbb023 (&#34;bpf: Forbid XADD on spilled pointers for unprivileged users&#34;) for more context on check_mem_access() and its handling of placeholder value -1. One minimally intrusive option to fix the leak is for the BPF_FETCH case to initially check the BPF_READ case via check_mem_access() with -1 as…</p> https://cve.radiocsirt.org/vuln/ubuntu-cve-2021-47608 https://cve.radiocsirt.org/vuln/wid-sec-w-2024-1418 <p>Ein lokaler Angreifer kann mehrere Schwachstellen im Linux Kernel ausnutzen, um einen nicht näher spezifizierten Angriff durchzuführen.</p> <p>Ein lokaler Angreifer kann mehrere Schwachstellen im Linux Kernel ausnutzen, um einen nicht näher spezifizierten Angriff durchzuführen.</p> https://cve.radiocsirt.org/vuln/wid-sec-w-2024-1418