https://db.gcve.eu Contains only the most 10 recent entries. http://www.rssboard.org/rss-specification python-feedgen en Mon, 02 Nov 2026 03:53:46 +0000 https://db.gcve.eu/vuln/certfr-2026-avi-1375 certfr-2026-avi-1375 https://db.gcve.eu/vuln/certfr-2026-avi-1375 https://db.gcve.eu/vuln/fkie_cve-2026-98862 <p>In the Linux kernel, the following vulnerability has been resolved:</p> <p>audit: fix exe mark UAF in kill_rules()</p> <p>kill_rules() removes mixed AUDIT_DIR and AUDIT_EXE rules when an audit tree is pruned. It drops entry-&gt;rule.exe before removing the rule from the RCU-visible filter lists.</p> <p>After a rule has been installed with AUDIT_ADD_RULE, which requires CAP_AUDIT_CONTROL, removing the watched directory can race with another task that is still evaluating the rule. In that case, fsnotify can free the executable mark before the reader reaches audit_mark_compare(), causing a use-after-free.</p> <p>KASAN reports:</p> <p>BUG: KASAN: slab-use-after-free in audit_mark_compare+0x8d/0xa0</p> <p>Unlink the published rules from the RCU-visible lists and retain them on tree-&gt;rules for cleanup. If any rule has an executable mark, wait for a single RCU grace period before removing the marks and scheduling the entries for freeing. Otherwise, call_rcu() already provides the required deferred freeing without a synchronous wait.</p> <p>In the Linux kernel, the following vulnerability has been resolved:</p> <p>audit: fix exe mark UAF in kill_rules()</p> <p>kill_rules() removes mixed AUDIT_DIR and AUDIT_EXE rules when an audit tree is pruned. It drops entry-&gt;rule.exe before removing the rule from the RCU-visible filter lists.</p> <p>After a rule has been installed with AUDIT_ADD_RULE, which requires CAP_AUDIT_CONTROL, removing the watched directory can race with another task that is still evaluating the rule. In that case, fsnotify can free the executable mark before the reader reaches audit_mark_compare(), causing a use-after-free.</p> <p>KASAN reports:</p> <p>BUG: KASAN: slab-use-after-free in audit_mark_compare+0x8d/0xa0</p> <p>Unlink the published rules from the RCU-visible lists and retain them on tree-&gt;rules for cleanup. If any rule has an executable mark, wait for a single RCU grace period before removing the marks and scheduling the entries for freeing. Otherwise, call_rcu() already provides the required deferred freeing without a synchronous wait.</p> https://db.gcve.eu/vuln/fkie_cve-2026-98862 https://db.gcve.eu/vuln/ghsa-73jm-mgrc-fg99 <p>In the Linux kernel, the following vulnerability has been resolved:</p> <p>audit: fix exe mark UAF in kill_rules()</p> <p>kill_rules() removes mixed AUDIT_DIR and AUDIT_EXE rules when an audit tree is pruned. It drops entry-&gt;rule.exe before removing the rule from the RCU-visible filter lists.</p> <p>After a rule has been installed with AUDIT_ADD_RULE, which requires CAP_AUDIT_CONTROL, removing the watched directory can race with another task that is still evaluating the rule. In that case, fsnotify can free the executable mark before the reader reaches audit_mark_compare(), causing a use-after-free.</p> <p>KASAN reports:</p> <p>BUG: KASAN: slab-use-after-free in audit_mark_compare+0x8d/0xa0</p> <p>Unlink the published rules from the RCU-visible lists and retain them on tree-&gt;rules for cleanup. If any rule has an executable mark, wait for a single RCU grace period before removing the marks and scheduling the entries for freeing. Otherwise, call_rcu() already provides the required deferred freeing without a synchronous wait.</p> <p>In the Linux kernel, the following vulnerability has been resolved:</p> <p>audit: fix exe mark UAF in kill_rules()</p> <p>kill_rules() removes mixed AUDIT_DIR and AUDIT_EXE rules when an audit tree is pruned. It drops entry-&gt;rule.exe before removing the rule from the RCU-visible filter lists.</p> <p>After a rule has been installed with AUDIT_ADD_RULE, which requires CAP_AUDIT_CONTROL, removing the watched directory can race with another task that is still evaluating the rule. In that case, fsnotify can free the executable mark before the reader reaches audit_mark_compare(), causing a use-after-free.</p> <p>KASAN reports:</p> <p>BUG: KASAN: slab-use-after-free in audit_mark_compare+0x8d/0xa0</p> <p>Unlink the published rules from the RCU-visible lists and retain them on tree-&gt;rules for cleanup. If any rule has an executable mark, wait for a single RCU grace period before removing the marks and scheduling the entries for freeing. Otherwise, call_rcu() already provides the required deferred freeing without a synchronous wait.</p> https://db.gcve.eu/vuln/ghsa-73jm-mgrc-fg99 https://db.gcve.eu/vuln/msrc_cve-2026-98862 msrc_CVE-2026-98862 https://db.gcve.eu/vuln/msrc_cve-2026-98862 https://db.gcve.eu/vuln/ubuntu-cve-2026-98862 <p><strong>Affected:</strong> 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, Ubuntu:16.04:LTS: linux-hwe-edge and 246 more</p> <p>In the Linux kernel, the following vulnerability has been resolved: audit: fix exe mark UAF in kill_rules() kill_rules() removes mixed AUDIT_DIR and AUDIT_EXE rules when an audit tree is pruned. It drops entry-&gt;rule.exe before removing the rule from the RCU-visible filter lists. After a rule has been installed with AUDIT_ADD_RULE, which requires CAP_AUDIT_CONTROL, removing the watched directory can race with another task that is still evaluating the rule. In that case, fsnotify can free the executable mark before the reader reaches audit_mark_compare(), causing a use-after-free. KASAN reports: BUG: KASAN: slab-use-after-free in audit_mark_compare+0x8d/0xa0 Unlink the published rules from the RCU-visible lists and retain them on tree-&gt;rules for cleanup. If any rule has an executable mark, wait for a single RCU grace period before removing the marks and scheduling the entries for freeing. Otherwise, call_rcu() already provides the required deferred freeing without a synchronous wait.</p> <p><strong>Affected:</strong> 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, Ubuntu:16.04:LTS: linux-hwe-edge and 246 more</p> <p>In the Linux kernel, the following vulnerability has been resolved: audit: fix exe mark UAF in kill_rules() kill_rules() removes mixed AUDIT_DIR and AUDIT_EXE rules when an audit tree is pruned. It drops entry-&gt;rule.exe before removing the rule from the RCU-visible filter lists. After a rule has been installed with AUDIT_ADD_RULE, which requires CAP_AUDIT_CONTROL, removing the watched directory can race with another task that is still evaluating the rule. In that case, fsnotify can free the executable mark before the reader reaches audit_mark_compare(), causing a use-after-free. KASAN reports: BUG: KASAN: slab-use-after-free in audit_mark_compare+0x8d/0xa0 Unlink the published rules from the RCU-visible lists and retain them on tree-&gt;rules for cleanup. If any rule has an executable mark, wait for a single RCU grace period before removing the marks and scheduling the entries for freeing. Otherwise, call_rcu() already provides the required deferred freeing without a synchronous wait.</p> https://db.gcve.eu/vuln/ubuntu-cve-2026-98862