Vulnerabilities

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.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> nvme: host: fix double-free of struct nvme_id_ns in ns_update_nuse()<br /> <br /> When nvme_identify_ns() fails, it frees the pointer to the struct<br /> nvme_id_ns before it returns. However, ns_update_nuse() calls kfree()<br /> for the pointer even when nvme_identify_ns() fails. This results in<br /> KASAN double-free, which was observed with blktests nvme/045 with<br /> proposed patches [1] on the kernel v6.8-rc7. Fix the double-free by<br /> skipping kfree() when nvme_identify_ns() fails.

IBM WebSphere Automation 1.7.0 is vulnerable to cross-site scripting. This vulnerability allows users to embed arbitrary JavaScript code in the Web UI thus altering the intended functionality potentially leading to credentials disclosure within a trusted session. IBM X-Force ID: 285648.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> media: dvb-frontends: avoid stack overflow warnings with clang<br /> <br /> A previous patch worked around a KASAN issue in stv0367, now a similar<br /> problem showed up with clang:<br /> <br /> drivers/media/dvb-frontends/stv0367.c:1222:12: error: stack frame size (3624) exceeds limit (2048) in &amp;#39;stv0367ter_set_frontend&amp;#39; [-Werror,-Wframe-larger-than]<br /> 1214 | static int stv0367ter_set_frontend(struct dvb_frontend *fe)<br /> <br /> Rework the stv0367_writereg() function to be simpler and mark both<br /> register access functions as noinline_for_stack so the temporary<br /> i2c_msg structures do not get duplicated on the stack when KASAN_STACK<br /> is enabled.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> media: usbtv: Remove useless locks in usbtv_video_free()<br /> <br /> Remove locks calls in usbtv_video_free() because<br /> are useless and may led to a deadlock as reported here:<br /> https://syzkaller.appspot.com/x/bisect.txt?x=166dc872180000<br /> Also remove usbtv_stop() call since it will be called when<br /> unregistering the device.<br /> <br /> Before &amp;#39;c838530d230b&amp;#39; this issue would only be noticed if you<br /> disconnect while streaming and now it is noticeable even when<br /> disconnecting while not streaming.<br /> <br /> <br /> [hverkuil: fix minor spelling mistake in log message]

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> wifi: mt76: mt7925e: fix use-after-free in free_irq()<br /> <br /> From commit a304e1b82808 ("[PATCH] Debug shared irqs"), there is a test<br /> to make sure the shared irq handler should be able to handle the unexpected<br /> event after deregistration. For this case, let&amp;#39;s apply MT76_REMOVED flag to<br /> indicate the device was removed and do not run into the resource access<br /> anymore.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> libbpf: Use OPTS_SET() macro in bpf_xdp_query()<br /> <br /> When the feature_flags and xdp_zc_max_segs fields were added to the libbpf<br /> bpf_xdp_query_opts, the code writing them did not use the OPTS_SET() macro.<br /> This causes libbpf to write to those fields unconditionally, which means<br /> that programs compiled against an older version of libbpf (with a smaller<br /> size of the bpf_xdp_query_opts struct) will have its stack corrupted by<br /> libbpf writing out of bounds.<br /> <br /> The patch adding the feature_flags field has an early bail out if the<br /> feature_flags field is not part of the opts struct (via the OPTS_HAS)<br /> macro, but the patch adding xdp_zc_max_segs does not. For consistency, this<br /> fix just changes the assignments to both fields to use the OPTS_SET()<br /> macro.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> cpufreq: brcmstb-avs-cpufreq: add check for cpufreq_cpu_get&amp;#39;s return value<br /> <br /> cpufreq_cpu_get may return NULL. To avoid NULL-dereference check it<br /> and return 0 in case of error.<br /> <br /> Found by Linux Verification Center (linuxtesting.org) with SVACE.