https://cve.radiocsirt.org Contains only the most 10 recent entries. http://www.rssboard.org/rss-specification python-feedgen en Sat, 03 Oct 2026 12:20:48 +0000 https://cve.radiocsirt.org/vuln/bell-cve-2025-68359 <p><strong>Affected:</strong> Alpaquita:25: linux-lts, Alpaquita:stream: linux-lts</p> <p><strong>Affected:</strong> Alpaquita:25: linux-lts, Alpaquita:stream: linux-lts</p> https://cve.radiocsirt.org/vuln/bell-cve-2025-68359 https://cve.radiocsirt.org/vuln/certfr-2026-avi-0247 certfr-2026-avi-0247 https://cve.radiocsirt.org/vuln/certfr-2026-avi-0247 https://cve.radiocsirt.org/vuln/euvd-2026-347495 EUVD-2026-347495 https://cve.radiocsirt.org/vuln/euvd-2026-347495 https://cve.radiocsirt.org/vuln/fkie_cve-2025-68359 <p>In the Linux kernel, the following vulnerability has been resolved:</p> <p>btrfs: fix double free of qgroup record after failure to add delayed ref head</p> <p>In the previous code it was possible to incur into a double kfree() scenario when calling add_delayed_ref_head(). This could happen if the record was reported to already exist in the btrfs_qgroup_trace_extent_nolock() call, but then there was an error later on add_delayed_ref_head(). In this case, since add_delayed_ref_head() returned an error, the caller went to free the record. Since add_delayed_ref_head() couldn&#39;t set this kfree&#39;d pointer to NULL, then kfree() would have acted on a non-NULL &#39;record&#39; object which was pointing to memory already freed by the callee.</p> <p>The problem comes from the fact that the responsibility to kfree the object is on both the caller and the callee at the same time. Hence, the fix for this is to shift the ownership of the &#39;qrecord&#39; object out of the add_delayed_ref_head(). That is, we will never attempt to kfree() the given object inside of this function, and will expect the caller to act on the &#39;qrecord&#39; object on its own. The only exception where the &#39;qrecord&#39; object cannot be kfree&#39;d is if it was inserted into the tracing logic, for which we already have the &#39;qrecord_inserted_ret&#39; boolean to account for this. Hence, the caller has to kfree the object only if add_delayed_ref_head() reports not to have inserted it on the tracing logic.</p> <p>As a side-effect of the above, we must guarantee that &#39;qrecord_…</p> <p>In the Linux kernel, the following vulnerability has been resolved:</p> <p>btrfs: fix double free of qgroup record after failure to add delayed ref head</p> <p>In the previous code it was possible to incur into a double kfree() scenario when calling add_delayed_ref_head(). This could happen if the record was reported to already exist in the btrfs_qgroup_trace_extent_nolock() call, but then there was an error later on add_delayed_ref_head(). In this case, since add_delayed_ref_head() returned an error, the caller went to free the record. Since add_delayed_ref_head() couldn&#39;t set this kfree&#39;d pointer to NULL, then kfree() would have acted on a non-NULL &#39;record&#39; object which was pointing to memory already freed by the callee.</p> <p>The problem comes from the fact that the responsibility to kfree the object is on both the caller and the callee at the same time. Hence, the fix for this is to shift the ownership of the &#39;qrecord&#39; object out of the add_delayed_ref_head(). That is, we will never attempt to kfree() the given object inside of this function, and will expect the caller to act on the &#39;qrecord&#39; object on its own. The only exception where the &#39;qrecord&#39; object cannot be kfree&#39;d is if it was inserted into the tracing logic, for which we already have the &#39;qrecord_inserted_ret&#39; boolean to account for this. Hence, the caller has to kfree the object only if add_delayed_ref_head() reports not to have inserted it on the tracing logic.</p> <p>As a side-effect of the above, we must guarantee that &#39;qrecord_…</p> https://cve.radiocsirt.org/vuln/fkie_cve-2025-68359 https://cve.radiocsirt.org/vuln/ghsa-wmvq-g95c-rpvj <p>In the Linux kernel, the following vulnerability has been resolved:</p> <p>btrfs: fix double free of qgroup record after failure to add delayed ref head</p> <p>In the previous code it was possible to incur into a double kfree() scenario when calling add_delayed_ref_head(). This could happen if the record was reported to already exist in the btrfs_qgroup_trace_extent_nolock() call, but then there was an error later on add_delayed_ref_head(). In this case, since add_delayed_ref_head() returned an error, the caller went to free the record. Since add_delayed_ref_head() couldn&#39;t set this kfree&#39;d pointer to NULL, then kfree() would have acted on a non-NULL &#39;record&#39; object which was pointing to memory already freed by the callee.</p> <p>The problem comes from the fact that the responsibility to kfree the object is on both the caller and the callee at the same time. Hence, the fix for this is to shift the ownership of the &#39;qrecord&#39; object out of the add_delayed_ref_head(). That is, we will never attempt to kfree() the given object inside of this function, and will expect the caller to act on the &#39;qrecord&#39; object on its own. The only exception where the &#39;qrecord&#39; object cannot be kfree&#39;d is if it was inserted into the tracing logic, for which we already have the &#39;qrecord_inserted_ret&#39; boolean to account for this. Hence, the caller has to kfree the object only if add_delayed_ref_head() reports not to have inserted it on the tracing logic.</p> <p>As a side-effect of the above, we must guarantee that &#39;qrecord_…</p> <p>In the Linux kernel, the following vulnerability has been resolved:</p> <p>btrfs: fix double free of qgroup record after failure to add delayed ref head</p> <p>In the previous code it was possible to incur into a double kfree() scenario when calling add_delayed_ref_head(). This could happen if the record was reported to already exist in the btrfs_qgroup_trace_extent_nolock() call, but then there was an error later on add_delayed_ref_head(). In this case, since add_delayed_ref_head() returned an error, the caller went to free the record. Since add_delayed_ref_head() couldn&#39;t set this kfree&#39;d pointer to NULL, then kfree() would have acted on a non-NULL &#39;record&#39; object which was pointing to memory already freed by the callee.</p> <p>The problem comes from the fact that the responsibility to kfree the object is on both the caller and the callee at the same time. Hence, the fix for this is to shift the ownership of the &#39;qrecord&#39; object out of the add_delayed_ref_head(). That is, we will never attempt to kfree() the given object inside of this function, and will expect the caller to act on the &#39;qrecord&#39; object on its own. The only exception where the &#39;qrecord&#39; object cannot be kfree&#39;d is if it was inserted into the tracing logic, for which we already have the &#39;qrecord_inserted_ret&#39; boolean to account for this. Hence, the caller has to kfree the object only if add_delayed_ref_head() reports not to have inserted it on the tracing logic.</p> <p>As a side-effect of the above, we must guarantee that &#39;qrecord_…</p> https://cve.radiocsirt.org/vuln/ghsa-wmvq-g95c-rpvj https://cve.radiocsirt.org/vuln/opensuse-su-2026:10039-1 <p>kernel-devel-6.18.5-1.1 on GA media</p> <p>kernel-devel-6.18.5-1.1 on GA media</p> https://cve.radiocsirt.org/vuln/opensuse-su-2026:10039-1 https://cve.radiocsirt.org/vuln/suse-su-2026:20555-1 <p>Security update for the Linux Kernel</p> <p>Security update for the Linux Kernel</p> https://cve.radiocsirt.org/vuln/suse-su-2026:20555-1 https://cve.radiocsirt.org/vuln/ubuntu-cve-2025-68359 <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 106 more</p> <p>In the Linux kernel, the following vulnerability has been resolved: btrfs: fix double free of qgroup record after failure to add delayed ref head In the previous code it was possible to incur into a double kfree() scenario when calling add_delayed_ref_head(). This could happen if the record was reported to already exist in the btrfs_qgroup_trace_extent_nolock() call, but then there was an error later on add_delayed_ref_head(). In this case, since add_delayed_ref_head() returned an error, the caller went to free the record. Since add_delayed_ref_head() couldn&#39;t set this kfree&#39;d pointer to NULL, then kfree() would have acted on a non-NULL &#39;record&#39; object which was pointing to memory already freed by the callee. The problem comes from the fact that the responsibility to kfree the object is on both the caller and the callee at the same time. Hence, the fix for this is to shift the ownership of the &#39;qrecord&#39; object out of the add_delayed_ref_head(). That is, we will never attempt to kfree() the given object inside of this function, and will expect the caller to act on the &#39;qrecord&#39; object on its own. The only exception where the &#39;qrecord&#39; object cannot be kfree&#39;d is if it was inserted into the tracing logic, for which we already have the &#39;qrecord_inserted_ret&#39; boolean to account for this. Hence, the caller has to kfree the object only if add_delayed_ref_head() reports not to have inserted it on the tracing logic. As a side-effect of the above, we must guarantee that &#39;qrecord_inse…</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 106 more</p> <p>In the Linux kernel, the following vulnerability has been resolved: btrfs: fix double free of qgroup record after failure to add delayed ref head In the previous code it was possible to incur into a double kfree() scenario when calling add_delayed_ref_head(). This could happen if the record was reported to already exist in the btrfs_qgroup_trace_extent_nolock() call, but then there was an error later on add_delayed_ref_head(). In this case, since add_delayed_ref_head() returned an error, the caller went to free the record. Since add_delayed_ref_head() couldn&#39;t set this kfree&#39;d pointer to NULL, then kfree() would have acted on a non-NULL &#39;record&#39; object which was pointing to memory already freed by the callee. The problem comes from the fact that the responsibility to kfree the object is on both the caller and the callee at the same time. Hence, the fix for this is to shift the ownership of the &#39;qrecord&#39; object out of the add_delayed_ref_head(). That is, we will never attempt to kfree() the given object inside of this function, and will expect the caller to act on the &#39;qrecord&#39; object on its own. The only exception where the &#39;qrecord&#39; object cannot be kfree&#39;d is if it was inserted into the tracing logic, for which we already have the &#39;qrecord_inserted_ret&#39; boolean to account for this. Hence, the caller has to kfree the object only if add_delayed_ref_head() reports not to have inserted it on the tracing logic. As a side-effect of the above, we must guarantee that &#39;qrecord_inse…</p> https://cve.radiocsirt.org/vuln/ubuntu-cve-2025-68359 https://cve.radiocsirt.org/vuln/wid-sec-w-2025-2920 <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-2025-2920