Vulnerabilities

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.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> pstore: inode: Only d_invalidate() is needed<br /> <br /> Unloading a modular pstore backend with records in pstorefs would<br /> trigger the dput() double-drop warning:<br /> <br /> WARNING: CPU: 0 PID: 2569 at fs/dcache.c:762 dput.part.0+0x3f3/0x410<br /> <br /> Using the combo of d_drop()/dput() (as mentioned in<br /> Documentation/filesystems/vfs.rst) isn&amp;#39;t the right approach here, and<br /> leads to the reference counting problem seen above. Use d_invalidate()<br /> and update the code to not bother checking for error codes that can<br /> never happen.<br /> <br /> ---

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ipv6: mcast: remove one synchronize_net() barrier in ipv6_mc_down()<br /> <br /> As discussed in the past (commit 2d3916f31891 ("ipv6: fix skb drops<br /> in igmp6_event_query() and igmp6_event_report()")) I think the<br /> synchronize_net() call in ipv6_mc_down() is not needed.<br /> <br /> Under load, synchronize_net() can last between 200 usec and 5 ms.<br /> <br /> KASAN seems to agree as well.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> wifi: wilc1000: do not realloc workqueue everytime an interface is added<br /> <br /> Commit 09ed8bfc5215 ("wilc1000: Rename workqueue from "WILC_wq" to<br /> "NETDEV-wq"") moved workqueue creation in wilc_netdev_ifc_init in order to<br /> set the interface name in the workqueue name. However, while the driver<br /> needs only one workqueue, the wilc_netdev_ifc_init is called each time we<br /> add an interface over a phy, which in turns overwrite the workqueue with a<br /> new one. This can be observed with the following commands:<br /> <br /> for i in $(seq 0 10)<br /> do<br /> iw phy phy0 interface add wlan1 type managed<br /> iw dev wlan1 del<br /> done<br /> ps -eo pid,comm|grep wlan<br /> <br /> 39 kworker/R-wlan0<br /> 98 kworker/R-wlan1<br /> 102 kworker/R-wlan1<br /> 105 kworker/R-wlan1<br /> 108 kworker/R-wlan1<br /> 111 kworker/R-wlan1<br /> 114 kworker/R-wlan1<br /> 117 kworker/R-wlan1<br /> 120 kworker/R-wlan1<br /> 123 kworker/R-wlan1<br /> 126 kworker/R-wlan1<br /> 129 kworker/R-wlan1<br /> <br /> Fix this leakage by putting back hif_workqueue allocation in<br /> wilc_cfg80211_init. Regarding the workqueue name, it is indeed relevant to<br /> set it lowercase, however it is not attached to a specific netdev, so<br /> enforcing netdev name in the name is not so relevant. Still, enrich the<br /> name with the wiphy name to make it clear which phy is using the workqueue.