Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> netfs: Fix leak of request in netfs_write_begin() error handling<br /> <br /> Fix netfs_write_begin() to not leak our ref on the request in the event<br /> that we get an error from netfs_wait_for_read().

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> netfs: Fix early put of sink folio in netfs_read_gaps()<br /> <br /> Fix netfs_read_gaps() to release the sink page it uses after waiting for<br /> the request to complete. The way the sink page is used is that an<br /> ITER_BVEC-class iterator is created that has the gaps from the target folio<br /> at either end, but has the sink page tiled over the middle so that a single<br /> read op can fill in both gaps.<br /> <br /> The bug was found by KASAN detecting a UAF on the generic/075 xfstest in<br /> the cifsd kernel thread that handles reception of data from the TCP socket:<br /> <br /> BUG: KASAN: use-after-free in _copy_to_iter+0x48a/0xa20<br /> Write of size 885 at addr ffff888107f92000 by task cifsd/1285<br /> CPU: 2 UID: 0 PID: 1285 Comm: cifsd Not tainted 7.0.0 #6 PREEMPT(lazy)<br /> Call Trace:<br /> dump_stack_lvl+0x5d/0x80<br /> print_report+0x17f/0x4f1<br /> kasan_report+0x100/0x1e0<br /> kasan_check_range+0x10f/0x1e0<br /> __asan_memcpy+0x3c/0x60<br /> _copy_to_iter+0x48a/0xa20<br /> __skb_datagram_iter+0x2c9/0x430<br /> skb_copy_datagram_iter+0x6e/0x160<br /> tcp_recvmsg_locked+0xce0/0x1130<br /> tcp_recvmsg+0xeb/0x300<br /> inet_recvmsg+0xcf/0x3a0<br /> sock_recvmsg+0xea/0x100<br /> cifs_readv_from_socket+0x3a6/0x4d0 [cifs]<br /> cifs_read_iter_from_socket+0xdd/0x130 [cifs]<br /> cifs_readv_receive+0xaad/0xb10 [cifs]<br /> cifs_demultiplex_thread+0x1148/0x1740 [cifs]<br /> kthread+0x1cf/0x210

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> netfs: Fix potential deadlock in write-through mode<br /> <br /> Fix netfs_advance_writethrough() to always unlock the supplied folio and to<br /> mark it dirty if it isn&amp;#39;t yet written to the end. Unfortunately, it can&amp;#39;t<br /> be marked for writeback until the folio is done with as that may cause a<br /> deadlock against mmapped reads and writes.<br /> <br /> Even though it has been marked dirty, premature writeback can&amp;#39;t occur as<br /> the caller is holding both inode-&gt;i_rwsem (which will prevent concurrent<br /> truncation, fallocation, DIO and other writes) and ictx-&gt;wb_lock (which<br /> will cause flushing to wait and writeback to skip or wait).<br /> <br /> Note that this may be easier to deal with once the queuing of folios is<br /> split from the generation of subrequests.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> netfs: Fix streaming write being overwritten<br /> <br /> In order to avoid reading whilst writing, netfslib will allow "streaming<br /> writes" in which dirty data is stored directly into folios without reading<br /> them first. Such folios are marked dirty but may not be marked uptodate.<br /> If a folio is entirely written by a streaming write, uptodate will be set,<br /> otherwise it will have a netfs_folio struct attached to -&gt;private recording<br /> the dirty region.<br /> <br /> In the event that a partially written streaming write page is to be<br /> overwritten entirely by a single write(), netfs_perform_write() will try to<br /> copy over it, but doesn&amp;#39;t discard the netfs_folio if it succeeds; further,<br /> it doesn&amp;#39;t correctly handle a partial copy that overwrites some of the<br /> dirty data.<br /> <br /> Fix this by the following:<br /> <br /> (1) If the folio is successfully overwritten, free the netfs_folio struct<br /> before marking the page uptodate.<br /> <br /> (2) If the copy to the folio partially fails, but short of the dirty data,<br /> just ignore the copy.<br /> <br /> (3) If the copy partially fails and overwrites some of the dirty data,<br /> accept the copy, update the netfs_folio struct to record the new data.<br /> If the folio is now filled, free the netfs_folio and set uptodate,<br /> otherwise return a partial write.<br /> <br /> Found with:<br /> <br /> fsx -q -N 1000000 -p 10000 -o 128000 -l 600000 \<br /> /xfstest.test/junk --replay-ops=junk.fsxops<br /> <br /> using the following as junk.fsxops:<br /> <br /> truncate 0x0 0 0x927c0<br /> write 0x63fb8 0x53c8 0<br /> copy_range 0xb704 0x19b9 0x24429 0x79380<br /> write 0x2402b 0x144a2 0x90660 *<br /> write 0x204d5 0x140a0 0x927c0 *<br /> copy_range 0x1f72c 0x137d0 0x7a906 0x927c0 *<br /> read 0x00000 0x20000 0x9157c<br /> read 0x20000 0x20000 0x9157c<br /> read 0x40000 0x20000 0x9157c<br /> read 0x60000 0x20000 0x9157c<br /> read 0x7e1a0 0xcfb9 0x9157c<br /> <br /> on cifs with the default cache option.<br /> <br /> It shows folio 0x24 misbehaving if the FMODE_READ check is commented out in<br /> netfs_perform_write():<br /> <br /> if (//(file-&gt;f_mode &amp; FMODE_READ) ||<br /> netfs_is_cache_enabled(ctx)) {<br /> <br /> and no fscache. This was initially found with the generic/522 xfstest.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> netfs: Fix netfs_invalidate_folio() to clear dirty bit if all changes gone<br /> <br /> If a streaming write is made, this will leave the relevant modified folio<br /> in a not-uptodate, but dirty state with a netfs_folio struct hung off of<br /> folio-&gt;private indicating the dirty range. Subsequently truncating the<br /> file such that the dirty data in the folio is removed, but the first part<br /> of the folio theoretically remains will cause the netfs_folio struct to be<br /> discarded... but will leave the dirty flag set.<br /> <br /> If the folio is then read via mmap(), netfs_read_folio() will see that the<br /> page is dirty and jump to netfs_read_gaps() to fill in the missing bits.<br /> netfs_read_gaps(), however, expects there to be a netfs_folio struct<br /> present and can oops because truncate removed it.<br /> <br /> Fix this by calling folio_cancel_dirty() in netfs_invalidate_folio() in the<br /> event that all the dirty data in the folio is erased (as nfs does).<br /> <br /> Also add some tracepoints to log modifications to a dirty page.<br /> <br /> This can be reproduced with something like:<br /> <br /> dd if=/dev/zero of=/xfstest.test/foo bs=1M count=1<br /> umount /xfstest.test<br /> mount /xfstest.test<br /> xfs_io -c "w 0xbbbf 0xf96c" \<br /> -c "truncate 0xbbbf" \<br /> -c "mmap -r 0xb000 0x11000" \<br /> -c "mr 0xb000 0x11000" \<br /> /xfstest.test/foo<br /> <br /> with fscaching disabled (otherwise streaming writes are suppressed) and a<br /> change to netfs_perform_write() to disallow streaming writes if the fd is<br /> open O_RDWR:<br /> <br /> if (//(file-&gt;f_mode &amp; FMODE_READ) ||

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: tls: fix off-by-one in sg_chain entry count for wrapped sk_msg ring<br /> <br /> When an sk_msg scatterlist ring wraps (sg.end sg.start],<br /> MAX_SKB_FRAGS - msg_pl-&gt;sg.start + 1,<br /> msg_pl-&gt;sg.data);<br /> <br /> This places the chain pointer at<br /> <br /> sg_chain(data[start], (MAX_SKB_FRAGS - msg_start + 1) .. =<br /> &amp;data[start] + (MAX_SKB_FRAGS - msg_start + 1) - 1 =<br /> data[start + (MAX_SKB_FRAGS - start + 1) - 1] =<br /> data[MAX_SKB_FRAGS]<br /> <br /> instead of the true last entry. This is likely due to a "race" of<br /> the commit under Fixes landing close to<br /> commit 031097d9e079 ("bpf: sk_msg, zap ingress queue on psock down")<br /> <br /> Convert to ARRAY_SIZE and drop the data[start] / - start (as suggested<br /> by Sabrina).

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net/smc: reject CHID-0 ACCEPT that matches an empty ism_dev slot<br /> <br /> On the SMC-D client, slot 0 of ini-&gt;ism_dev[]/ini-&gt;ism_chid[] is<br /> reserved for an SMC-Dv1 device. smc_find_ism_v2_device_clnt()<br /> populates V2 entries starting at index 1, so when no V1 device is<br /> selected slot 0 is left in its kzalloc()&amp;#39;ed state with ism_dev[0] ==<br /> NULL and ism_chid[0] == 0.<br /> <br /> smc_v2_determine_accepted_chid() then matches the peer&amp;#39;s CHID against<br /> the array starting from index 0 using the CHID alone. A malicious<br /> peer replying to a SMC-Dv2-only proposal with d1.chid == 0 matches<br /> the empty slot, ini-&gt;ism_selected becomes 0, and the subsequent<br /> ism_dev[0]-&gt;lgr_lock dereference in smc_conn_create() faults at<br /> offsetof(struct smcd_dev, lgr_lock) == 0x68:<br /> <br /> BUG: KASAN: null-ptr-deref in _raw_spin_lock_bh+0x79/0xe0<br /> Write of size 4 at addr 0000000000000068 by task exploit/144<br /> Call Trace:<br /> _raw_spin_lock_bh<br /> smc_conn_create (net/smc/smc_core.c:1997)<br /> __smc_connect (net/smc/af_smc.c:1447)<br /> smc_connect (net/smc/af_smc.c:1720)<br /> __sys_connect<br /> __x64_sys_connect<br /> do_syscall_64<br /> <br /> Require ism_dev[i] to be non-NULL before accepting a CHID match.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/msm/adreno: fix userspace-triggered crash on a2xx-a4xx<br /> <br /> Before a5xx Adreno driver will not try fetching UBWC params (because<br /> those generations didn&amp;#39;t support UBWC anyway), however it&amp;#39;s still<br /> possible to query UBWC-related params from the userspace, triggering<br /> possible NULL pointer dereference. Check for UBWC config in<br /> adreno_get_param() and return sane defaults if there is none.<br /> <br /> Patchwork: https://patchwork.freedesktop.org/patch/717778/

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/msm/dpu: don&amp;#39;t mix devm and drmm functions<br /> <br /> Mixing devm and drmm functions will result in a use-after-free on msm<br /> driver teardown if userspace keeps a reference on the drm device:<br /> The WB connector data will be destroyed because of the use of<br /> devm_kzalloc()), while the usersoace still can try interacting with the<br /> WB connector (which uses drmm_ functions).<br /> <br /> Change dpu_writeback_init() to use drmm_.<br /> <br /> Patchwork: https://patchwork.freedesktop.org/patch/722656/

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> accel/qaic: Add overflow check to remap_pfn_range during mmap<br /> <br /> The call to remap_pfn_range in qaic_gem_object_mmap is susceptible to<br /> (re)mapping beyond the VMA if the BO is too large. This can cause use<br /> after free issues when munmap() unmaps only the VMA region and not the<br /> additional mappings. To prevent this, check the remaining size of the<br /> VMA before remapping and truncate the remapped length if sg-&gt;length is<br /> too large.<br /> <br /> [jhugo: fix braces from checkpatch --strict]

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> block: bio-integrity: Fix null-ptr-deref in bio_integrity_map_user()<br /> <br /> pin_user_pages_fast() can partially succeed and return the number of<br /> pages that were actually pinned. However, the bio_integrity_map_user()<br /> does not handle this partial pinning. This leads to a general protection<br /> fault since bvec_from_pages() dereferences an unpinned page address,<br /> which is 0.<br /> <br /> To fix this, add a check to verify that all requested memory is pinned.<br /> If partial pinning occurs, unpin the memory and return -EFAULT.<br /> <br /> Kernel Oops:<br /> <br /> Oops: general protection fault, probably for non-canonical address 0xdffffc0000000001: 0000 [#1] SMP KASAN NOPTI<br /> KASAN: null-ptr-deref in range [0x0000000000000008-0x000000000000000f]<br /> CPU: 0 UID: 0 PID: 1061 Comm: nvme-passthroug Not tainted 7.0.0-11783-g90957f9314e8-dirty #16 PREEMPT(lazy)<br /> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.17.0-0-gb52ca86e094d-prebuilt.qemu.org 04/01/2014<br /> RIP: 0010:bio_integrity_map_user.cold+0x1b0/0x9d6

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> block: don&amp;#39;t overwrite bip_vcnt in bio_integrity_copy_user()<br /> <br /> bio_integrity_add_page() already sets bip_vcnt to 1 for the bounce<br /> segment. Overwriting it with nr_vecs breaks bip_vcnt