https://cve.radiocsirt.org Contains only the most 10 recent entries. http://www.rssboard.org/rss-specification python-feedgen en Sun, 04 Oct 2026 05:03:16 +0000 https://cve.radiocsirt.org/vuln/bdu:2024-08322 bdu:2024-08322 https://cve.radiocsirt.org/vuln/bdu:2024-08322 https://cve.radiocsirt.org/vuln/bell-cve-2024-42093 <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-2024-42093 https://cve.radiocsirt.org/vuln/certfr-2024-avi-0693 certfr-2024-avi-0693 https://cve.radiocsirt.org/vuln/certfr-2024-avi-0693 https://cve.radiocsirt.org/vuln/euvd-2026-317031 EUVD-2026-317031 https://cve.radiocsirt.org/vuln/euvd-2026-317031 https://cve.radiocsirt.org/vuln/fkie_cve-2024-42093 <p>In the Linux kernel, the following vulnerability has been resolved:</p> <p>net/dpaa2: Avoid explicit cpumask var allocation on stack</p> <p>For CONFIG_CPUMASK_OFFSTACK=y kernel, explicit allocation of cpumask variable on stack is not recommended since it can cause potential stack overflow.</p> <p>Instead, kernel code should always use *cpumask_var API(s) to allocate cpumask var in config-neutral way, leaving allocation strategy to CONFIG_CPUMASK_OFFSTACK.</p> <p>Use *cpumask_var API(s) to address it.</p> <p>In the Linux kernel, the following vulnerability has been resolved:</p> <p>net/dpaa2: Avoid explicit cpumask var allocation on stack</p> <p>For CONFIG_CPUMASK_OFFSTACK=y kernel, explicit allocation of cpumask variable on stack is not recommended since it can cause potential stack overflow.</p> <p>Instead, kernel code should always use *cpumask_var API(s) to allocate cpumask var in config-neutral way, leaving allocation strategy to CONFIG_CPUMASK_OFFSTACK.</p> <p>Use *cpumask_var API(s) to address it.</p> https://cve.radiocsirt.org/vuln/fkie_cve-2024-42093 https://cve.radiocsirt.org/vuln/ghsa-v9r3-3hjw-wxm2 <p>In the Linux kernel, the following vulnerability has been resolved:</p> <p>net/dpaa2: Avoid explicit cpumask var allocation on stack</p> <p>For CONFIG_CPUMASK_OFFSTACK=y kernel, explicit allocation of cpumask variable on stack is not recommended since it can cause potential stack overflow.</p> <p>Instead, kernel code should always use *cpumask_var API(s) to allocate cpumask var in config-neutral way, leaving allocation strategy to CONFIG_CPUMASK_OFFSTACK.</p> <p>Use *cpumask_var API(s) to address it.</p> <p>In the Linux kernel, the following vulnerability has been resolved:</p> <p>net/dpaa2: Avoid explicit cpumask var allocation on stack</p> <p>For CONFIG_CPUMASK_OFFSTACK=y kernel, explicit allocation of cpumask variable on stack is not recommended since it can cause potential stack overflow.</p> <p>Instead, kernel code should always use *cpumask_var API(s) to allocate cpumask var in config-neutral way, leaving allocation strategy to CONFIG_CPUMASK_OFFSTACK.</p> <p>Use *cpumask_var API(s) to address it.</p> https://cve.radiocsirt.org/vuln/ghsa-v9r3-3hjw-wxm2 https://cve.radiocsirt.org/vuln/icsa-24-102-01 <p>An out-of-bounds (OOB) memory write flaw was found in the NFSD in the Linux kernel. Missing sanity may lead to a write beyond bmval[bmlen-1] in nfsd4_decode_bitmap4 in fs/nfsd/nfs4xdr.c. In this flaw, a local attacker with user privilege may gain access to out-of-bounds memory, leading to a system integrity and confidentiality threat. fs/nfsd/trace.h in the Linux kernel before 5.13.4 might allow remote attackers to cause a denial of service (out-of-bounds read in strlen) by sending NFS traffic when the trace event framework is being used for nfsd. SUNRPC: null pointer dereference in svc_rqst_free(). When alloc_pages_node() returns null in svc_rqst_alloc(), the null rq_scratch_page pointer will be dereferenced when calling put_page() in svc_rqst_free(). NFSD: READDIR buffer overflow. If a client sends a READDIR count argument that is too small (say, zero), then the buffer size calculation in the new init_dirlist helper functions results in an underflow, allowing the XDR stream functions to write beyond the actual buffer. This calculation has always been suspect. NFSD has never sanity- checked the READDIR count argument, but the old entry encoders managed the problem correctly. With the commits below, entry encoding changed, exposing the underflow to the pointer arithmetic in xdr_reserve_space(). Modern NFS clients attempt to retrieve as much data as possible for each READDIR request. nfsd: NULL dereference in nfs3svc_encode_getaclres. A NULL pointer dereference vulnerability…</p> <p>An out-of-bounds (OOB) memory write flaw was found in the NFSD in the Linux kernel. Missing sanity may lead to a write beyond bmval[bmlen-1] in nfsd4_decode_bitmap4 in fs/nfsd/nfs4xdr.c. In this flaw, a local attacker with user privilege may gain access to out-of-bounds memory, leading to a system integrity and confidentiality threat. fs/nfsd/trace.h in the Linux kernel before 5.13.4 might allow remote attackers to cause a denial of service (out-of-bounds read in strlen) by sending NFS traffic when the trace event framework is being used for nfsd. SUNRPC: null pointer dereference in svc_rqst_free(). When alloc_pages_node() returns null in svc_rqst_alloc(), the null rq_scratch_page pointer will be dereferenced when calling put_page() in svc_rqst_free(). NFSD: READDIR buffer overflow. If a client sends a READDIR count argument that is too small (say, zero), then the buffer size calculation in the new init_dirlist helper functions results in an underflow, allowing the XDR stream functions to write beyond the actual buffer. This calculation has always been suspect. NFSD has never sanity- checked the READDIR count argument, but the old entry encoders managed the problem correctly. With the commits below, entry encoding changed, exposing the underflow to the pointer arithmetic in xdr_reserve_space(). Modern NFS clients attempt to retrieve as much data as possible for each READDIR request. nfsd: NULL dereference in nfs3svc_encode_getaclres. A NULL pointer dereference vulnerability…</p> https://cve.radiocsirt.org/vuln/icsa-24-102-01 https://cve.radiocsirt.org/vuln/msrc_cve-2024-42093 msrc_CVE-2024-42093 https://cve.radiocsirt.org/vuln/msrc_cve-2024-42093 https://cve.radiocsirt.org/vuln/oesa-2024-1961 <p><strong>Affected:</strong> openEuler:22.03-LTS-SP4: kernel</p> <p>The Linux Kernel, the operating system core itself. Security Fix(es): In the Linux kernel, the following vulnerability has been resolved: NFSD: Fix the behavior of READ near OFFSET_MAX Dan Aloni reports: &amp;gt; Due to commit 8cfb9015280d (&amp;quot;NFS: Always provide aligned buffers to &amp;gt; the RPC read layers&amp;quot;) on the client, a read of 0xfff is aligned up &amp;gt; to server rsize of 0x1000. &amp;gt; &amp;gt; As a result, in a test where the server has a file of size &amp;gt; 0x7fffffffffffffff, and the client tries to read from the offset &amp;gt; 0x7ffffffffffff000, the read causes loff_t overflow in the server &amp;gt; and it returns an NFS code of EINVAL to the client. The client as &amp;gt; a result indefinitely retries the request. The Linux NFS client does not handle NFS?ERR_INVAL, even though all NFS specifications permit servers to return that status code for a READ. Instead of NFS?ERR_INVAL, have out-of-range READ requests succeed and return a short result. Set the EOF flag in the result to prevent the client from retrying the READ request. This behavior appears to be consistent with Solaris NFS servers. Note that NFSv3 and NFSv4 use u64 offset values on the wire. These must be converted to loff_t internally before use -- an implicit type cast is not adequate for this purpose. Otherwise VFS checks against sb-&amp;gt;s_maxbytes do not work properly.(CVE-2022-48827) In the Linux kernel, the following vulnerability has been resolved: net: can: j1939: enhanced error handlin…</p> <p><strong>Affected:</strong> openEuler:22.03-LTS-SP4: kernel</p> <p>The Linux Kernel, the operating system core itself. Security Fix(es): In the Linux kernel, the following vulnerability has been resolved: NFSD: Fix the behavior of READ near OFFSET_MAX Dan Aloni reports: &amp;gt; Due to commit 8cfb9015280d (&amp;quot;NFS: Always provide aligned buffers to &amp;gt; the RPC read layers&amp;quot;) on the client, a read of 0xfff is aligned up &amp;gt; to server rsize of 0x1000. &amp;gt; &amp;gt; As a result, in a test where the server has a file of size &amp;gt; 0x7fffffffffffffff, and the client tries to read from the offset &amp;gt; 0x7ffffffffffff000, the read causes loff_t overflow in the server &amp;gt; and it returns an NFS code of EINVAL to the client. The client as &amp;gt; a result indefinitely retries the request. The Linux NFS client does not handle NFS?ERR_INVAL, even though all NFS specifications permit servers to return that status code for a READ. Instead of NFS?ERR_INVAL, have out-of-range READ requests succeed and return a short result. Set the EOF flag in the result to prevent the client from retrying the READ request. This behavior appears to be consistent with Solaris NFS servers. Note that NFSv3 and NFSv4 use u64 offset values on the wire. These must be converted to loff_t internally before use -- an implicit type cast is not adequate for this purpose. Otherwise VFS checks against sb-&amp;gt;s_maxbytes do not work properly.(CVE-2022-48827) In the Linux kernel, the following vulnerability has been resolved: net: can: j1939: enhanced error handlin…</p> https://cve.radiocsirt.org/vuln/oesa-2024-1961 https://cve.radiocsirt.org/vuln/ssa-265688 <p>An out-of-bounds (OOB) memory write flaw was found in the NFSD in the Linux kernel. Missing sanity may lead to a write beyond bmval[bmlen-1] in nfsd4_decode_bitmap4 in fs/nfsd/nfs4xdr.c. In this flaw, a local attacker with user privilege may gain access to out-of-bounds memory, leading to a system integrity and confidentiality threat. fs/nfsd/trace.h in the Linux kernel before 5.13.4 might allow remote attackers to cause a denial of service (out-of-bounds read in strlen) by sending NFS traffic when the trace event framework is being used for nfsd. SUNRPC: null pointer dereference in svc_rqst_free(). When alloc_pages_node() returns null in svc_rqst_alloc(), the null rq_scratch_page pointer will be dereferenced when calling put_page() in svc_rqst_free(). NFSD: READDIR buffer overflow. If a client sends a READDIR count argument that is too small (say, zero), then the buffer size calculation in the new init_dirlist helper functions results in an underflow, allowing the XDR stream functions to write beyond the actual buffer. This calculation has always been suspect. NFSD has never sanity- checked the READDIR count argument, but the old entry encoders managed the problem correctly. With the commits below, entry encoding changed, exposing the underflow to the pointer arithmetic in xdr_reserve_space(). Modern NFS clients attempt to retrieve as much data as possible for each READDIR request. nfsd: NULL dereference in nfs3svc_encode_getaclres. A NULL pointer dereference vulnerability…</p> <p>An out-of-bounds (OOB) memory write flaw was found in the NFSD in the Linux kernel. Missing sanity may lead to a write beyond bmval[bmlen-1] in nfsd4_decode_bitmap4 in fs/nfsd/nfs4xdr.c. In this flaw, a local attacker with user privilege may gain access to out-of-bounds memory, leading to a system integrity and confidentiality threat. fs/nfsd/trace.h in the Linux kernel before 5.13.4 might allow remote attackers to cause a denial of service (out-of-bounds read in strlen) by sending NFS traffic when the trace event framework is being used for nfsd. SUNRPC: null pointer dereference in svc_rqst_free(). When alloc_pages_node() returns null in svc_rqst_alloc(), the null rq_scratch_page pointer will be dereferenced when calling put_page() in svc_rqst_free(). NFSD: READDIR buffer overflow. If a client sends a READDIR count argument that is too small (say, zero), then the buffer size calculation in the new init_dirlist helper functions results in an underflow, allowing the XDR stream functions to write beyond the actual buffer. This calculation has always been suspect. NFSD has never sanity- checked the READDIR count argument, but the old entry encoders managed the problem correctly. With the commits below, entry encoding changed, exposing the underflow to the pointer arithmetic in xdr_reserve_space(). Modern NFS clients attempt to retrieve as much data as possible for each READDIR request. nfsd: NULL dereference in nfs3svc_encode_getaclres. A NULL pointer dereference vulnerability…</p> https://cve.radiocsirt.org/vuln/ssa-265688 https://cve.radiocsirt.org/vuln/suse-su-2024:2892-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:2892-1 https://cve.radiocsirt.org/vuln/ubuntu-cve-2024-42093 <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:Pro:18.04:LTS: linux-aws-5.4, Ubuntu:18.04:LTS: linux-azure, Ubuntu:18.04:LTS: linux-azure-5.3, Ubuntu:Pro:18.04:LTS: linux-azure-5.4, Ubuntu:18.04:LTS: linux-azure-edge, Ubuntu:18.04:LTS: linux-gcp, Ubuntu:18.04:LTS: linux-gcp-5.3 and 159 more</p> <p>In the Linux kernel, the following vulnerability has been resolved: net/dpaa2: Avoid explicit cpumask var allocation on stack For CONFIG_CPUMASK_OFFSTACK=y kernel, explicit allocation of cpumask variable on stack is not recommended since it can cause potential stack overflow. Instead, kernel code should always use *cpumask_var API(s) to allocate cpumask var in config-neutral way, leaving allocation strategy to CONFIG_CPUMASK_OFFSTACK. Use *cpumask_var API(s) to address it.</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:Pro:18.04:LTS: linux-aws-5.4, Ubuntu:18.04:LTS: linux-azure, Ubuntu:18.04:LTS: linux-azure-5.3, Ubuntu:Pro:18.04:LTS: linux-azure-5.4, Ubuntu:18.04:LTS: linux-azure-edge, Ubuntu:18.04:LTS: linux-gcp, Ubuntu:18.04:LTS: linux-gcp-5.3 and 159 more</p> <p>In the Linux kernel, the following vulnerability has been resolved: net/dpaa2: Avoid explicit cpumask var allocation on stack For CONFIG_CPUMASK_OFFSTACK=y kernel, explicit allocation of cpumask variable on stack is not recommended since it can cause potential stack overflow. Instead, kernel code should always use *cpumask_var API(s) to allocate cpumask var in config-neutral way, leaving allocation strategy to CONFIG_CPUMASK_OFFSTACK. Use *cpumask_var API(s) to address it.</p> https://cve.radiocsirt.org/vuln/ubuntu-cve-2024-42093 https://cve.radiocsirt.org/vuln/wid-sec-w-2024-1722 <p>Ein Angreifer kann mehrere Schwachstellen im Linux Kernel ausnutzen, um einen nicht näher spezifizierten Angriff durchzuführen.</p> <p>Ein 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-1722