https://cve.radiocsirt.org Contains only the most 10 recent entries. http://www.rssboard.org/rss-specification python-feedgen en Sat, 03 Oct 2026 03:33:21 +0000 https://cve.radiocsirt.org/vuln/bdu:2026-11403 bdu:2026-11403 https://cve.radiocsirt.org/vuln/bdu:2026-11403 https://cve.radiocsirt.org/vuln/bell-cve-2025-40306 <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-40306 https://cve.radiocsirt.org/vuln/certfr-2025-avi-1136 certfr-2025-avi-1136 https://cve.radiocsirt.org/vuln/certfr-2025-avi-1136 https://cve.radiocsirt.org/vuln/euvd-2026-347420 EUVD-2026-347420 https://cve.radiocsirt.org/vuln/euvd-2026-347420 https://cve.radiocsirt.org/vuln/fkie_cve-2025-40306 <p>In the Linux kernel, the following vulnerability has been resolved:</p> <p>orangefs: fix xattr related buffer overflow...</p> <p>Willy Tarreau &lt;w@1wt.eu&gt; forwarded me a message from Disclosure &lt;disclosure@aisle.com&gt; with the following warning:</p> <p>&gt; The helper `xattr_key()` uses the pointer variable in the loop condition &gt; rather than dereferencing it. As `key` is incremented, it remains non-NULL &gt; (until it runs into unmapped memory), so the loop does not terminate on &gt; valid C strings and will walk memory indefinitely, consuming CPU or hanging &gt; the thread.</p> <p>I easily reproduced this with setfattr and getfattr, causing a kernel oops, hung user processes and corrupted orangefs files. Disclosure sent along a diff (not a patch) with a suggested fix, which I based this patch on.</p> <p>After xattr_key started working right, xfstest generic/069 exposed an xattr related memory leak that lead to OOM. xattr_key returns a hashed key. When adding xattrs to the orangefs xattr cache, orangefs used hash_add, a kernel hashing macro. hash_add also hashes the key using hash_log which resulted in additions to the xattr cache going to the wrong hash bucket. generic/069 tortures a single file and orangefs does a getattr for the xattr &#34;security.capability&#34; every time. Orangefs negative caches on xattrs which includes a kmalloc. Since adds to the xattr cache were going to the wrong bucket, every getattr for &#34;security.capability&#34; resulted in another kmalloc, none of which were ever freed.</p> <p>I changed the two uses of…</p> <p>In the Linux kernel, the following vulnerability has been resolved:</p> <p>orangefs: fix xattr related buffer overflow...</p> <p>Willy Tarreau &lt;w@1wt.eu&gt; forwarded me a message from Disclosure &lt;disclosure@aisle.com&gt; with the following warning:</p> <p>&gt; The helper `xattr_key()` uses the pointer variable in the loop condition &gt; rather than dereferencing it. As `key` is incremented, it remains non-NULL &gt; (until it runs into unmapped memory), so the loop does not terminate on &gt; valid C strings and will walk memory indefinitely, consuming CPU or hanging &gt; the thread.</p> <p>I easily reproduced this with setfattr and getfattr, causing a kernel oops, hung user processes and corrupted orangefs files. Disclosure sent along a diff (not a patch) with a suggested fix, which I based this patch on.</p> <p>After xattr_key started working right, xfstest generic/069 exposed an xattr related memory leak that lead to OOM. xattr_key returns a hashed key. When adding xattrs to the orangefs xattr cache, orangefs used hash_add, a kernel hashing macro. hash_add also hashes the key using hash_log which resulted in additions to the xattr cache going to the wrong hash bucket. generic/069 tortures a single file and orangefs does a getattr for the xattr &#34;security.capability&#34; every time. Orangefs negative caches on xattrs which includes a kmalloc. Since adds to the xattr cache were going to the wrong bucket, every getattr for &#34;security.capability&#34; resulted in another kmalloc, none of which were ever freed.</p> <p>I changed the two uses of…</p> https://cve.radiocsirt.org/vuln/fkie_cve-2025-40306 https://cve.radiocsirt.org/vuln/ghsa-v4qq-9xc6-v286 <p>In the Linux kernel, the following vulnerability has been resolved:</p> <p>orangefs: fix xattr related buffer overflow...</p> <p>Willy Tarreau &lt;w@1wt.eu&gt; forwarded me a message from Disclosure &lt;disclosure@aisle.com&gt; with the following warning:</p> <p>&gt; The helper `xattr_key()` uses the pointer variable in the loop condition &gt; rather than dereferencing it. As `key` is incremented, it remains non-NULL &gt; (until it runs into unmapped memory), so the loop does not terminate on &gt; valid C strings and will walk memory indefinitely, consuming CPU or hanging &gt; the thread.</p> <p>I easily reproduced this with setfattr and getfattr, causing a kernel oops, hung user processes and corrupted orangefs files. Disclosure sent along a diff (not a patch) with a suggested fix, which I based this patch on.</p> <p>After xattr_key started working right, xfstest generic/069 exposed an xattr related memory leak that lead to OOM. xattr_key returns a hashed key. When adding xattrs to the orangefs xattr cache, orangefs used hash_add, a kernel hashing macro. hash_add also hashes the key using hash_log which resulted in additions to the xattr cache going to the wrong hash bucket. generic/069 tortures a single file and orangefs does a getattr for the xattr &#34;security.capability&#34; every time. Orangefs negative caches on xattrs which includes a kmalloc. Since adds to the xattr cache were going to the wrong bucket, every getattr for &#34;security.capability&#34; resulted in another kmalloc, none of which were ever freed.</p> <p>I changed the two uses of…</p> <p>In the Linux kernel, the following vulnerability has been resolved:</p> <p>orangefs: fix xattr related buffer overflow...</p> <p>Willy Tarreau &lt;w@1wt.eu&gt; forwarded me a message from Disclosure &lt;disclosure@aisle.com&gt; with the following warning:</p> <p>&gt; The helper `xattr_key()` uses the pointer variable in the loop condition &gt; rather than dereferencing it. As `key` is incremented, it remains non-NULL &gt; (until it runs into unmapped memory), so the loop does not terminate on &gt; valid C strings and will walk memory indefinitely, consuming CPU or hanging &gt; the thread.</p> <p>I easily reproduced this with setfattr and getfattr, causing a kernel oops, hung user processes and corrupted orangefs files. Disclosure sent along a diff (not a patch) with a suggested fix, which I based this patch on.</p> <p>After xattr_key started working right, xfstest generic/069 exposed an xattr related memory leak that lead to OOM. xattr_key returns a hashed key. When adding xattrs to the orangefs xattr cache, orangefs used hash_add, a kernel hashing macro. hash_add also hashes the key using hash_log which resulted in additions to the xattr cache going to the wrong hash bucket. generic/069 tortures a single file and orangefs does a getattr for the xattr &#34;security.capability&#34; every time. Orangefs negative caches on xattrs which includes a kmalloc. Since adds to the xattr cache were going to the wrong bucket, every getattr for &#34;security.capability&#34; resulted in another kmalloc, none of which were ever freed.</p> <p>I changed the two uses of…</p> https://cve.radiocsirt.org/vuln/ghsa-v4qq-9xc6-v286 https://cve.radiocsirt.org/vuln/msrc_cve-2025-40306 msrc_CVE-2025-40306 https://cve.radiocsirt.org/vuln/msrc_cve-2025-40306 https://cve.radiocsirt.org/vuln/suse-su-2026:0278-1 <p>Security update for the Linux Kernel</p> <p>Security update for the Linux Kernel</p> https://cve.radiocsirt.org/vuln/suse-su-2026:0278-1 https://cve.radiocsirt.org/vuln/ubuntu-cve-2025-40306 <p><strong>Affected:</strong> Ubuntu:Pro:14.04:LTS: linux-azure, 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:16.04:LTS: linux-hwe-edge, Ubuntu:Pro:16.04:LTS: linux-oracle, Ubuntu:Pro:18.04:LTS: linux, Ubuntu:Pro:18.04:LTS: linux-aws, Ubuntu:18.04:LTS: linux-aws-5.0 and 221 more</p> <p>In the Linux kernel, the following vulnerability has been resolved: orangefs: fix xattr related buffer overflow... Willy Tarreau &lt;w@1wt.eu&gt; forwarded me a message from Disclosure &lt;disclosure@aisle.com&gt; with the following warning: &gt; The helper `xattr_key()` uses the pointer variable in the loop condition &gt; rather than dereferencing it. As `key` is incremented, it remains non-NULL &gt; (until it runs into unmapped memory), so the loop does not terminate on &gt; valid C strings and will walk memory indefinitely, consuming CPU or hanging &gt; the thread. I easily reproduced this with setfattr and getfattr, causing a kernel oops, hung user processes and corrupted orangefs files. Disclosure sent along a diff (not a patch) with a suggested fix, which I based this patch on. After xattr_key started working right, xfstest generic/069 exposed an xattr related memory leak that lead to OOM. xattr_key returns a hashed key. When adding xattrs to the orangefs xattr cache, orangefs used hash_add, a kernel hashing macro. hash_add also hashes the key using hash_log which resulted in additions to the xattr cache going to the wrong hash bucket. generic/069 tortures a single file and orangefs does a getattr for the xattr &#34;security.capability&#34; every time. Orangefs negative caches on xattrs which includes a kmalloc. Since adds to the xattr cache were going to the wrong bucket, every getattr for &#34;security.capability&#34; resulted in another kmalloc, none of which were ever freed. I changed the two uses of hash_…</p> <p><strong>Affected:</strong> Ubuntu:Pro:14.04:LTS: linux-azure, 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:16.04:LTS: linux-hwe-edge, Ubuntu:Pro:16.04:LTS: linux-oracle, Ubuntu:Pro:18.04:LTS: linux, Ubuntu:Pro:18.04:LTS: linux-aws, Ubuntu:18.04:LTS: linux-aws-5.0 and 221 more</p> <p>In the Linux kernel, the following vulnerability has been resolved: orangefs: fix xattr related buffer overflow... Willy Tarreau &lt;w@1wt.eu&gt; forwarded me a message from Disclosure &lt;disclosure@aisle.com&gt; with the following warning: &gt; The helper `xattr_key()` uses the pointer variable in the loop condition &gt; rather than dereferencing it. As `key` is incremented, it remains non-NULL &gt; (until it runs into unmapped memory), so the loop does not terminate on &gt; valid C strings and will walk memory indefinitely, consuming CPU or hanging &gt; the thread. I easily reproduced this with setfattr and getfattr, causing a kernel oops, hung user processes and corrupted orangefs files. Disclosure sent along a diff (not a patch) with a suggested fix, which I based this patch on. After xattr_key started working right, xfstest generic/069 exposed an xattr related memory leak that lead to OOM. xattr_key returns a hashed key. When adding xattrs to the orangefs xattr cache, orangefs used hash_add, a kernel hashing macro. hash_add also hashes the key using hash_log which resulted in additions to the xattr cache going to the wrong hash bucket. generic/069 tortures a single file and orangefs does a getattr for the xattr &#34;security.capability&#34; every time. Orangefs negative caches on xattrs which includes a kmalloc. Since adds to the xattr cache were going to the wrong bucket, every getattr for &#34;security.capability&#34; resulted in another kmalloc, none of which were ever freed. I changed the two uses of hash_…</p> https://cve.radiocsirt.org/vuln/ubuntu-cve-2025-40306 https://cve.radiocsirt.org/vuln/wid-sec-w-2025-2756 <p>Ein Angreifer kann mehrere Schwachstellen im Linux Kernel ausnutzen, um einen Denial-of-Service-Zustand zu erzeugen oder weitere, nicht spezifizierte Auswirkungen zu erlangen.</p> <p>Ein Angreifer kann mehrere Schwachstellen im Linux Kernel ausnutzen, um einen Denial-of-Service-Zustand zu erzeugen oder weitere, nicht spezifizierte Auswirkungen zu erlangen.</p> https://cve.radiocsirt.org/vuln/wid-sec-w-2025-2756