https://cve.radiocsirt.org Contains only the most 10 recent entries. http://www.rssboard.org/rss-specification python-feedgen en Fri, 09 Oct 2026 09:22:18 +0000 https://cve.radiocsirt.org/vuln/bdu:2026-12435 bdu:2026-12435 https://cve.radiocsirt.org/vuln/bdu:2026-12435 https://cve.radiocsirt.org/vuln/bell-cve-2026-23012 <p><strong>Affected:</strong> Alpaquita:stream: linux-lts</p> <p><strong>Affected:</strong> Alpaquita:stream: linux-lts</p> https://cve.radiocsirt.org/vuln/bell-cve-2026-23012 https://cve.radiocsirt.org/vuln/certfr-2026-avi-0926 certfr-2026-avi-0926 https://cve.radiocsirt.org/vuln/certfr-2026-avi-0926 https://cve.radiocsirt.org/vuln/euvd-2026-315288 EUVD-2026-315288 https://cve.radiocsirt.org/vuln/euvd-2026-315288 https://cve.radiocsirt.org/vuln/fkie_cve-2026-23012 <p>In the Linux kernel, the following vulnerability has been resolved:</p> <p>mm/damon/core: remove call_control in inactive contexts</p> <p>If damon_call() is executed against a DAMON context that is not running, the function returns error while keeping the damon_call_control object linked to the context&#39;s call_controls list. Let&#39;s suppose the object is deallocated after the damon_call(), and yet another damon_call() is executed against the same context. The function tries to add the new damon_call_control object to the call_controls list, which still has the pointer to the previous damon_call_control object, which is deallocated. As a result, use-after-free happens.</p> <p>This can actually be triggered using the DAMON sysfs interface. It is not easily exploitable since it requires the sysfs write permission and making a definitely weird file writes, though. Please refer to the report for more details about the issue reproduction steps.</p> <p>Fix the issue by making two changes. Firstly, move the final kdamond_call() for cancelling all existing damon_call() requests from terminating DAMON context to be done before the ctx-&gt;kdamond reset. This makes any code that sees NULL ctx-&gt;kdamond can safely assume the context may not access damon_call() requests anymore. Secondly, let damon_call() to cleanup the damon_call_control objects that were added to the already-terminated DAMON context, before returning the error.</p> <p>In the Linux kernel, the following vulnerability has been resolved:</p> <p>mm/damon/core: remove call_control in inactive contexts</p> <p>If damon_call() is executed against a DAMON context that is not running, the function returns error while keeping the damon_call_control object linked to the context&#39;s call_controls list. Let&#39;s suppose the object is deallocated after the damon_call(), and yet another damon_call() is executed against the same context. The function tries to add the new damon_call_control object to the call_controls list, which still has the pointer to the previous damon_call_control object, which is deallocated. As a result, use-after-free happens.</p> <p>This can actually be triggered using the DAMON sysfs interface. It is not easily exploitable since it requires the sysfs write permission and making a definitely weird file writes, though. Please refer to the report for more details about the issue reproduction steps.</p> <p>Fix the issue by making two changes. Firstly, move the final kdamond_call() for cancelling all existing damon_call() requests from terminating DAMON context to be done before the ctx-&gt;kdamond reset. This makes any code that sees NULL ctx-&gt;kdamond can safely assume the context may not access damon_call() requests anymore. Secondly, let damon_call() to cleanup the damon_call_control objects that were added to the already-terminated DAMON context, before returning the error.</p> https://cve.radiocsirt.org/vuln/fkie_cve-2026-23012 https://cve.radiocsirt.org/vuln/ghsa-mprh-g3xh-wh7r <p>In the Linux kernel, the following vulnerability has been resolved:</p> <p>mm/damon/core: remove call_control in inactive contexts</p> <p>If damon_call() is executed against a DAMON context that is not running, the function returns error while keeping the damon_call_control object linked to the context&#39;s call_controls list. Let&#39;s suppose the object is deallocated after the damon_call(), and yet another damon_call() is executed against the same context. The function tries to add the new damon_call_control object to the call_controls list, which still has the pointer to the previous damon_call_control object, which is deallocated. As a result, use-after-free happens.</p> <p>This can actually be triggered using the DAMON sysfs interface. It is not easily exploitable since it requires the sysfs write permission and making a definitely weird file writes, though. Please refer to the report for more details about the issue reproduction steps.</p> <p>Fix the issue by making two changes. Firstly, move the final kdamond_call() for cancelling all existing damon_call() requests from terminating DAMON context to be done before the ctx-&gt;kdamond reset. This makes any code that sees NULL ctx-&gt;kdamond can safely assume the context may not access damon_call() requests anymore. Secondly, let damon_call() to cleanup the damon_call_control objects that were added to the already-terminated DAMON context, before returning the error.</p> <p>In the Linux kernel, the following vulnerability has been resolved:</p> <p>mm/damon/core: remove call_control in inactive contexts</p> <p>If damon_call() is executed against a DAMON context that is not running, the function returns error while keeping the damon_call_control object linked to the context&#39;s call_controls list. Let&#39;s suppose the object is deallocated after the damon_call(), and yet another damon_call() is executed against the same context. The function tries to add the new damon_call_control object to the call_controls list, which still has the pointer to the previous damon_call_control object, which is deallocated. As a result, use-after-free happens.</p> <p>This can actually be triggered using the DAMON sysfs interface. It is not easily exploitable since it requires the sysfs write permission and making a definitely weird file writes, though. Please refer to the report for more details about the issue reproduction steps.</p> <p>Fix the issue by making two changes. Firstly, move the final kdamond_call() for cancelling all existing damon_call() requests from terminating DAMON context to be done before the ctx-&gt;kdamond reset. This makes any code that sees NULL ctx-&gt;kdamond can safely assume the context may not access damon_call() requests anymore. Secondly, let damon_call() to cleanup the damon_call_control objects that were added to the already-terminated DAMON context, before returning the error.</p> https://cve.radiocsirt.org/vuln/ghsa-mprh-g3xh-wh7r https://cve.radiocsirt.org/vuln/ubuntu-cve-2026-23012 <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 99 more</p> <p>In the Linux kernel, the following vulnerability has been resolved: mm/damon/core: remove call_control in inactive contexts If damon_call() is executed against a DAMON context that is not running, the function returns error while keeping the damon_call_control object linked to the context&#39;s call_controls list. Let&#39;s suppose the object is deallocated after the damon_call(), and yet another damon_call() is executed against the same context. The function tries to add the new damon_call_control object to the call_controls list, which still has the pointer to the previous damon_call_control object, which is deallocated. As a result, use-after-free happens. This can actually be triggered using the DAMON sysfs interface. It is not easily exploitable since it requires the sysfs write permission and making a definitely weird file writes, though. Please refer to the report for more details about the issue reproduction steps. Fix the issue by making two changes. Firstly, move the final kdamond_call() for cancelling all existing damon_call() requests from terminating DAMON context to be done before the ctx-&gt;kdamond reset. This makes any code that sees NULL ctx-&gt;kdamond can safely assume the context may not access damon_call() requests anymore. Secondly, let damon_call() to cleanup the damon_call_control objects that were added to the already-terminated DAMON context, before returning the error.</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 99 more</p> <p>In the Linux kernel, the following vulnerability has been resolved: mm/damon/core: remove call_control in inactive contexts If damon_call() is executed against a DAMON context that is not running, the function returns error while keeping the damon_call_control object linked to the context&#39;s call_controls list. Let&#39;s suppose the object is deallocated after the damon_call(), and yet another damon_call() is executed against the same context. The function tries to add the new damon_call_control object to the call_controls list, which still has the pointer to the previous damon_call_control object, which is deallocated. As a result, use-after-free happens. This can actually be triggered using the DAMON sysfs interface. It is not easily exploitable since it requires the sysfs write permission and making a definitely weird file writes, though. Please refer to the report for more details about the issue reproduction steps. Fix the issue by making two changes. Firstly, move the final kdamond_call() for cancelling all existing damon_call() requests from terminating DAMON context to be done before the ctx-&gt;kdamond reset. This makes any code that sees NULL ctx-&gt;kdamond can safely assume the context may not access damon_call() requests anymore. Secondly, let damon_call() to cleanup the damon_call_control objects that were added to the already-terminated DAMON context, before returning the error.</p> https://cve.radiocsirt.org/vuln/ubuntu-cve-2026-23012 https://cve.radiocsirt.org/vuln/wid-sec-w-2026-0215 <p>Ein Angreifer kann mehrere Schwachstellen im Linux Kernel ausnutzen, um nicht näher spezifizierte Angriffe durchzuführen, die möglicherweise zu einer Denial-of-Service- Bedingung führen oder eine Speicherbeschädigung verursachen können.</p> <p>Ein Angreifer kann mehrere Schwachstellen im Linux Kernel ausnutzen, um nicht näher spezifizierte Angriffe durchzuführen, die möglicherweise zu einer Denial-of-Service- Bedingung führen oder eine Speicherbeschädigung verursachen können.</p> https://cve.radiocsirt.org/vuln/wid-sec-w-2026-0215