https://cve.radiocsirt.org Contains only the most 10 recent entries. http://www.rssboard.org/rss-specification python-feedgen en Mon, 05 Oct 2026 16:34:30 +0000 https://cve.radiocsirt.org/vuln/cve-2026-89762 <p><strong>Affected:</strong> Linux</p> <p>In the Linux kernel, the following vulnerability has been resolved:</p> <p>apparmor: fix cred UAF caused by begin_current_label_crit_section()</p> <p>AppArmor&#39;s begin_current_label_crit_section() is a scary function called from lots of LSM hooks (in particular VFS/socket-related ones) that checks if the label referenced by the current creds is marked FLAG_STALE, and if so, attempts to use aa_replace_current_label() to replace the creds with an updated version that uses a new label.</p> <p>The first problem with this is that it would directly lead to UAF of `struct cred` if anything in the kernel takes a pointer to the current creds and accesses these past a security hook invocation that replaces creds, like so: ``` const struct cred *cred = current_cred(); alloc_file_pseudo(...); uid_t uid = cred-&gt;euid; ``` I don&#39;t know if anything in the kernel actually does this, but I think it is very surprising that this pattern could lead to UAF.</p> <p>The second problem is that things go wrong when aa_replace_current_label() runs with overridden credentials. aa_replace_current_label() bails out if `current_cred() != current_real_cred()` (mirroring the check in proc_pid_attr_write()), but this check can&#39;t actually reliably detect overridden credentials because the overridden creds can be the same as the objective creds.</p> <p>So in approximately the following scenario, things go wrong:</p> <p>1. task begins with &lt;creds A&gt; (as both objective and subjective creds), with refcount=2 2. task grabs an extra reference on &lt;c…</p> <p><strong>Affected:</strong> Linux</p> <p>In the Linux kernel, the following vulnerability has been resolved:</p> <p>apparmor: fix cred UAF caused by begin_current_label_crit_section()</p> <p>AppArmor&#39;s begin_current_label_crit_section() is a scary function called from lots of LSM hooks (in particular VFS/socket-related ones) that checks if the label referenced by the current creds is marked FLAG_STALE, and if so, attempts to use aa_replace_current_label() to replace the creds with an updated version that uses a new label.</p> <p>The first problem with this is that it would directly lead to UAF of `struct cred` if anything in the kernel takes a pointer to the current creds and accesses these past a security hook invocation that replaces creds, like so: ``` const struct cred *cred = current_cred(); alloc_file_pseudo(...); uid_t uid = cred-&gt;euid; ``` I don&#39;t know if anything in the kernel actually does this, but I think it is very surprising that this pattern could lead to UAF.</p> <p>The second problem is that things go wrong when aa_replace_current_label() runs with overridden credentials. aa_replace_current_label() bails out if `current_cred() != current_real_cred()` (mirroring the check in proc_pid_attr_write()), but this check can&#39;t actually reliably detect overridden credentials because the overridden creds can be the same as the objective creds.</p> <p>So in approximately the following scenario, things go wrong:</p> <p>1. task begins with &lt;creds A&gt; (as both objective and subjective creds), with refcount=2 2. task grabs an extra reference on &lt;c…</p> https://cve.radiocsirt.org/vuln/cve-2026-89762