| CVE |
Vendors |
Products |
Updated |
CVSS v3.1 |
| A flaw was found in GCC. When an application calls the erase_if function on a binary heap priority queue in libstdc++, the library reallocates storage but fails to update its internal entry pointer. An attacker capable of triggering this operation can exploit this use-after-free condition, leading to a Denial of Service (DoS) via an application crash or potential memory corruption. |
| When tarfile or zipfile command line interface (CLI) is used to
decompress an archive, a Python script shadowing the stdlib can be
created. Then if an error occurs during decompressing the next file,
the newly created Python script is executed. This is especially true
if the created Python is called traceback.py. The problem is that
Python adds the current directory to sys.path when python -m MODULE is
run, and the archive is also decompressed in the current directory.
The fix removes sys.path[0] in gzip, tarfile and zipfile command line
interface to prevent shadowing standard library modules from extracted
files. |
| Untrusted pointer dereference in Windows DirectX allows an authorized attacker to execute code locally. |
| Incorrect access of indexable resource ('range error') in Windows Sensor Data Service allows an authorized attacker to elevate privileges locally. |
| Untrusted pointer dereference in Windows Resilient File System (ReFS) allows an authorized attacker to elevate privileges locally. |
| Untrusted pointer dereference in Windows Domain Controller allows an unauthorized attacker to deny service over a network. |
| Untrusted pointer dereference in Windows USB Hub Driver allows an authorized attacker to elevate privileges locally. |
| In the Linux kernel, the following vulnerability has been resolved:
f2fs: atomic: fix UAF issue on f2fs_inode_info.atomic_inode
- ioctl(F2FS_IOC_GARBAGE_COLLECT_RANGE) - shrink
- f2fs_gc
- gc_data_segment
- ra_data_block(cow_inode)
- mapping = F2FS_I(inode)->atomic_inode->i_mapping
: f2fs_is_cow_file(cow_inode) is true
- f2fs_evict_inode(atomic_inode)
- clear_inode_flag(fi->cow_inode, FI_COW_FILE)
- F2FS_I(fi->cow_inode)->atomic_inode = NULL
...
- truncate_inode_pages_final(atomic_inode)
- f2fs_grab_cache_folio(mapping)
: create folio in atomic_inode->mapping
- clear_inode(atomic_inode)
- BUG_ON(atomic_inode->i_data.nrpages)
We need to add a reference on fi->atomic_inode before using its mapping
field during garbage collection, otherwise, it will cause UAF issue. |
| Use-after-free in the Graphics: Text component. This vulnerability was fixed in Firefox 159, Thunderbird 159, Firefox ESR 153.7, and Thunderbird 153.7. |
| Sandbox escape due to use-after-free in the XPCOM component. This vulnerability was fixed in Firefox 159, Thunderbird 159, Firefox ESR 153.7, and Thunderbird 153.7. |
| Race condition, use-after-free in the DOM: File component. This vulnerability was fixed in Firefox 159, Thunderbird 159, Firefox ESR 153.7, and Thunderbird 153.7. |
| Use-after-free in the JavaScript: GC component. This vulnerability was fixed in Firefox 159, Thunderbird 159, Firefox ESR 153.7, and Thunderbird 153.7. |
| In the Linux kernel, the following vulnerability has been resolved:
f2fs: fix incorrect FI_NO_EXTENT handling in __destroy_extent_node()
When __destroy_extent_node() sets the inode flag FI_NO_EXTENT, it does
not reset the length of the largest extent to 0 and update the inode
folio. Since modifications to the extent tree are disallowed afterward,
the cached largest extent may become stale. This can trigger the
following error in xfstests generic/388:
F2FS-fs (dm-0): sanity_check_extent_cache: inode (ino=1761) extent info [220057, 57, 6] is incorrect, run fsck to fix
In the f2fs_drop_inode path, __destroy_extent_node() does not need to
guarantee that et->node_cnt is 0, because concurrency with writeback
is expected in this path, and writeback may update the extent cache.
This patch reverts commit ed78aeebef05 ("f2fs: fix node_cnt race between
extent node destroy and writeback"), and remove the unnecessary zero
check of et->node_cnt. |
| In JetBrains IntelliJ IDEA before 2026.3 code execution was possible in untrusted projects via the Terraform File Watchers |
| In JetBrains IntelliJ IDEA before 2026.3 untrusted projects could trigger changes to GPG agent configuration |
| In JetBrains IntelliJ IDEA before 2026.3 code execution via the document import was possible in untrusted projects |
| In JetBrains IntelliJ IDEA before 2026.3,
2026.2.4 sSRF was possible via annotations.xml files during indexing |
| In JetBrains IntelliJ IDEA before 2026.3 improper checks could enable disabled plugins via external dependency settings |
| In JetBrains IntelliJ IDEA before 2026.3 database connections could be established in untrusted projects |
| In JetBrains IntelliJ IDEA before 2026.3 code execution was possible in Safe Mode via UI Designer form file |
