| CVE |
Vendors |
Products |
Updated |
CVSS v3.1 |
| Use after free in WebMIDI in Google Chrome on Android prior to 148.0.7778.216 allowed a remote attacker who had compromised the renderer process to potentially perform a sandbox escape via a crafted HTML page. (Chromium security severity: High) |
| Use after free in WebGL in Google Chrome on Android prior to 148.0.7778.216 allowed a remote attacker to potentially perform a sandbox escape via a crafted HTML page. (Chromium security severity: Critical) |
| Use after free in WebView in Google Chrome on Android prior to 148.0.7778.216 allowed a remote attacker who had compromised the renderer process to potentially perform a sandbox escape via a crafted HTML page. (Chromium security severity: Critical) |
| Use after free in Accessibility in Google Chrome on Windows prior to 148.0.7778.216 allowed a remote attacker who had compromised the renderer process to potentially perform a sandbox escape via a crafted HTML page. (Chromium security severity: High) |
| Uninitialized Use in ANGLE in Google Chrome prior to 148.0.7778.216 allowed a remote attacker who had compromised the renderer process to leak cross-origin data via a crafted HTML page. (Chromium security severity: High) |
| Use after free in Views in Google Chrome on Mac prior to 148.0.7778.216 allowed a remote attacker who had compromised the renderer process to potentially perform a sandbox escape via a crafted HTML page. (Chromium security severity: High) |
| Use after free in TabStrip in Google Chrome prior to 148.0.7778.216 allowed a remote attacker who convinced a user to engage in specific UI gestures to potentially exploit heap corruption via a crafted HTML page. (Chromium security severity: High) |
| Use after free in PDFium in Google Chrome prior to 148.0.7778.216 allowed a remote attacker to potentially exploit heap corruption via a crafted PDF file. (Chromium security severity: High) |
| Uninitialized Use in Gamepad in Google Chrome on Mac prior to 148.0.7778.216 allowed a remote attacker who had compromised the renderer process to potentially perform a sandbox escape via a crafted HTML page. (Chromium security severity: High) |
| Heap-based buffer overflow in Windows Kernel allows an authorized attacker to elevate privileges locally. |
| Access of resource using incompatible type ('type confusion') in Microsoft Office Word allows an unauthorized attacker to execute code locally. |
| Inappropriate implementation in Skia in Google Chrome prior to 148.0.7778.216 allowed a remote attacker to obtain potentially sensitive information from process memory via a crafted HTML page. (Chromium security severity: High) |
| Use after free in WebAppInstalls in Google Chrome on Mac prior to 148.0.7778.216 allowed a remote attacker who convinced a user to engage in specific UI gestures to potentially exploit heap corruption via a crafted HTML page. (Chromium security severity: High) |
| The vllm-metal inference backend in Docker Model Runner on macOS unconditionally sets trust_remote_code=True when loading model tokenizers, and runs without sandboxing. This causes transformers.AutoTokenizer.from_pretrained() to import and execute arbitrary Python files included in any model pulled from an OCI registry, resulting in arbitrary code execution on the Docker host as the Docker Desktop user when inference is triggered.
Any container on the Docker network can trigger this by calling the model-runner.docker.internal API to pull a malicious model and request inference. |
| The MLX inference backend in Docker Model Runner on macOS uses the MLX-LM library, which unconditionally imports and executes arbitrary Python files from model directories via the model_file configuration field in config.json. When a model's config.json specifies a model_file pointing to a Python file, MLX-LM uses importlib to load and execute it with no trust_remote_code gate or equivalent safety check. The MLX backend runs without sandboxing, resulting in arbitrary code execution on the Docker host as the Docker Desktop user.
Any container on the Docker network can trigger this by calling the model-runner.docker.internal API to pull a malicious model from an attacker-controlled OCI registry and request inference. |
| Use after free in WebCodecs in Google Chrome prior to 148.0.7778.216 allowed a remote attacker to execute arbitrary code inside a sandbox via a crafted HTML page. (Chromium security severity: High) |
| In the Linux kernel, the following vulnerability has been resolved:
batman-adv: stop caching unowned originator pointers in BAT IV
BAT IV keeps the last-hop neighbor address in each neigh_node, but some
paths also cache an originator pointer derived from a temporary lookup.
That pointer is not owned by the neigh_node and may no longer refer to a
live originator entry after purge handling runs.
Stop storing the auxiliary originator pointer in the BAT IV neighbor
state. When BAT IV needs the neighbor originator data, resolve it from
the stored neighbor address and drop the reference again after use.
[sven: avoid bonding logic for outgoing OGM] |
| In the Linux kernel, the following vulnerability has been resolved:
mptcp: fix scheduling with atomic in timestamp sockopt
Using lock_sock_fast() (atomic context) around sock_set_timestamp()
and sock_set_timestamping() is unsafe, as both helpers can sleep.
Replace lock_sock_fast() with sleepable lock_sock()/release_sock()
to avoid scheduling while atomic panic. |
| In the Linux kernel, the following vulnerability has been resolved:
usb: usblp: fix uninitialized heap leak via LPGETSTATUS ioctl
Just like in a previous problem in this driver, usblp_ctrl_msg() will
collapse the usb_control_msg() return value to 0/-errno, discarding the
actual number of bytes transferred.
Ideally that short command should be detected and error out, but many
printers are known to send "incorrect" responses back so we can't just
do that.
statusbuf is kmalloc(8) at probe time and never filled before the first
LPGETSTATUS ioctl.
usblp_read_status() requests 1 byte. If a malicious printer responds
with zero bytes, *statusbuf is one byte of stale kmalloc heap,
sign-extended into the local int status, which the LPGETSTATUS path then
copy_to_user()s directly to the ioctl caller.
Fix this all by just zapping out the memory buffer when allocated at
probe time. If a later call does a short read, the data will be
identical to what the device sent it the last time, so there is no
"leak" of information happening. |
| In the Linux kernel, the following vulnerability has been resolved:
LoongArch: Fix potential ADE in loongson_gpu_fixup_dma_hang()
The switch case in loongson_gpu_fixup_dma_hang() may not DC2 or DC3, and
readl(crtc_reg) will access with random address, because the "device" is
from "base+PCI_DEVICE_ID", "base" is from "pdev->devfn+1". This is wrong
when my platform inserts a discrete GPU:
lspci -tv
-[0000:00]-+-00.0 Loongson Technology LLC Hyper Transport Bridge Controller
...
+-06.0 Loongson Technology LLC LG100 GPU
+-06.2 Loongson Technology LLC Device 7a37
...
Add a default switch case to fix the panic as below:
Kernel ade access[#1]:
CPU: 0 PID: 1 Comm: swapper/0 Not tainted 6.6.136-loong64-desktop-hwe+ #4
pc 90000000017e5534 ra 90000000017e54c0 tp 90000001002f8000 sp 90000001002fb6c0
a0 80000efe00003100 a1 0000000000003100 a2 0000000000000000 a3 0000000000000002
a4 90000001002fb6b4 a5 900000087cdb58fd a6 90000000027af000 a7 0000000000000001
t0 00000000000085b9 t1 000000000000ffff t2 0000000000000000 t3 0000000000000000
t4 fffffffffffffffd t5 00000000fffb6d9c t6 0000000000083b00 t7 00000000000070c0
t8 900000087cdb4d94 u0 900000087cdb58fd s9 90000001002fb826 s0 90000000031c12c8
s1 7fffffffffffff00 s2 90000000031c12d0 s3 0000000000002710 s4 0000000000000000
s5 0000000000000000 s6 9000000100053000 s7 7fffffffffffff00 s8 90000000030d4000
ra: 90000000017e54c0 loongson_gpu_fixup_dma_hang+0x40/0x210
ERA: 90000000017e5534 loongson_gpu_fixup_dma_hang+0xb4/0x210
CRMD: 000000b0 (PLV0 -IE -DA +PG DACF=CC DACM=CC -WE)
PRMD: 00000004 (PPLV0 +PIE -PWE)
EUEN: 00000000 (-FPE -SXE -ASXE -BTE)
ECFG: 00071c1d (LIE=0,2-4,10-12 VS=7)
ESTAT: 00480000 [ADEM] (IS= ECode=8 EsubCode=1)
BADV: 7fffffffffffff00
PRID: 0014d000 (Loongson-64bit, Loongson-3A6000-HV)
Modules linked in:
Process swapper/0 (pid: 1, threadinfo=(____ptrval____), task=(____ptrval____))
Stack : 0000000000000006 90000001002fb778 90000001002fb704 0000000000000007
0000000016a65700 90000000017e5690 000000000000ffff ffffffffffffffff
900000000209f7c0 9000000100053000 900000000209f7a8 9000000000eebc08
0000000000000000 0000000000000000 0000000000000006 90000001002fb778
90000001000530b8 90000000027af000 0000000000000000 9000000100054000
9000000100053000 9000000000ebb70c 9000000100004c00 9000000004000001
90000001002fb7e4 bae765461f31cb12 0000000000000000 0000000000000000
0000000000000006 90000000027af000 0000000000000030 90000000027af000
900000087cd6f800 9000000100053000 0000000000000000 9000000000ebc560
7a2500147cdaf720 bae765461f31cb12 0000000000000001 0000000000000030
...
Call Trace:
[<90000000017e5534>] loongson_gpu_fixup_dma_hang+0xb4/0x210
[<9000000000eebc08>] pci_fixup_device+0x108/0x280
[<9000000000ebb70c>] pci_setup_device+0x24c/0x690
[<9000000000ebc560>] pci_scan_single_device+0xe0/0x140
[<9000000000ebc684>] pci_scan_slot+0xc4/0x280
[<9000000000ebdd00>] pci_scan_child_bus_extend+0x60/0x3f0
[<9000000000f5bc94>] acpi_pci_root_create+0x2b4/0x420
[<90000000017e5e74>] pci_acpi_scan_root+0x2d4/0x440
[<9000000000f5b02c>] acpi_pci_root_add+0x21c/0x3a0
[<9000000000f4ee54>] acpi_bus_attach+0x1a4/0x3c0
[<90000000010e200c>] device_for_each_child+0x6c/0xe0
[<9000000000f4bbf4>] acpi_dev_for_each_child+0x44/0x70
[<9000000000f4ef40>] acpi_bus_attach+0x290/0x3c0
[<90000000010e200c>] device_for_each_child+0x6c/0xe0
[<9000000000f4bbf4>] acpi_dev_for_each_child+0x44/0x70
[<9000000000f4ef40>] acpi_bus_attach+0x290/0x3c0
[<9000000000f5211c>] acpi_bus_scan+0x6c/0x280
[<900000000189c028>] acpi_scan_init+0x194/0x310
[<900000000189bc6c>] acpi_init+0xcc/0x140
[<9000000000220cdc>] do_one_initcall+0x4c/0x310
[<90000000018618fc>] kernel_init_freeable+0x258/0x2d4
[<900000000184326c>] kernel_init+0x28/0x13c
[<9000000000222008>] ret_from_kernel_thread+0xc/0xa4 |
