https://vulnerability.circl.lu Contains only the most 10 recent entries. http://www.rssboard.org/rss-specification python-feedgen en Sat, 03 Oct 2026 19:43:26 +0000 https://vulnerability.circl.lu/vuln/bell-cve-2026-72220 <p><strong>Affected:</strong> Alpaquita:stream: linux-lts</p> <p><strong>Affected:</strong> Alpaquita:stream: linux-lts</p> https://vulnerability.circl.lu/vuln/bell-cve-2026-72220 https://vulnerability.circl.lu/vuln/certfr-2026-avi-1229 certfr-2026-avi-1229 https://vulnerability.circl.lu/vuln/certfr-2026-avi-1229 https://vulnerability.circl.lu/vuln/fkie_cve-2026-72220 <p>In the Linux kernel, the following vulnerability has been resolved:</p> <p>sunrpc: harden rq_procinfo lifecycle to prevent double-free</p> <p>The svc_release_rqst() function executes the callback inside rqstp-&gt;rq_procinfo-&gt;pc_release. However, if a worker thread begins processing a new request and encounters an early error path (e.g., unsupported protocol, short frame, or bad auth) before a valid rq_procinfo is installed, a stale release hook can be re-triggered against reused state from the previous RPC, resulting in a double-free or use-after-free vulnerability.</p> <p>Harden the lifecycle of rq_procinfo by: 1. Ensuring svc_release_rqst() always clears rq_procinfo after the optional pc_release() call, regardless of whether the hook exists. 2. Explicitly clearing rq_procinfo at request entry in svc_process() before any early decode or drop paths. 3. Ensuring svc_process_bc() does the same at backchannel entry.</p> <p>This guarantees that error flows will not encounter a non-NULL stale rq_procinfo pointer when there is nothing to release.</p> <p>In the Linux kernel, the following vulnerability has been resolved:</p> <p>sunrpc: harden rq_procinfo lifecycle to prevent double-free</p> <p>The svc_release_rqst() function executes the callback inside rqstp-&gt;rq_procinfo-&gt;pc_release. However, if a worker thread begins processing a new request and encounters an early error path (e.g., unsupported protocol, short frame, or bad auth) before a valid rq_procinfo is installed, a stale release hook can be re-triggered against reused state from the previous RPC, resulting in a double-free or use-after-free vulnerability.</p> <p>Harden the lifecycle of rq_procinfo by: 1. Ensuring svc_release_rqst() always clears rq_procinfo after the optional pc_release() call, regardless of whether the hook exists. 2. Explicitly clearing rq_procinfo at request entry in svc_process() before any early decode or drop paths. 3. Ensuring svc_process_bc() does the same at backchannel entry.</p> <p>This guarantees that error flows will not encounter a non-NULL stale rq_procinfo pointer when there is nothing to release.</p> https://vulnerability.circl.lu/vuln/fkie_cve-2026-72220 https://vulnerability.circl.lu/vuln/ghsa-m4wq-7wv4-xpq8 <p>In the Linux kernel, the following vulnerability has been resolved:</p> <p>sunrpc: harden rq_procinfo lifecycle to prevent double-free</p> <p>The svc_release_rqst() function executes the callback inside rqstp-&gt;rq_procinfo-&gt;pc_release. However, if a worker thread begins processing a new request and encounters an early error path (e.g., unsupported protocol, short frame, or bad auth) before a valid rq_procinfo is installed, a stale release hook can be re-triggered against reused state from the previous RPC, resulting in a double-free or use-after-free vulnerability.</p> <p>Harden the lifecycle of rq_procinfo by: 1. Ensuring svc_release_rqst() always clears rq_procinfo after the optional pc_release() call, regardless of whether the hook exists. 2. Explicitly clearing rq_procinfo at request entry in svc_process() before any early decode or drop paths. 3. Ensuring svc_process_bc() does the same at backchannel entry.</p> <p>This guarantees that error flows will not encounter a non-NULL stale rq_procinfo pointer when there is nothing to release.</p> <p>In the Linux kernel, the following vulnerability has been resolved:</p> <p>sunrpc: harden rq_procinfo lifecycle to prevent double-free</p> <p>The svc_release_rqst() function executes the callback inside rqstp-&gt;rq_procinfo-&gt;pc_release. However, if a worker thread begins processing a new request and encounters an early error path (e.g., unsupported protocol, short frame, or bad auth) before a valid rq_procinfo is installed, a stale release hook can be re-triggered against reused state from the previous RPC, resulting in a double-free or use-after-free vulnerability.</p> <p>Harden the lifecycle of rq_procinfo by: 1. Ensuring svc_release_rqst() always clears rq_procinfo after the optional pc_release() call, regardless of whether the hook exists. 2. Explicitly clearing rq_procinfo at request entry in svc_process() before any early decode or drop paths. 3. Ensuring svc_process_bc() does the same at backchannel entry.</p> <p>This guarantees that error flows will not encounter a non-NULL stale rq_procinfo pointer when there is nothing to release.</p> https://vulnerability.circl.lu/vuln/ghsa-m4wq-7wv4-xpq8 https://vulnerability.circl.lu/vuln/ubuntu-cve-2026-72220 <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 115 more</p> <p>In the Linux kernel, the following vulnerability has been resolved: sunrpc: harden rq_procinfo lifecycle to prevent double-free The svc_release_rqst() function executes the callback inside rqstp-&gt;rq_procinfo-&gt;pc_release. However, if a worker thread begins processing a new request and encounters an early error path (e.g., unsupported protocol, short frame, or bad auth) before a valid rq_procinfo is installed, a stale release hook can be re-triggered against reused state from the previous RPC, resulting in a double-free or use-after-free vulnerability. Harden the lifecycle of rq_procinfo by: 1. Ensuring svc_release_rqst() always clears rq_procinfo after the optional pc_release() call, regardless of whether the hook exists. 2. Explicitly clearing rq_procinfo at request entry in svc_process() before any early decode or drop paths. 3. Ensuring svc_process_bc() does the same at backchannel entry. This guarantees that error flows will not encounter a non-NULL stale rq_procinfo pointer when there is nothing to release.</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 115 more</p> <p>In the Linux kernel, the following vulnerability has been resolved: sunrpc: harden rq_procinfo lifecycle to prevent double-free The svc_release_rqst() function executes the callback inside rqstp-&gt;rq_procinfo-&gt;pc_release. However, if a worker thread begins processing a new request and encounters an early error path (e.g., unsupported protocol, short frame, or bad auth) before a valid rq_procinfo is installed, a stale release hook can be re-triggered against reused state from the previous RPC, resulting in a double-free or use-after-free vulnerability. Harden the lifecycle of rq_procinfo by: 1. Ensuring svc_release_rqst() always clears rq_procinfo after the optional pc_release() call, regardless of whether the hook exists. 2. Explicitly clearing rq_procinfo at request entry in svc_process() before any early decode or drop paths. 3. Ensuring svc_process_bc() does the same at backchannel entry. This guarantees that error flows will not encounter a non-NULL stale rq_procinfo pointer when there is nothing to release.</p> https://vulnerability.circl.lu/vuln/ubuntu-cve-2026-72220 https://vulnerability.circl.lu/vuln/wid-sec-w-2026-2852 <p>Ein Angreifer kann mehrere Schwachstellen in Linux Kernel ausnutzen, um einen Denial of Service herbeizuführen oder einen nicht näher spezifizierten Angriff durchzuführen.</p> <p>Ein Angreifer kann mehrere Schwachstellen in Linux Kernel ausnutzen, um einen Denial of Service herbeizuführen oder einen nicht näher spezifizierten Angriff durchzuführen.</p> https://vulnerability.circl.lu/vuln/wid-sec-w-2026-2852