Linux-stable-mirror June 2023

linux-stable-mirror@lists.linaro.org

414 participants
1197 discussions

[PATCH 5.15.y 1/5] binder: fix UAF caused by faulty buffer cleanup

by Carlos Llamas

commit bdc1c5fac982845a58d28690cdb56db8c88a530d upstream. In binder_transaction_buffer_release() the 'failed_at' offset indicates the number of objects to clean up. However, this function was changed by commit 44d8047f1d87 ("binder: use standard functions to allocate fds"), to release all the objects in the buffer when 'failed_at' is zero. This introduced an issue when a transaction buffer is released without any objects having been processed so far. In this case, 'failed_at' is indeed zero yet it is misinterpreted as releasing the entire buffer. This leads to use-after-free errors where nodes are incorrectly freed and subsequently accessed. Such is the case in the following KASAN report: ================================================================== BUG: KASAN: slab-use-after-free in binder_thread_read+0xc40/0x1f30 Read of size 8 at addr ffff4faf037cfc58 by task poc/474 CPU: 6 PID: 474 Comm: poc Not tainted 6.3.0-12570-g7df047b3f0aa #5 Hardware name: linux,dummy-virt (DT) Call trace: dump_backtrace+0x94/0xec show_stack+0x18/0x24 dump_stack_lvl+0x48/0x60 print_report+0xf8/0x5b8 kasan_report+0xb8/0xfc __asan_load8+0x9c/0xb8 binder_thread_read+0xc40/0x1f30 binder_ioctl+0xd9c/0x1768 __arm64_sys_ioctl+0xd4/0x118 invoke_syscall+0x60/0x188 [...] Allocated by task 474: kasan_save_stack+0x3c/0x64 kasan_set_track+0x2c/0x40 kasan_save_alloc_info+0x24/0x34 __kasan_kmalloc+0xb8/0xbc kmalloc_trace+0x48/0x5c binder_new_node+0x3c/0x3a4 binder_transaction+0x2b58/0x36f0 binder_thread_write+0x8e0/0x1b78 binder_ioctl+0x14a0/0x1768 __arm64_sys_ioctl+0xd4/0x118 invoke_syscall+0x60/0x188 [...] Freed by task 475: kasan_save_stack+0x3c/0x64 kasan_set_track+0x2c/0x40 kasan_save_free_info+0x38/0x5c __kasan_slab_free+0xe8/0x154 __kmem_cache_free+0x128/0x2bc kfree+0x58/0x70 binder_dec_node_tmpref+0x178/0x1fc binder_transaction_buffer_release+0x430/0x628 binder_transaction+0x1954/0x36f0 binder_thread_write+0x8e0/0x1b78 binder_ioctl+0x14a0/0x1768 __arm64_sys_ioctl+0xd4/0x118 invoke_syscall+0x60/0x188 [...] ================================================================== In order to avoid these issues, let's always calculate the intended 'failed_at' offset beforehand. This is renamed and wrapped in a helper function to make it clear and convenient. Fixes: 32e9f56a96d8 ("binder: don't detect sender/target during buffer cleanup") Reported-by: Zi Fan Tan <zifantan(a)google.com> Cc: stable(a)vger.kernel.org Signed-off-by: Carlos Llamas <cmllamas(a)google.com> Acked-by: Todd Kjos <tkjos(a)google.com> Link: https://lore.kernel.org/r/20230505203020.4101154-1-cmllamas@google.com Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> [cmllamas: resolve trivial conflict due to missing commit 9864bb4801331] Signed-off-by: Carlos Llamas <cmllamas(a)google.com> --- drivers/android/binder.c | 26 ++++++++++++++++++++------ 1 file changed, 20 insertions(+), 6 deletions(-) diff --git a/drivers/android/binder.c b/drivers/android/binder.c index c8d33c5dbe29..a4749b6c3d73 100644 --- a/drivers/android/binder.c +++ b/drivers/android/binder.c @@ -1903,24 +1903,23 @@ static void binder_deferred_fd_close(int fd) static void binder_transaction_buffer_release(struct binder_proc *proc, struct binder_thread *thread, struct binder_buffer *buffer, - binder_size_t failed_at, + binder_size_t off_end_offset, bool is_failure) { int debug_id = buffer->debug_id; - binder_size_t off_start_offset, buffer_offset, off_end_offset; + binder_size_t off_start_offset, buffer_offset; binder_debug(BINDER_DEBUG_TRANSACTION, "%d buffer release %d, size %zd-%zd, failed at %llx\n", proc->pid, buffer->debug_id, buffer->data_size, buffer->offsets_size, - (unsigned long long)failed_at); + (unsigned long long)off_end_offset); if (buffer->target_node) binder_dec_node(buffer->target_node, 1, 0); off_start_offset = ALIGN(buffer->data_size, sizeof(void *)); - off_end_offset = is_failure && failed_at ? failed_at : - off_start_offset + buffer->offsets_size; + for (buffer_offset = off_start_offset; buffer_offset < off_end_offset; buffer_offset += sizeof(binder_size_t)) { struct binder_object_header *hdr; @@ -2080,6 +2079,21 @@ static void binder_transaction_buffer_release(struct binder_proc *proc, } } +/* Clean up all the objects in the buffer */ +static inline void binder_release_entire_buffer(struct binder_proc *proc, + struct binder_thread *thread, + struct binder_buffer *buffer, + bool is_failure) +{ + binder_size_t off_end_offset; + + off_end_offset = ALIGN(buffer->data_size, sizeof(void *)); + off_end_offset += buffer->offsets_size; + + binder_transaction_buffer_release(proc, thread, buffer, + off_end_offset, is_failure); +} + static int binder_translate_binder(struct flat_binder_object *fp, struct binder_transaction *t, struct binder_thread *thread) @@ -3578,7 +3592,7 @@ binder_free_buf(struct binder_proc *proc, binder_node_inner_unlock(buf_node); } trace_binder_transaction_buffer_release(buffer); - binder_transaction_buffer_release(proc, thread, buffer, 0, is_failure); + binder_release_entire_buffer(proc, thread, buffer, is_failure); binder_alloc_free_buf(&proc->alloc, buffer); } -- 2.41.0.rc0.172.g3f132b7071-goog

1 year, 4 months

Re: [PATCH 6.1 1/1] bluetooth: Add cmd validity checks at the start of hci_sock_ioctl()

by Greg KH

On Wed, May 31, 2023 at 10:06:11AM +0000, Panait, Dragos Marian wrote: > Done! (without the cover letter for newer kernels :)) All now queued up, thanks. You could have just send a one sentance email saying "Please apply commit XYZ to all stable kernels please" which would have been much simpler and easier for you :) thanks, greg k-h

1 year, 4 months

[PATCH] drm/msm/a6xx: fix uninitialised lock in init error path

by Johan Hovold

A recent commit started taking the GMU lock in the GPU destroy path, which on GPU initialisation failure is called before the GMU and its lock have been initialised. Make sure that the GMU has been initialised before taking the lock in a6xx_destroy() and drop the now redundant check from a6xx_gmu_remove(). Fixes: 4cd15a3e8b36 ("drm/msm/a6xx: Make GPU destroy a bit safer") Cc: stable(a)vger.kernel.org # 6.3 Cc: Douglas Anderson <dianders(a)chromium.org> Signed-off-by: Johan Hovold <johan+linaro(a)kernel.org> --- drivers/gpu/drm/msm/adreno/a6xx_gmu.c | 3 --- drivers/gpu/drm/msm/adreno/a6xx_gpu.c | 9 ++++++--- 2 files changed, 6 insertions(+), 6 deletions(-) diff --git a/drivers/gpu/drm/msm/adreno/a6xx_gmu.c b/drivers/gpu/drm/msm/adreno/a6xx_gmu.c index e16b4b3f8535..105ccf17041f 100644 --- a/drivers/gpu/drm/msm/adreno/a6xx_gmu.c +++ b/drivers/gpu/drm/msm/adreno/a6xx_gmu.c @@ -1472,9 +1472,6 @@ void a6xx_gmu_remove(struct a6xx_gpu *a6xx_gpu) struct a6xx_gmu *gmu = &a6xx_gpu->gmu; struct platform_device *pdev = to_platform_device(gmu->dev); - if (!gmu->initialized) - return; - pm_runtime_force_suspend(gmu->dev); /* diff --git a/drivers/gpu/drm/msm/adreno/a6xx_gpu.c b/drivers/gpu/drm/msm/adreno/a6xx_gpu.c index 9fb214f150dd..ee47b95a0205 100644 --- a/drivers/gpu/drm/msm/adreno/a6xx_gpu.c +++ b/drivers/gpu/drm/msm/adreno/a6xx_gpu.c @@ -1684,6 +1684,7 @@ static void a6xx_destroy(struct msm_gpu *gpu) { struct adreno_gpu *adreno_gpu = to_adreno_gpu(gpu); struct a6xx_gpu *a6xx_gpu = to_a6xx_gpu(adreno_gpu); + struct a6xx_gmu *gmu = &a6xx_gpu->gmu; if (a6xx_gpu->sqe_bo) { msm_gem_unpin_iova(a6xx_gpu->sqe_bo, gpu->aspace); @@ -1697,9 +1698,11 @@ static void a6xx_destroy(struct msm_gpu *gpu) a6xx_llc_slices_destroy(a6xx_gpu); - mutex_lock(&a6xx_gpu->gmu.lock); - a6xx_gmu_remove(a6xx_gpu); - mutex_unlock(&a6xx_gpu->gmu.lock); + if (gmu->initialized) { + mutex_lock(&gmu->lock); + a6xx_gmu_remove(a6xx_gpu); + mutex_unlock(&gmu->lock); + } adreno_gpu_cleanup(adreno_gpu); -- 2.39.3

1 year, 4 months

WARNING trace at kvm_nx_huge_page_recovery_worker on 6.3.4

by Fabio Coatti

Hi all, I'm using vanilla kernels on a gentoo-based laptop and since 6.3.2 I'm getting the kernel log below when using kvm VM on my box. I know, kernel is tainted but avoiding to load nvidia driver could make things complicated on my side; if needed for debug I can try to avoid it. Not sure which other infos can be relevant in this context; if you need more details just let me know, happy to provide them. [Fri May 26 09:16:35 2023] ------------[ cut here ]------------ [Fri May 26 09:16:35 2023] WARNING: CPU: 5 PID: 4684 at kvm_nx_huge_page_recovery_worker+0x38c/0x3d0 [kvm] [Fri May 26 09:16:35 2023] Modules linked in: vhost_net vhost vhost_iotlb tap tun tls rfcomm snd_hrtimer snd_seq xt_CHECKSUM algif_skcipher xt_MASQUERADE xt_conntrack ipt_REJECT nf_reject_ipv4 ip6table_mangle ip6table_nat ip6table_filter ip6_tables iptable_mangle iptable_nat nf_nat iptable_filter ip_tables bpfilter bridge stp llc rmi_smbus rmi_core bnep squashfs sch_fq_codel nvidia_drm(POE) intel_rapl_msr vboxnetadp(OE) vboxnetflt(OE) nvidia_modeset(POE) mei_pxp mei_hdcp rtsx_pci_sdmmc vboxdrv(OE) mmc_core intel_rapl_common intel_pmc_core_pltdrv intel_pmc_core snd_ctl_led intel_tcc_cooling snd_hda_codec_realtek snd_hda_codec_generic x86_pkg_temp_thermal intel_powerclamp btusb btrtl snd_usb_audio btbcm btmtk kvm_intel btintel snd_hda_intel snd_intel_dspcfg snd_usbmidi_lib snd_hda_codec snd_rawmidi snd_hwdep bluetooth snd_hda_core snd_seq_device kvm snd_pcm thinkpad_acpi iwlmvm mousedev ledtrig_audio uvcvideo snd_timer ecdh_generic irqbypass crct10dif_pclmul crc32_pclmul polyval_clmulni snd think_lmi joydev mei_me ecc uvc [Fri May 26 09:16:35 2023] polyval_generic rtsx_pci iwlwifi firmware_attributes_class psmouse wmi_bmof soundcore intel_pch_thermal mei platform_profile input_leds evdev nvidia(POE) coretemp hwmon akvcam(OE) videobuf2_vmalloc videobuf2_memops videobuf2_v4l2 videodev videobuf2_common mc loop nfsd auth_rpcgss nfs_acl efivarfs dmi_sysfs dm_zero dm_thin_pool dm_persistent_data dm_bio_prison dm_service_time dm_round_robin dm_queue_length dm_multipath dm_delay virtio_pci virtio_pci_legacy_dev virtio_pci_modern_dev virtio_blk virtio_console virtio_balloon vxlan ip6_udp_tunnel udp_tunnel macvlan virtio_net net_failover failover virtio_ring virtio fuse overlay nfs lockd grace sunrpc linear raid10 raid1 raid0 dm_raid raid456 async_raid6_recov async_memcpy async_pq async_xor async_tx md_mod dm_snapshot dm_bufio dm_crypt trusted asn1_encoder tpm rng_core dm_mirror dm_region_hash dm_log firewire_core crc_itu_t hid_apple usb_storage ehci_pci ehci_hcd sr_mod cdrom ahci libahci libata [Fri May 26 09:16:35 2023] CPU: 5 PID: 4684 Comm: kvm-nx-lpage-re Tainted: P U OE 6.3.4-cova #1 [Fri May 26 09:16:35 2023] Hardware name: LENOVO 20EQS58500/20EQS58500, BIOS N1EET98W (1.71 ) 12/06/2022 [Fri May 26 09:16:35 2023] RIP: 0010:kvm_nx_huge_page_recovery_worker+0x38c/0x3d0 [kvm] [Fri May 26 09:16:35 2023] Code: 48 8b 44 24 30 4c 39 e0 0f 85 1b fe ff ff 48 89 df e8 2e ab fb ff e9 23 fe ff ff 49 bc ff ff ff ff ff ff ff 7f e9 fb fc ff ff <0f> 0b e9 1b ff ff ff 48 8b 44 24 40 65 48 2b 04 25 28 00 00 00 75 [Fri May 26 09:16:35 2023] RSP: 0018:ffff8e1a4403fe68 EFLAGS: 00010246 [Fri May 26 09:16:35 2023] RAX: 0000000000000000 RBX: ffff8e1a42bbd000 RCX: 0000000000000000 [Fri May 26 09:16:35 2023] RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000 [Fri May 26 09:16:35 2023] RBP: ffff8b4e9a56d930 R08: 0000000000000000 R09: ffff8b4e9a56d8a0 [Fri May 26 09:16:35 2023] R10: 0000000000000000 R11: 0000000000000001 R12: ffff8e1a4403fe98 [Fri May 26 09:16:35 2023] R13: 0000000000000001 R14: ffff8b4d9c432e80 R15: 0000000000000010 [Fri May 26 09:16:35 2023] FS: 0000000000000000(0000) GS:ffff8b5cdf740000(0000) knlGS:0000000000000000 [Fri May 26 09:16:35 2023] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [Fri May 26 09:16:35 2023] CR2: 00007efeac53d000 CR3: 0000000978c2c003 CR4: 00000000003726e0 [Fri May 26 09:16:35 2023] Call Trace: [Fri May 26 09:16:35 2023] <TASK> [Fri May 26 09:16:35 2023] ? __pfx_kvm_nx_huge_page_recovery_worker+0x10/0x10 [kvm] [Fri May 26 09:16:35 2023] kvm_vm_worker_thread+0x106/0x1c0 [kvm] [Fri May 26 09:16:35 2023] ? __pfx_kvm_vm_worker_thread+0x10/0x10 [kvm] [Fri May 26 09:16:35 2023] kthread+0xd9/0x100 [Fri May 26 09:16:35 2023] ? __pfx_kthread+0x10/0x10 [Fri May 26 09:16:35 2023] ret_from_fork+0x2c/0x50 [Fri May 26 09:16:35 2023] </TASK> [Fri May 26 09:16:35 2023] ---[ end trace 0000000000000000 ]--- -- Fabio

1 year, 4 months

[PATCH v2] ceph: fix use-after-free bug for inodes when flushing capsnaps

by xiubli＠redhat.com

From: Xiubo Li <xiubli(a)redhat.com> There is racy between capsnaps flush and removing the inode from 'mdsc->snap_flush_list' list: == Thread A == == Thread B == ceph_queue_cap_snap() -> allocate 'capsnapA' ->ihold('&ci->vfs_inode') ->add 'capsnapA' to 'ci->i_cap_snaps' ->add 'ci' to 'mdsc->snap_flush_list' ... == Thread C == ceph_flush_snaps() ->__ceph_flush_snaps() ->__send_flush_snap() handle_cap_flushsnap_ack() ->iput('&ci->vfs_inode') this also will release 'ci' ... == Thread D == ceph_handle_snap() ->flush_snaps() ->iterate 'mdsc->snap_flush_list' ->get the stale 'ci' ->remove 'ci' from ->ihold(&ci->vfs_inode) this 'mdsc->snap_flush_list' will WARNING To fix this we will increase the ihold the inode when adding 'ci' to the 'mdsc->snap_flush_list' list. Cc: stable(a)vger.kernel.org URL: https://bugzilla.redhat.com/show_bug.cgi?id=2209299 Signed-off-by: Xiubo Li <xiubli(a)redhat.com> --- V2: - Increase the i_count reference instead to fix this issue fs/ceph/caps.c | 6 ++++++ fs/ceph/snap.c | 4 +++- 2 files changed, 9 insertions(+), 1 deletion(-) diff --git a/fs/ceph/caps.c b/fs/ceph/caps.c index feabf4cc0c4f..7c2cb813aba4 100644 --- a/fs/ceph/caps.c +++ b/fs/ceph/caps.c @@ -1684,6 +1684,7 @@ void ceph_flush_snaps(struct ceph_inode_info *ci, struct inode *inode = &ci->netfs.inode; struct ceph_mds_client *mdsc = ceph_inode_to_client(inode)->mdsc; struct ceph_mds_session *session = NULL; + int put = 0; int mds; dout("ceph_flush_snaps %p\n", inode); @@ -1728,8 +1729,13 @@ void ceph_flush_snaps(struct ceph_inode_info *ci, ceph_put_mds_session(session); /* we flushed them all; remove this inode from the queue */ spin_lock(&mdsc->snap_flush_lock); + if (!list_empty(&ci->i_snap_flush_item)) + put++; list_del_init(&ci->i_snap_flush_item); spin_unlock(&mdsc->snap_flush_lock); + + if (put) + iput(inode); } /* diff --git a/fs/ceph/snap.c b/fs/ceph/snap.c index 5a4bf0201737..d5ad10d94424 100644 --- a/fs/ceph/snap.c +++ b/fs/ceph/snap.c @@ -697,8 +697,10 @@ int __ceph_finish_cap_snap(struct ceph_inode_info *ci, capsnap->size); spin_lock(&mdsc->snap_flush_lock); - if (list_empty(&ci->i_snap_flush_item)) + if (list_empty(&ci->i_snap_flush_item)) { + ihold(inode); list_add_tail(&ci->i_snap_flush_item, &mdsc->snap_flush_list); + } spin_unlock(&mdsc->snap_flush_lock); return 1; /* caller may want to ceph_flush_snaps */ } -- 2.40.1

1 year, 4 months

[PATCH] scsi: stex: Fix gcc 13 warnings

by Bart Van Assche

gcc 13 may assign another type to enumeration constants than gcc 12. Split the large enum at the top of source file stex.c such that the type of the constants used in time expressions is changed back to the same type chosen by gcc 12. This patch suppresses compiler warnings like this one: In file included from ./include/linux/bitops.h:7, from ./include/linux/kernel.h:22, from drivers/scsi/stex.c:13: drivers/scsi/stex.c: In function ‘stex_common_handshake’: ./include/linux/typecheck.h:12:25: error: comparison of distinct pointer types lacks a cast [-Werror] 12 | (void)(&__dummy == &__dummy2); \ | ^~ ./include/linux/jiffies.h:106:10: note: in expansion of macro ‘typecheck’ 106 | typecheck(unsigned long, b) && \ | ^~~~~~~~~ drivers/scsi/stex.c:1035:29: note: in expansion of macro ‘time_after’ 1035 | if (time_after(jiffies, before + MU_MAX_DELAY * HZ)) { | ^~~~~~~~~~ See also https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107405. Cc: stable(a)vger.kernel.org Acked-by: Randy Dunlap <rdunlap(a)infradead.org> Tested-by: Randy Dunlap <rdunlap(a)infradead.org> # build-tested Signed-off-by: Bart Van Assche <bvanassche(a)acm.org> --- drivers/scsi/stex.c | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/drivers/scsi/stex.c b/drivers/scsi/stex.c index 5b230e149c3d..8ffb75be99bc 100644 --- a/drivers/scsi/stex.c +++ b/drivers/scsi/stex.c @@ -109,7 +109,9 @@ enum { TASK_ATTRIBUTE_HEADOFQUEUE = 0x1, TASK_ATTRIBUTE_ORDERED = 0x2, TASK_ATTRIBUTE_ACA = 0x4, +}; +enum { SS_STS_NORMAL = 0x80000000, SS_STS_DONE = 0x40000000, SS_STS_HANDSHAKE = 0x20000000, @@ -121,7 +123,9 @@ enum { SS_I2H_REQUEST_RESET = 0x2000, SS_MU_OPERATIONAL = 0x80000000, +}; +enum { STEX_CDB_LENGTH = 16, STATUS_VAR_LEN = 128,

1 year, 4 months

[PATCH] mpi3mr: propagate sense data for admin queue SCSI IO

by Sumit Saxena

Copy the sense data to internal driver buffer when the firmware completes any SCSI IO command sent through admin queue with sense data for further use. Fixes: 506bc1a0d6ba ("scsi: mpi3mr: Add support for MPT commands") Cc: <stable(a)vger.kernel.org> Signed-off-by: Sathya Prakash <sathya.prakash(a)broadcom.com> Signed-off-by: Sumit Saxena <sumit.saxena(a)broadcom.com> --- drivers/scsi/mpi3mr/mpi3mr_fw.c | 5 +++++ 1 file changed, 5 insertions(+) diff --git a/drivers/scsi/mpi3mr/mpi3mr_fw.c b/drivers/scsi/mpi3mr/mpi3mr_fw.c index 9b56d13821c6..945783c30985 100644 --- a/drivers/scsi/mpi3mr/mpi3mr_fw.c +++ b/drivers/scsi/mpi3mr/mpi3mr_fw.c @@ -402,6 +402,11 @@ static void mpi3mr_process_admin_reply_desc(struct mpi3mr_ioc *mrioc, memcpy((u8 *)cmdptr->reply, (u8 *)def_reply, mrioc->reply_sz); } + if (sense_buf && cmdptr->sensebuf) { + cmdptr->is_sense = 1; + memcpy(cmdptr->sensebuf, sense_buf, + MPI3MR_SENSE_BUF_SZ); + } if (cmdptr->is_waiting) { complete(&cmdptr->done); cmdptr->is_waiting = 0; -- 2.18.1

1 year, 4 months

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror June 2023