| CVE |
Vendors |
Products |
Updated |
CVSS v3.1 |
| In the Linux kernel, the following vulnerability has been resolved:
keys: Protect the type name while describing a key
keyctl_describe_key() must keep the key type's name alive until
kasprintf() has consumed it. The retained key reference keeps the key
and its description alive, but does not pin the module providing its
type. The name is passed to kasprintf() without holding key->sem.
kvasprintf() uses the saved name pointer in two formatting passes, with
a GFP_KERNEL allocation between them. With AF_RXRPC=m, a task that
passes View permission before type retirement can overlap a privileged
module unload in this order:
1. KEYCTL_DESCRIBE looks up the key, saves key->type->name in the
kasprintf() arguments and completes the first formatting pass.
2. While the formatter is delayed before its second pass,
af_rxrpc_exit() calls unregister_key_type(), which removes the type
from the registry and waits for key_gc_keytype().
3. The collector takes key->sem for writing, retypes the retained key
to key_type_dead and completes retirement. Unregistration and module
exit return, allowing free_module() to release the type and name.
4. The formatter resumes its second pass and reads the saved name from
released module storage, which can fault in string().
Hold key->sem for reading across kasprintf(). The collector then cannot
retype the key or complete retirement until both formatting passes have
finished. If retirement wins the lock first, formatting uses the core
key_type_dead name instead. Release the semaphore immediately after
kasprintf(), including on allocation failure, before copying to
userspace.
Oops report as below:
BUG: unable to handle page fault for address: fffffbfff8054794
#PF: supervisor read access in kernel mode
#PF: error_code(0x0000) - not-present page
RIP: 0010:string+0x23f/0x470
Call Trace:
vsnprintf+0x330/0x1110 |
| Wasmtime 47.0.0 before 48.0.4 and 49.0.0 before 49.0.2 contains a missing GC rooting vulnerability that leaves references live across try_call unrooted when compiling Wasm modules. Attackers can supply Wasm modules whose callee triggers garbage collection, leaving stale or dangling references that cause GC heap corruption or incorrect execution. |
| In the Linux kernel, the following vulnerability has been resolved:
coredump: hold RCU while releasing parked threads
coredump_finish() releases the parked threads by clearing ->task in
their core_thread entry and calling wake_up_process() on each of them.
It does that without holding a reference on the task and without being
inside rcu.
But calling wake_up_process(task) without rcu here isn't safe. A parked
thread doesn't need that wakeup to leave. A spurious wakeup or a
preemption after the store is enough for the task to go away.
So if the coredump client is preempted between the store and
wake_up_process() the thread can exit and be freed in the meantime and
try_to_wake_up() takes pi_lock in freed memory.
Hold rcu across the loop. |
| In the Linux kernel, the following vulnerability has been resolved:
ftrace: Initialize modname and offset in print_rec()
print_rec() leaves 'modname' and 'offset' uninitialized and
kallsyms_lookup() only sets them on success. When the lookup fails like
when a module is being loaded or unloaded, 'modname' holds a garbage
value, passes the 'if (modname)' check, and is dereferenced by
seq_printf().
Oops: general protection fault
RIP: 0010:string+0x48/0xe0
Call Trace:
vsnprintf+0x1f5/0x650
seq_printf+0x8e/0xb0
print_rec+0x6c/0xc0
t_show+0x4c/0x440
seq_read_iter+0x119/0x480
This can be triggered by reading available_filter_functions while a
module is being loaded or unloaded.
Initialize both variables so a failed lookup skips the module name. |
| In the Linux kernel, the following vulnerability has been resolved:
keys: Avoid the owner account dereference in named keyring lookup
Named keyring lookup must keep the storage containing the owner UID
alive through the namespace mapping check. find_keyring_by_name()
reads keyring->user->uid under keyring_name_lock, but that lock protects
the keyring's name entry and allocation, not its separate key_user.
A named session-keyring join can overlap a privileged KEYCTL_CHOWN on
another CPU. If the keyring holds the last reference to its old dynamic
key_user and the ownership transfer succeeds, the following ordering is
possible:
Named join Chown
find_keyring_by_name() keyctl_chown_key()
read_lock(keyring_name_lock) down_write(key->sem)
load old keyring->user
replace key->user and key->uid
up_write(key->sem)
key_put(key)
key_user_put(old user): free
read old user->uid
read_unlock(keyring_name_lock)
Chown neither takes keyring_name_lock nor key_session_mutex, so it can
free the old account between the pointer load and the UID read. The
lookup then reads freed memory even though the keyring itself is alive.
Use keyring->uid for the mapping check. key_alloc() initializes this
inline owner UID and keyctl_chown_key() updates it on chown.
The existing name lock keeps its containing keyring allocated throughout
the check, so lookup no longer depends on the account's lifetime. This
also matches the owner UID used by the permission check.
KASAN report as below:
BUG: KASAN: slab-use-after-free in find_keyring_by_name+0x577/0x5d0
Read of size 4 at addr ffff8881128ae2ec by task keycase/500 |
| Missing authorization in Accessibility in Google Chrome prior to 156.0.8078.47 allowed a remote attacker who had compromised the renderer process to potentially execute arbitrary code outside the sandbox via a crafted HTML page. (Chromium security severity: Medium) |
| The flash_copy() system call is verified by z_vrfy_flash_copy() in drivers/flash/flash_util.c. On builds with CONFIG_USERSPACE enabled, this handler is the kernel-side trust boundary for a user-mode caller. Prior to the fix it validated only the output buffer (K_SYSCALL_MEMORY_WRITE) and passed the two struct device * arguments, src_dev and dst_dev, directly into the implementation without any object validation — unlike every sibling flash syscall, which guards its device pointer with K_SYSCALL_DRIVER_FLASH.
A user-mode thread fully controls the values of src_dev/dst_dev and the contents of its own address space. The implementation z_impl_flash_copy() dereferences these pointers and calls through their driver-API function tables (e.g. api->get_parameters(dst_dev), flash_read(src_dev, ...), flash_write(dst_dev, ...)). By supplying a pointer to a forged struct device whose api table contains attacker-chosen function pointers, an unprivileged thread can cause the kernel to call arbitrary code in supervisor mode; passing any arbitrary or invalid address otherwise yields a kernel crash or out-of-bounds read.
The result is a local privilege escalation out of the userspace sandbox (with kernel denial-of-service and information disclosure as lesser outcomes). The fix adds K_SYSCALL_DRIVER_FLASH(src_dev, read) and K_SYSCALL_DRIVER_FLASH(dst_dev, write) to z_vrfy_flash_copy(), which verify each device is a registered flash-driver kernel object the calling thread is permitted to use before any dereference, closing the path completely. |
| SQLite before 3.54.0 built with FTS3/FTS4 and SQLITE_ENABLE_FTS3_PARENTHESIS contains a use-after-free vulnerability in fts3BestSnippet() caused by dangling cached position-list pointers. Attackers can run a full-text MATCH query combining OR and NEAR operators with snippet() to read freed heap memory and crash the process. |
| Monkeytype is a minimalistic and customizable typing test. Prior to 26.43.0, the .github/workflows/fix-formatting.yml workflow runs on pull_request_target with repository write permissions, checks out a fork pull request, installs dependencies from the fork's package.json, and invokes the fork-controlled oxfmt binary. Because actions/checkout persists the elevated GITHUB_TOKEN in Git configuration until after untrusted code executes, an external contributor whose pull request receives the format label can run arbitrary code, read or exfiltrate the token, and push repository content or modify pull requests and issues. The issue affects the repository CI workflow, not the Monkeytype application or user data. This issue is fixed in version 26.43.0. |
| Windows Cloud Files Mini Filter Driver Elevation of Privilege Vulnerability |
| Microsoft Streaming Service Elevation of Privilege Vulnerability |
| Use after free in Canvas in Google Chrome on Linux, ChromeOS prior to 147.0.7727.138 allowed a remote attacker to execute arbitrary code inside a sandbox via a crafted HTML page. (Chromium security severity: Critical) |
| Heap-based buffer overflow in Windows Kernel allows an authorized attacker to elevate privileges locally. |
| Incorrect authorization in FileSystem in Google Chrome prior to 156.0.8078.79 allowed a remote attacker leveraging social engineering to execute arbitrary code outside the sandbox via a crafted HTML page. (Chromium security severity: High) |
| Uninitialized resource in Skia in Google Chrome prior to 156.0.8078.79 allowed a remote attacker who had compromised the renderer process to read memory outside the sandbox via a crafted HTML page. (Chromium security severity: High) |
| Incorrect authorization in Blink in Google Chrome prior to 156.0.8078.79 allowed a remote attacker to bypass web origin policy via a crafted HTML page. (Chromium security severity: High) |
| Improper state validation in Performance in Google Chrome prior to 156.0.8078.47 allowed a local attacker to read memory via a local program. (Chromium security severity: Medium) |
| Uninitialized resource in GPU in Google Chrome prior to 156.0.8078.47 allowed a remote attacker who had compromised the renderer process to read memory outside the sandbox via a crafted HTML page. (Chromium security severity: High) |
| UI misrepresentation in Chrome for iOS in Google Chrome on on iOS prior to 156.0.8078.47 allowed a remote attacker to spoof UI elements via a crafted HTML page. (Chromium security severity: Low) |
| Missing authorization in Extensions in Google Chrome prior to 156.0.8078.47 allowed a remote attacker to obtain cross-origin data via a crafted Chrome extension. (Chromium security severity: Medium) |
