https://cve.radiocsirt.org/rss/recent/all/10 Most recent entries from all 2026-10-04T12:48:38.464253+00:00 Vulnerability-Lookup csirt@opendfir.org python-feedgen Contains only the most 10 recent entries. https://cve.radiocsirt.org/vuln/bdu:2024-08687 bdu:2024-08687 2026-10-04T12:48:38.471598+00:00 bdu:2024-08687 https://cve.radiocsirt.org/vuln/bell-cve-2024-42233 BELL-CVE-2024-42233 2026-10-04T12:48:38.471644+00:00

Affected: Alpaquita:25: linux-lts, Alpaquita:stream: linux-lts

 https://cve.radiocsirt.org/vuln/euvd-2026-345979 EUVD-2026-345979 2026-10-04T12:48:38.471683+00:00 EUVD-2026-345979 https://cve.radiocsirt.org/vuln/fkie_cve-2024-42233 fkie_cve-2024-42233 2026-10-04T12:48:38.471702+00:00

In the Linux kernel, the following vulnerability has been resolved:

filemap: replace pte_offset_map() with pte_offset_map_nolock()

The vmf->ptl in filemap_fault_recheck_pte_none() is still set from handle_pte_fault(). But at the same time, we did a pte_unmap(vmf->pte). After a pte_unmap(vmf->pte) unmap and rcu_read_unlock(), the page table may be racily changed and vmf->ptl maybe fails to protect the actual page table. Fix this by replacing pte_offset_map() with pte_offset_map_nolock().

As David said, the PTL pointer might be stale so if we continue to use it infilemap_fault_recheck_pte_none(), it might trigger UAF. Also, if the PTL fails, the issue fixed by commit 58f327f2ce80 ("filemap: avoid unnecessary major faults in filemap_fault()") might reappear.

 https://cve.radiocsirt.org/vuln/ghsa-2rr5-68hg-rwmh GHSA-2rr5-68hg-rwmh 2026-10-04T12:48:38.471746+00:00

In the Linux kernel, the following vulnerability has been resolved:

filemap: replace pte_offset_map() with pte_offset_map_nolock()

The vmf->ptl in filemap_fault_recheck_pte_none() is still set from handle_pte_fault(). But at the same time, we did a pte_unmap(vmf->pte). After a pte_unmap(vmf->pte) unmap and rcu_read_unlock(), the page table may be racily changed and vmf->ptl maybe fails to protect the actual page table. Fix this by replacing pte_offset_map() with pte_offset_map_nolock().

As David said, the PTL pointer might be stale so if we continue to use it infilemap_fault_recheck_pte_none(), it might trigger UAF. Also, if the PTL fails, the issue fixed by commit 58f327f2ce80 ("filemap: avoid unnecessary major faults in filemap_fault()") might reappear.

 https://cve.radiocsirt.org/vuln/ubuntu-cve-2024-42233 UBUNTU-CVE-2024-42233 2026-10-04T12:48:38.471776+00:00

Affected: 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 66 more

In the Linux kernel, the following vulnerability has been resolved: filemap: replace pte_offset_map() with pte_offset_map_nolock() The vmf->ptl in filemap_fault_recheck_pte_none() is still set from handle_pte_fault(). But at the same time, we did a pte_unmap(vmf->pte). After a pte_unmap(vmf->pte) unmap and rcu_read_unlock(), the page table may be racily changed and vmf->ptl maybe fails to protect the actual page table. Fix this by replacing pte_offset_map() with pte_offset_map_nolock(). As David said, the PTL pointer might be stale so if we continue to use it infilemap_fault_recheck_pte_none(), it might trigger UAF. Also, if the PTL fails, the issue fixed by commit 58f327f2ce80 ("filemap: avoid unnecessary major faults in filemap_fault()") might reappear.

 https://cve.radiocsirt.org/vuln/wid-sec-w-2024-1788 WID-SEC-W-2024-1788 — Linux Kernel: Mehrere Schwachstellen ermöglichen nicht spezifizierten Angriff 2026-10-04T12:48:38.471906+00:00

Ein lokaler Angreifer kann mehrere Schwachstellen im Linux Kernel ausnutzen, um einen nicht näher spezifizierten Angriff durchzuführen.