CVE Watch4 ago 2026

CVE-2024-47674

In the Linux kernel, the following vulnerability has been resolved: mm: avoid leaving partial pfn mappings around in error case As Jann po

CVSS

7.8

Alto

EPSS

0.2%

p16

KEV

—

Exploit Today

0-100

Publicado: 15 oct 2024 · Última mod.: 4 ago 2026 · CWE-459

EPSS · 30d

0.2%EPSS · 30 días0.2%

2026-07-312026-08-27

Descripción técnica

In the Linux kernel, the following vulnerability has been resolved: mm: avoid leaving partial pfn mappings around in error case As Jann points out, PFN mappings are special, because unlike normal memory mappings, there is no lifetime information associated with the mapping - it is just a raw mapping of PFNs with no reference counting of a 'struct page'. That's all very much intentional, but it does mean that it's easy to mess up the cleanup in case of errors. Yes, a failed mmap() will always eventually clean up any partial mappings, but without any explicit lifetime in the page table mapping itself, it's very easy to do the error handling in the wrong order. In particular, it's easy to mistakenly free the physical backing store before the page tables are actually cleaned up and (temporarily) have stale dangling PTE entries. To make this situation less error-prone, just make sure that any partial pfn mapping is torn down early, before any other error handling.

Referencias oficiales

CVEs relacionados

CVECVSSEPSSKEVRExplotTítuloVis.

CVE-2026-822373.1 BAJ

—

———filebrowser through 2.63.23 does not remove share records when a shared file is renamed (only deletion triggers share cleanup). The share record is keyed by path, so it survives the rename and remains dormant (returning 404 while the path is empty). When any new, unrelated file later appears at the original shared path — via re-upload, another user with create permission, or a hook — the stale public share link serves that new file under the original link's password and expiry settings, unexpectedly exposing it.19h CVE-2026-822363.1 BAJ

—

———File Browser versions from 2.63.6 through 2.63.23 fail to clean up public share links when a privileged user deletes another user's shared file. Attackers can access the surviving share link to retrieve new unrelated content uploaded to the same path without authentication.19h CVE-2026-792655.3 MED

18.8%

——6Incomplete cleanup in GetUserMedia in Google Chrome prior to 152.0.7977.65 allowed a remote attacker who had compromised the renderer process and leveraged social engineering to obtain sensitive information via a crafted HTML page. (Chromium security severity: Medium)3d CVE-2026-789476.5 MED

14.5%

——4Incomplete cleanup in Chromium in Google Chrome prior to 152.0.7977.65 allowed a remote attacker leveraging social engineering to bypass web origin policy via a crafted Chrome extension. (Chromium security severity: Low)18h CVE-2026-789033.1 BAJ

19.9%

——6Incomplete cleanup in SiteIsolation in Google Chrome prior to 152.0.7977.65 allowed a remote attacker who had compromised the renderer process to bypass site isolation via a crafted HTML page. (Chromium security severity: Medium)19h CVE-2026-727146.3 MED

2.1%

——1Rocq Prover does not restore the universe graph's copy of the universe checking flag when a module that locally disabled the check is closed. Local Unset Universe Checking inside a module is expected to last only until the module ends, and the global flag is restored, but the universe graph keeps its own copy which is left disabled. The two views then disagree: Test Universe Checking reports the check as enabled while the kernel continues to accept universe-inconsistent terms. With the constraint between two universes no longer enforced, Hurkens' paradox applies and yields a proof of False, from which any proposition follows. The proof uses no axioms, plugins or unsafe features once the module has closed, and Print Assumptions reports it as closed under the global context, so neither the assumption audit nor the flag query reflects the actual kernel state. No fix is available.4d