| CVE |
Vendors |
Products |
Updated |
CVSS v3.1 |
| Uninitialized resource in ANGLE in Google Chrome on on Windows prior to 155.0.8059.39 allowed a remote attacker to read memory outside the sandbox via a crafted HTML page. (Chromium security severity: High) |
| Uninitialized resource in Video in Google Chrome prior to 155.0.8059.39 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) |
| Use after free in Chrome Tabs in Google Chrome on on Mac prior to 155.0.8059.39 allowed a remote attacker to potentially execute arbitrary code outside the sandbox via a crafted HTML page. (Chromium security severity: High) |
| Use after free in Bindings in Google Chrome prior to 155.0.8059.39 allowed a remote attacker to execute arbitrary code inside the sandbox via a crafted HTML page. (Chromium security severity: High) |
| Use after free in WebRTC in Google Chrome prior to 155.0.8059.39 allowed a remote attacker to execute arbitrary code inside the sandbox via a crafted HTML page. (Chromium security severity: High) |
| Use after free in Media in Google Chrome prior to 155.0.8059.39 allowed a remote attacker to execute arbitrary code inside the sandbox via a crafted HTML page. (Chromium security severity: High) |
| Use after free in V8 in Google Chrome prior to 155.0.8059.39 allowed a remote attacker to execute arbitrary code inside the sandbox via a crafted HTML page. (Chromium security severity: High) |
| UI misrepresentation in File in Google Chrome prior to 155.0.8059.39 allowed a remote attacker leveraging social engineering to spoof UI elements via a crafted HTML page. (Chromium security severity: Medium) |
| Incorrect authorization in WebAppInstalls in Google Chrome on on Android prior to 155.0.8059.39 allowed a remote attacker to bypass system access restrictions via a crafted HTML page. (Chromium security severity: Medium) |
| Confused deputy in Omnibox in Google Chrome prior to 155.0.8059.39 allowed a remote attacker to bypass web origin policy via crafted network traffic. (Chromium security severity: Medium) |
| Missing authorization in Animation in Google Chrome prior to 155.0.8059.39 allowed a remote attacker to bypass web origin policy via a crafted HTML page. (Chromium security severity: Medium) |
| Missing authorization in Network in Google Chrome prior to 155.0.8059.39 allowed a remote attacker who had compromised the renderer process to bypass site isolation via a crafted HTML page. (Chromium security severity: Medium) |
| Incorrect authorization in Browser in Google Chrome on on Android prior to 155.0.8059.39 allowed a local attacker leveraging social engineering to obtain sensitive information via a co-installed app. (Chromium security severity: Medium) |
| Race condition in CacheStorage in Google Chrome prior to 155.0.8059.39 allowed a remote attacker who had compromised the renderer process to read memory outside the sandbox via a crafted HTML page. (Chromium security severity: Medium) |
| Information leak in Payments in Google Chrome prior to 155.0.8059.39 allowed a remote attacker to obtain cross-origin data via a crafted HTML page. (Chromium security severity: Medium) |
| Improper input validation in SignIn in Google Chrome prior to 155.0.8059.39 allowed a remote attacker leveraging social engineering to bypass system access restrictions via a crafted Chrome extension. (Chromium security severity: Medium) |
| In the Linux kernel, the following vulnerability has been resolved:
selinux: recheck intermediate backing files on mprotect()
mprotect() can be used to bypass the SELinux checks that mmap() performs
against the intermediate layers of a stacked filesystem.
mmap() checks every backing layer as the request descends through the
stack. mprotect() only has the lowest backing file in vma->vm_file, so it
rechecks the top-level user and the lowest mounter, but skips the mounters
of every layer in between. With two nested overlayfs mounts and a policy
denying mounter_t -> middle_file_t:file { execute }, a direct
mmap(PROT_EXEC) is denied:
avc: denied { execute } for pid=71 comm="nested_exec"
path="/payload" dev="overlay" ino=9
scontext=user_u:base_r:mounter_t
tcontext=user_u:object_r:middle_file_t tclass=file permissive=0
while mmap(PROT_NONE) followed by mprotect(PROT_EXEC) succeeds.
Preserve each intermediate path, mounter SID and file-description SID in
the backing-file security blob, copying the saved entries when another
backing layer is opened. Allocate the array only for nested backing files,
and release it and the path references in the backing_file_free hook.
During mprotect(), recheck fd { use } and the requested inode permissions
for every saved mounter, and include the intermediate layers in the execmod
checks. Policy for nested stacking may then need to grant intermediate
mounters what a direct mmap() already requires, and execmod on intermediate
labels for binaries using text relocations.
Tested on arm64 QEMU with a small BusyBox initramfs and a purpose-built
SELinux policy, on a mainline tree containing
commit f2381b546e7e ("fs: fix user path of nested backing files").
[PM: subject tweak] |
| In the Linux kernel, the following vulnerability has been resolved:
selinux: preserve user SID across nested backing files
SELinux saves the user file SID in a backing-file security blob so it
remains available after mmap() replaces vma->vm_file with a backing file.
For nested backing files (overlayfs over overlayfs, or FUSE passthrough
backed by overlayfs), user_file may itself be a backing file. Its
fsec->sid is the SID of the mounter that opened it, rather than the user
that opened the top-level file. mprotect() then checks fd { use } against
the mounter SID. This can incorrectly deny access without a domain
transition, or check the wrong target SID after one.
Copy the saved user SID when user_file is a backing file. Keep using the
regular file SID for the first backing layer.
With two nested overlayfs mounts and SELinux enforcing,
mprotect(PROT_READ) returns EACCES with an fd { use } denial against the
mounter SID. With this change, mprotect() succeeds.
Tested on arm64 QEMU with a small BusyBox initramfs and a purpose-built
SELinux policy. The original test was also repeated with Fedora Cloud
Base 44 userspace and gave the same result. |
| In the Linux kernel, the following vulnerability has been resolved:
mm/shrinker: fix bogus set_shrinker_bit() with cgroup.memory=nokmem
With cgroup.memory=nokmem, shrinker_memcg_alloc() bails out early and
never allocates an id, so shrinker->id keeps the 0 it got from the
kzalloc() in shrinker_alloc(). __list_lru_init() then copies that 0 into
lru->shrinker_id, where it looks like a valid bit index.
Nothing calls expand_shrinker_info() on nokmem either, so shrinker_nr_max
stays 0 and every memcg ends up with an empty map (map_nr_max == 0).
deferred_split_folio() hands a real memcg to __list_lru_add() regardless
of whether the lru is memcg aware, so the first THP queued in a cgroup
does set_shrinker_bit(memcg, nid, 0) and trips the bounds check:
WARNING: mm/shrinker.c:212 at set_shrinker_bit+0x7d/0x90, CPU#126
Call Trace:
<TASK>
deferred_split_folio+0x18c/0x220
map_anon_folio_pmd_nopf+0xdd/0x130
map_anon_folio_pmd_pf+0x14/0xb0
do_huge_pmd_anonymous_page+0x1a1/0x620
__handle_mm_fault+0xea9/0x10d0
handle_mm_fault+0xe5/0x320
do_user_addr_fault+0x1cc/0x870
exc_page_fault+0x81/0x1b0
asm_exc_page_fault+0x27/0x30
</TASK>
Harmless, the WARN_ON_ONCE() is what keeps the out of bounds unit[] read
from happening, but the id should not look valid in the first place.
Clear it before returning.
Two other spots could paper over this: drop the id in __list_lru_init()
when nokmem turns memcg_aware off, or make deferred_split_folio() pass
NULL like list_lru_add_obj() does. Both leave shrinker->id lying around
for the next caller, so fix it where the id is handed out. |
| Uninitialized resource in GPU in Google Chrome on on Android prior to 155.0.8059.39 allowed a remote attacker to read memory outside the sandbox via a crafted HTML page. (Chromium security severity: Medium) |
