Vulnerabilities

Out of bounds read in V8 API in Google Chrome prior to 124.0.6367.78 allowed a remote attacker to leak cross-site data via a crafted HTML page. (Chromium security severity: High)

Use after free in Dawn in Google Chrome prior to 124.0.6367.78 allowed a remote attacker to potentially exploit heap corruption via a crafted HTML page. (Chromium security severity: High)

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> f2fs: fix to avoid use-after-free issue in f2fs_filemap_fault<br /> <br /> syzbot reports a f2fs bug as below:<br /> <br /> BUG: KASAN: slab-use-after-free in f2fs_filemap_fault+0xd1/0x2c0 fs/f2fs/file.c:49<br /> Read of size 8 at addr ffff88807bb22680 by task syz-executor184/5058<br /> <br /> CPU: 0 PID: 5058 Comm: syz-executor184 Not tainted 6.7.0-syzkaller-09928-g052d534373b7 #0<br /> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 11/17/2023<br /> Call Trace:<br /> <br /> __dump_stack lib/dump_stack.c:88 [inline]<br /> dump_stack_lvl+0x1e7/0x2d0 lib/dump_stack.c:106<br /> print_address_description mm/kasan/report.c:377 [inline]<br /> print_report+0x163/0x540 mm/kasan/report.c:488<br /> kasan_report+0x142/0x170 mm/kasan/report.c:601<br /> f2fs_filemap_fault+0xd1/0x2c0 fs/f2fs/file.c:49<br /> __do_fault+0x131/0x450 mm/memory.c:4376<br /> do_shared_fault mm/memory.c:4798 [inline]<br /> do_fault mm/memory.c:4872 [inline]<br /> do_pte_missing mm/memory.c:3745 [inline]<br /> handle_pte_fault mm/memory.c:5144 [inline]<br /> __handle_mm_fault+0x23b7/0x72b0 mm/memory.c:5285<br /> handle_mm_fault+0x27e/0x770 mm/memory.c:5450<br /> do_user_addr_fault arch/x86/mm/fault.c:1364 [inline]<br /> handle_page_fault arch/x86/mm/fault.c:1507 [inline]<br /> exc_page_fault+0x456/0x870 arch/x86/mm/fault.c:1563<br /> asm_exc_page_fault+0x26/0x30 arch/x86/include/asm/idtentry.h:570<br /> <br /> The root cause is: in f2fs_filemap_fault(), vmf-&gt;vma may be not alive after<br /> filemap_fault(), so it may cause use-after-free issue when accessing<br /> vmf-&gt;vma-&gt;vm_flags in trace_f2fs_filemap_fault(). So it needs to keep vm_flags<br /> in separated temporary variable for tracepoint use.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> backlight: hx8357: Fix potential NULL pointer dereference<br /> <br /> The "im" pins are optional. Add missing check in the hx8357_probe().

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> media: ttpci: fix two memleaks in budget_av_attach<br /> <br /> When saa7146_register_device and saa7146_vv_init fails, budget_av_attach<br /> should free the resources it allocates, like the error-handling of<br /> ttpci_budget_init does. Besides, there are two fixme comment refers to<br /> such deallocations.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> media: go7007: fix a memleak in go7007_load_encoder<br /> <br /> In go7007_load_encoder, bounce(i.e. go-&gt;boot_fw), is allocated without<br /> a deallocation thereafter. After the following call chain:<br /> <br /> saa7134_go7007_init<br /> |-&gt; go7007_boot_encoder<br /> |-&gt; go7007_load_encoder<br /> |-&gt; kfree(go)<br /> <br /> go is freed and thus bounce is leaked.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> media: imx: csc/scaler: fix v4l2_ctrl_handler memory leak<br /> <br /> Free the memory allocated in v4l2_ctrl_handler_init on release.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> media: v4l2-mem2mem: fix a memleak in v4l2_m2m_register_entity<br /> <br /> The entity-&gt;name (i.e. name) is allocated in v4l2_m2m_register_entity<br /> but isn&amp;#39;t freed in its following error-handling paths. This patch<br /> adds such deallocation to prevent memleak of entity-&gt;name.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> media: v4l2-tpg: fix some memleaks in tpg_alloc<br /> <br /> In tpg_alloc, resources should be deallocated in each and every<br /> error-handling paths, since they are allocated in for statements.<br /> Otherwise there would be memleaks because tpg_free is called only when<br /> tpg_alloc return 0.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> iommu/vt-d: Fix NULL domain on device release<br /> <br /> In the kdump kernel, the IOMMU operates in deferred_attach mode. In this<br /> mode, info-&gt;domain may not yet be assigned by the time the release_device<br /> function is called. It leads to the following crash in the crash kernel:<br /> <br /> BUG: kernel NULL pointer dereference, address: 000000000000003c<br /> ...<br /> RIP: 0010:do_raw_spin_lock+0xa/0xa0<br /> ...<br /> _raw_spin_lock_irqsave+0x1b/0x30<br /> intel_iommu_release_device+0x96/0x170<br /> iommu_deinit_device+0x39/0xf0<br /> __iommu_group_remove_device+0xa0/0xd0<br /> iommu_bus_notifier+0x55/0xb0<br /> notifier_call_chain+0x5a/0xd0<br /> blocking_notifier_call_chain+0x41/0x60<br /> bus_notify+0x34/0x50<br /> device_del+0x269/0x3d0<br /> pci_remove_bus_device+0x77/0x100<br /> p2sb_bar+0xae/0x1d0<br /> ...<br /> i801_probe+0x423/0x740<br /> <br /> Use the release_domain mechanism to fix it. The scalable mode context<br /> entry which is not part of release domain should be cleared in<br /> release_device().

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> btrfs: fix race when detecting delalloc ranges during fiemap<br /> <br /> For fiemap we recently stopped locking the target extent range for the<br /> whole duration of the fiemap call, in order to avoid a deadlock in a<br /> scenario where the fiemap buffer happens to be a memory mapped range of<br /> the same file. This use case is very unlikely to be useful in practice but<br /> it may be triggered by fuzz testing (syzbot, etc).<br /> <br /> This however introduced a race that makes us miss delalloc ranges for<br /> file regions that are currently holes, so the caller of fiemap will not<br /> be aware that there&amp;#39;s data for some file regions. This can be quite<br /> serious for some use cases - for example in coreutils versions before 9.0,<br /> the cp program used fiemap to detect holes and data in the source file,<br /> copying only regions with data (extents or delalloc) from the source file<br /> to the destination file in order to preserve holes (see the documentation<br /> for its --sparse command line option). This means that if cp was used<br /> with a source file that had delalloc in a hole, the destination file could<br /> end up without that data, which is effectively a data loss issue, if it<br /> happened to hit the race described below.<br /> <br /> The race happens like this:<br /> <br /> 1) Fiemap is called, without the FIEMAP_FLAG_SYNC flag, for a file that<br /> has delalloc in the file range [64M, 65M[, which is currently a hole;<br /> <br /> 2) Fiemap locks the inode in shared mode, then starts iterating the<br /> inode&amp;#39;s subvolume tree searching for file extent items, without having<br /> the whole fiemap target range locked in the inode&amp;#39;s io tree - the<br /> change introduced recently by commit b0ad381fa769 ("btrfs: fix<br /> deadlock with fiemap and extent locking"). It only locks ranges in<br /> the io tree when it finds a hole or prealloc extent since that<br /> commit;<br /> <br /> 3) Note that fiemap clones each leaf before using it, and this is to<br /> avoid deadlocks when locking a file range in the inode&amp;#39;s io tree and<br /> the fiemap buffer is memory mapped to some file, because writing<br /> to the page with btrfs_page_mkwrite() will wait on any ordered extent<br /> for the page&amp;#39;s range and the ordered extent needs to lock the range<br /> and may need to modify the same leaf, therefore leading to a deadlock<br /> on the leaf;<br /> <br /> 4) While iterating the file extent items in the cloned leaf before<br /> finding the hole in the range [64M, 65M[, the delalloc in that range<br /> is flushed and its ordered extent completes - meaning the corresponding<br /> file extent item is in the inode&amp;#39;s subvolume tree, but not present in<br /> the cloned leaf that fiemap is iterating over;<br /> <br /> 5) When fiemap finds the hole in the [64M, 65M[ range by seeing the gap in<br /> the cloned leaf (or a file extent item with disk_bytenr == 0 in case<br /> the NO_HOLES feature is not enabled), it will lock that file range in<br /> the inode&amp;#39;s io tree and then search for delalloc by checking for the<br /> EXTENT_DELALLOC bit in the io tree for that range and ordered extents<br /> (with btrfs_find_delalloc_in_range()). But it finds nothing since the<br /> delalloc in that range was already flushed and the ordered extent<br /> completed and is gone - as a result fiemap will not report that there&amp;#39;s<br /> delalloc or an extent for the range [64M, 65M[, so user space will be<br /> mislead into thinking that there&amp;#39;s a hole in that range.<br /> <br /> This could actually be sporadically triggered with test case generic/094<br /> from fstests, which reports a missing extent/delalloc range like this:<br /> <br /> generic/094 2s ... - output mismatch (see /home/fdmanana/git/hub/xfstests/results//generic/094.out.bad)<br /> --- tests/generic/094.out 2020-06-10 19:29:03.830519425 +0100<br /> +++ /home/fdmanana/git/hub/xfstests/results//generic/094.out.bad 2024-02-28 11:00:00.381071525 +0000<br /> @@ -1,3 +1,9 @@<br /> QA output created by 094<br /> fiemap run with sync<br /> fiemap run without sync<br /> +ERROR: couldn&amp;#39;t find extent at 7<br /> +map is &amp;#39;HHDDHPPDPHPH&amp;#39;<br /> +logical: [ 5.. 6] phys:<br /> ---truncated---

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> SUNRPC: fix some memleaks in gssx_dec_option_array<br /> <br /> The creds and oa-&gt;data need to be freed in the error-handling paths after<br /> their allocation. So this patch add these deallocations in the<br /> corresponding paths.