https://cve.radiocsirt.org Contains only the most 10 recent entries. http://www.rssboard.org/rss-specification python-feedgen en Sat, 03 Oct 2026 10:05:49 +0000 https://cve.radiocsirt.org/vuln/bdu:2025-03429 bdu:2025-03429 https://cve.radiocsirt.org/vuln/bdu:2025-03429 https://cve.radiocsirt.org/vuln/bell-cve-2024-40942 <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-40942 https://cve.radiocsirt.org/vuln/certfr-2024-avi-0613 certfr-2024-avi-0613 https://cve.radiocsirt.org/vuln/certfr-2024-avi-0613 https://cve.radiocsirt.org/vuln/euvd-2026-317017 EUVD-2026-317017 https://cve.radiocsirt.org/vuln/euvd-2026-317017 https://cve.radiocsirt.org/vuln/fkie_cve-2024-40942 <p>In the Linux kernel, the following vulnerability has been resolved:</p> <p>wifi: mac80211: mesh: Fix leak of mesh_preq_queue objects</p> <p>The hwmp code use objects of type mesh_preq_queue, added to a list in ieee80211_if_mesh, to keep track of mpath we need to resolve. If the mpath gets deleted, ex mesh interface is removed, the entries in that list will never get cleaned. Fix this by flushing all corresponding items of the preq_queue in mesh_path_flush_pending().</p> <p>This should take care of KASAN reports like this:</p> <p>unreferenced object 0xffff00000668d800 (size 128): comm &#34;kworker/u8:4&#34;, pid 67, jiffies 4295419552 (age 1836.444s) hex dump (first 32 bytes): 00 1f 05 09 00 00 ff ff 00 d5 68 06 00 00 ff ff ..........h..... 8e 97 ea eb 3e b8 01 00 00 00 00 00 00 00 00 00 ....&gt;........... backtrace: [&lt;000000007302a0b6&gt;] __kmem_cache_alloc_node+0x1e0/0x35c [&lt;00000000049bd418&gt;] kmalloc_trace+0x34/0x80 [&lt;0000000000d792bb&gt;] mesh_queue_preq+0x44/0x2a8 [&lt;00000000c99c3696&gt;] mesh_nexthop_resolve+0x198/0x19c [&lt;00000000926bf598&gt;] ieee80211_xmit+0x1d0/0x1f4 [&lt;00000000fc8c2284&gt;] __ieee80211_subif_start_xmit+0x30c/0x764 [&lt;000000005926ee38&gt;] ieee80211_subif_start_xmit+0x9c/0x7a4 [&lt;000000004c86e916&gt;] dev_hard_start_xmit+0x174/0x440 [&lt;0000000023495647&gt;] __dev_queue_xmit+0xe24/0x111c [&lt;00000000cfe9ca78&gt;] batadv_send_skb_packet+0x180/0x1e4 [&lt;000000007bacc5d5&gt;] batadv_v_elp_periodic_work+0x2f4/0x508 [&lt;00000000adc3cd94&gt;] process_one_work+0x4b8/0xa1…</p> <p>In the Linux kernel, the following vulnerability has been resolved:</p> <p>wifi: mac80211: mesh: Fix leak of mesh_preq_queue objects</p> <p>The hwmp code use objects of type mesh_preq_queue, added to a list in ieee80211_if_mesh, to keep track of mpath we need to resolve. If the mpath gets deleted, ex mesh interface is removed, the entries in that list will never get cleaned. Fix this by flushing all corresponding items of the preq_queue in mesh_path_flush_pending().</p> <p>This should take care of KASAN reports like this:</p> <p>unreferenced object 0xffff00000668d800 (size 128): comm &#34;kworker/u8:4&#34;, pid 67, jiffies 4295419552 (age 1836.444s) hex dump (first 32 bytes): 00 1f 05 09 00 00 ff ff 00 d5 68 06 00 00 ff ff ..........h..... 8e 97 ea eb 3e b8 01 00 00 00 00 00 00 00 00 00 ....&gt;........... backtrace: [&lt;000000007302a0b6&gt;] __kmem_cache_alloc_node+0x1e0/0x35c [&lt;00000000049bd418&gt;] kmalloc_trace+0x34/0x80 [&lt;0000000000d792bb&gt;] mesh_queue_preq+0x44/0x2a8 [&lt;00000000c99c3696&gt;] mesh_nexthop_resolve+0x198/0x19c [&lt;00000000926bf598&gt;] ieee80211_xmit+0x1d0/0x1f4 [&lt;00000000fc8c2284&gt;] __ieee80211_subif_start_xmit+0x30c/0x764 [&lt;000000005926ee38&gt;] ieee80211_subif_start_xmit+0x9c/0x7a4 [&lt;000000004c86e916&gt;] dev_hard_start_xmit+0x174/0x440 [&lt;0000000023495647&gt;] __dev_queue_xmit+0xe24/0x111c [&lt;00000000cfe9ca78&gt;] batadv_send_skb_packet+0x180/0x1e4 [&lt;000000007bacc5d5&gt;] batadv_v_elp_periodic_work+0x2f4/0x508 [&lt;00000000adc3cd94&gt;] process_one_work+0x4b8/0xa1…</p> https://cve.radiocsirt.org/vuln/fkie_cve-2024-40942 https://cve.radiocsirt.org/vuln/ghsa-jj67-2389-vrqj <p>In the Linux kernel, the following vulnerability has been resolved:</p> <p>wifi: mac80211: mesh: Fix leak of mesh_preq_queue objects</p> <p>The hwmp code use objects of type mesh_preq_queue, added to a list in ieee80211_if_mesh, to keep track of mpath we need to resolve. If the mpath gets deleted, ex mesh interface is removed, the entries in that list will never get cleaned. Fix this by flushing all corresponding items of the preq_queue in mesh_path_flush_pending().</p> <p>This should take care of KASAN reports like this:</p> <p>unreferenced object 0xffff00000668d800 (size 128): comm &#34;kworker/u8:4&#34;, pid 67, jiffies 4295419552 (age 1836.444s) hex dump (first 32 bytes): 00 1f 05 09 00 00 ff ff 00 d5 68 06 00 00 ff ff ..........h..... 8e 97 ea eb 3e b8 01 00 00 00 00 00 00 00 00 00 ....&gt;........... backtrace: [&lt;000000007302a0b6&gt;] __kmem_cache_alloc_node+0x1e0/0x35c [&lt;00000000049bd418&gt;] kmalloc_trace+0x34/0x80 [&lt;0000000000d792bb&gt;] mesh_queue_preq+0x44/0x2a8 [&lt;00000000c99c3696&gt;] mesh_nexthop_resolve+0x198/0x19c [&lt;00000000926bf598&gt;] ieee80211_xmit+0x1d0/0x1f4 [&lt;00000000fc8c2284&gt;] __ieee80211_subif_start_xmit+0x30c/0x764 [&lt;000000005926ee38&gt;] ieee80211_subif_start_xmit+0x9c/0x7a4 [&lt;000000004c86e916&gt;] dev_hard_start_xmit+0x174/0x440 [&lt;0000000023495647&gt;] __dev_queue_xmit+0xe24/0x111c [&lt;00000000cfe9ca78&gt;] batadv_send_skb_packet+0x180/0x1e4 [&lt;000000007bacc5d5&gt;] batadv_v_elp_periodic_work+0x2f4/0x508 [&lt;00000000adc3cd94&gt;] process_one_work+0x4b8/0xa1…</p> <p>In the Linux kernel, the following vulnerability has been resolved:</p> <p>wifi: mac80211: mesh: Fix leak of mesh_preq_queue objects</p> <p>The hwmp code use objects of type mesh_preq_queue, added to a list in ieee80211_if_mesh, to keep track of mpath we need to resolve. If the mpath gets deleted, ex mesh interface is removed, the entries in that list will never get cleaned. Fix this by flushing all corresponding items of the preq_queue in mesh_path_flush_pending().</p> <p>This should take care of KASAN reports like this:</p> <p>unreferenced object 0xffff00000668d800 (size 128): comm &#34;kworker/u8:4&#34;, pid 67, jiffies 4295419552 (age 1836.444s) hex dump (first 32 bytes): 00 1f 05 09 00 00 ff ff 00 d5 68 06 00 00 ff ff ..........h..... 8e 97 ea eb 3e b8 01 00 00 00 00 00 00 00 00 00 ....&gt;........... backtrace: [&lt;000000007302a0b6&gt;] __kmem_cache_alloc_node+0x1e0/0x35c [&lt;00000000049bd418&gt;] kmalloc_trace+0x34/0x80 [&lt;0000000000d792bb&gt;] mesh_queue_preq+0x44/0x2a8 [&lt;00000000c99c3696&gt;] mesh_nexthop_resolve+0x198/0x19c [&lt;00000000926bf598&gt;] ieee80211_xmit+0x1d0/0x1f4 [&lt;00000000fc8c2284&gt;] __ieee80211_subif_start_xmit+0x30c/0x764 [&lt;000000005926ee38&gt;] ieee80211_subif_start_xmit+0x9c/0x7a4 [&lt;000000004c86e916&gt;] dev_hard_start_xmit+0x174/0x440 [&lt;0000000023495647&gt;] __dev_queue_xmit+0xe24/0x111c [&lt;00000000cfe9ca78&gt;] batadv_send_skb_packet+0x180/0x1e4 [&lt;000000007bacc5d5&gt;] batadv_v_elp_periodic_work+0x2f4/0x508 [&lt;00000000adc3cd94&gt;] process_one_work+0x4b8/0xa1…</p> https://cve.radiocsirt.org/vuln/ghsa-jj67-2389-vrqj 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/oesa-2024-1944 <p><strong>Affected:</strong> openEuler:20.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: usb: musb: tusb6010: check return value after calling platform_get_resource() It will cause null-ptr-deref if platform_get_resource() returns NULL, we need check the return value.(CVE-2021-47181) In the Linux kernel, the following vulnerability has been resolved: btrfs: fix memory ordering between normal and ordered work functions Ordered work functions aren&amp;apos;t guaranteed to be handled by the same thread which executed the normal work functions. The only way execution between normal/ordered functions is synchronized is via the WORK_DONE_BIT, unfortunately the used bitops don&amp;apos;t guarantee any ordering whatsoever. This manifested as seemingly inexplicable crashes on ARM64, where async_chunk::inode is seen as non-null in async_cow_submit which causes submit_compressed_extents to be called and crash occurs because async_chunk::inode suddenly became NULL. The call trace was similar to: pc : submit_compressed_extents+0x38/0x3d0 lr : async_cow_submit+0x50/0xd0 sp : ffff800015d4bc20 &amp;lt;registers omitted for brevity&amp;gt; Call trace: submit_compressed_extents+0x38/0x3d0 async_cow_submit+0x50/0xd0 run_ordered_work+0xc8/0x280 btrfs_work_helper+0x98/0x250 process_one_work+0x1f0/0x4ac worker_thread+0x188/0x504 kthread+0x110/0x114 ret_from_fork+0x10/0x18…</p> <p><strong>Affected:</strong> openEuler:20.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: usb: musb: tusb6010: check return value after calling platform_get_resource() It will cause null-ptr-deref if platform_get_resource() returns NULL, we need check the return value.(CVE-2021-47181) In the Linux kernel, the following vulnerability has been resolved: btrfs: fix memory ordering between normal and ordered work functions Ordered work functions aren&amp;apos;t guaranteed to be handled by the same thread which executed the normal work functions. The only way execution between normal/ordered functions is synchronized is via the WORK_DONE_BIT, unfortunately the used bitops don&amp;apos;t guarantee any ordering whatsoever. This manifested as seemingly inexplicable crashes on ARM64, where async_chunk::inode is seen as non-null in async_cow_submit which causes submit_compressed_extents to be called and crash occurs because async_chunk::inode suddenly became NULL. The call trace was similar to: pc : submit_compressed_extents+0x38/0x3d0 lr : async_cow_submit+0x50/0xd0 sp : ffff800015d4bc20 &amp;lt;registers omitted for brevity&amp;gt; Call trace: submit_compressed_extents+0x38/0x3d0 async_cow_submit+0x50/0xd0 run_ordered_work+0xc8/0x280 btrfs_work_helper+0x98/0x250 process_one_work+0x1f0/0x4ac worker_thread+0x188/0x504 kthread+0x110/0x114 ret_from_fork+0x10/0x18…</p> https://cve.radiocsirt.org/vuln/oesa-2024-1944 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-40942 <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 184 more</p> <p>In the Linux kernel, the following vulnerability has been resolved: wifi: mac80211: mesh: Fix leak of mesh_preq_queue objects The hwmp code use objects of type mesh_preq_queue, added to a list in ieee80211_if_mesh, to keep track of mpath we need to resolve. If the mpath gets deleted, ex mesh interface is removed, the entries in that list will never get cleaned. Fix this by flushing all corresponding items of the preq_queue in mesh_path_flush_pending(). This should take care of KASAN reports like this: unreferenced object 0xffff00000668d800 (size 128): comm &#34;kworker/u8:4&#34;, pid 67, jiffies 4295419552 (age 1836.444s) hex dump (first 32 bytes): 00 1f 05 09 00 00 ff ff 00 d5 68 06 00 00 ff ff ..........h..... 8e 97 ea eb 3e b8 01 00 00 00 00 00 00 00 00 00 ....&gt;........... backtrace: [&lt;000000007302a0b6&gt;] __kmem_cache_alloc_node+0x1e0/0x35c [&lt;00000000049bd418&gt;] kmalloc_trace+0x34/0x80 [&lt;0000000000d792bb&gt;] mesh_queue_preq+0x44/0x2a8 [&lt;00000000c99c3696&gt;] mesh_nexthop_resolve+0x198/0x19c [&lt;00000000926bf598&gt;] ieee80211_xmit+0x1d0/0x1f4 [&lt;00000000fc8c2284&gt;] __ieee80211_subif_start_xmit+0x30c/0x764 [&lt;000000005926ee38&gt;] ieee80211_subif_start_xmit+0x9c/0x7a4 [&lt;000000004c86e916&gt;] dev_hard_start_xmit+0x174/0x440 [&lt;0000000023495647&gt;] __dev_queue_xmit+0xe24/0x111c [&lt;00000000cfe9ca78&gt;] batadv_send_skb_packet+0x180/0x1e4 [&lt;000000007bacc5d5&gt;] batadv_v_elp_periodic_work+0x2f4/0x508 [&lt;00000000adc3cd94&gt;] process_one_work+0x4b8/0xa1c…</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 184 more</p> <p>In the Linux kernel, the following vulnerability has been resolved: wifi: mac80211: mesh: Fix leak of mesh_preq_queue objects The hwmp code use objects of type mesh_preq_queue, added to a list in ieee80211_if_mesh, to keep track of mpath we need to resolve. If the mpath gets deleted, ex mesh interface is removed, the entries in that list will never get cleaned. Fix this by flushing all corresponding items of the preq_queue in mesh_path_flush_pending(). This should take care of KASAN reports like this: unreferenced object 0xffff00000668d800 (size 128): comm &#34;kworker/u8:4&#34;, pid 67, jiffies 4295419552 (age 1836.444s) hex dump (first 32 bytes): 00 1f 05 09 00 00 ff ff 00 d5 68 06 00 00 ff ff ..........h..... 8e 97 ea eb 3e b8 01 00 00 00 00 00 00 00 00 00 ....&gt;........... backtrace: [&lt;000000007302a0b6&gt;] __kmem_cache_alloc_node+0x1e0/0x35c [&lt;00000000049bd418&gt;] kmalloc_trace+0x34/0x80 [&lt;0000000000d792bb&gt;] mesh_queue_preq+0x44/0x2a8 [&lt;00000000c99c3696&gt;] mesh_nexthop_resolve+0x198/0x19c [&lt;00000000926bf598&gt;] ieee80211_xmit+0x1d0/0x1f4 [&lt;00000000fc8c2284&gt;] __ieee80211_subif_start_xmit+0x30c/0x764 [&lt;000000005926ee38&gt;] ieee80211_subif_start_xmit+0x9c/0x7a4 [&lt;000000004c86e916&gt;] dev_hard_start_xmit+0x174/0x440 [&lt;0000000023495647&gt;] __dev_queue_xmit+0xe24/0x111c [&lt;00000000cfe9ca78&gt;] batadv_send_skb_packet+0x180/0x1e4 [&lt;000000007bacc5d5&gt;] batadv_v_elp_periodic_work+0x2f4/0x508 [&lt;00000000adc3cd94&gt;] process_one_work+0x4b8/0xa1c…</p> https://cve.radiocsirt.org/vuln/ubuntu-cve-2024-40942 https://cve.radiocsirt.org/vuln/wid-sec-w-2024-1607 <p>Ein lokaler Angreifer kann mehrere Schwachstellen im Linux-Kernel ausnutzen, um seine Privilegien zu erweitern, einen Denial-of-Service-Zustand zu erzeugen, vertrauliche Informationen offenzulegen oder einen unspezifischen Angriff durchzuführen.</p> <p>Ein lokaler Angreifer kann mehrere Schwachstellen im Linux-Kernel ausnutzen, um seine Privilegien zu erweitern, einen Denial-of-Service-Zustand zu erzeugen, vertrauliche Informationen offenzulegen oder einen unspezifischen Angriff durchzuführen.</p> https://cve.radiocsirt.org/vuln/wid-sec-w-2024-1607