Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/amdkfd: Fix double release compute pasid<br /> <br /> If kfd_process_device_init_vm returns failure after vm is converted to<br /> compute vm and vm-&gt;pasid set to compute pasid, KFD will not take<br /> pdd-&gt;drm_file reference. As a result, drm close file handler maybe<br /> called to release the compute pasid before KFD process destroy worker to<br /> release the same pasid and set vm-&gt;pasid to zero, this generates below<br /> WARNING backtrace and NULL pointer access.<br /> <br /> Add helper amdgpu_amdkfd_gpuvm_set_vm_pasid and call it at the last step<br /> of kfd_process_device_init_vm, to ensure vm pasid is the original pasid<br /> if acquiring vm failed or is the compute pasid with pdd-&gt;drm_file<br /> reference taken to avoid double release same pasid.<br /> <br /> amdgpu: Failed to create process VM object<br /> ida_free called for id=32770 which is not allocated.<br /> WARNING: CPU: 57 PID: 72542 at ../lib/idr.c:522 ida_free+0x96/0x140<br /> RIP: 0010:ida_free+0x96/0x140<br /> Call Trace:<br /> amdgpu_pasid_free_delayed+0xe1/0x2a0 [amdgpu]<br /> amdgpu_driver_postclose_kms+0x2d8/0x340 [amdgpu]<br /> drm_file_free.part.13+0x216/0x270 [drm]<br /> drm_close_helper.isra.14+0x60/0x70 [drm]<br /> drm_release+0x6e/0xf0 [drm]<br /> __fput+0xcc/0x280<br /> ____fput+0xe/0x20<br /> task_work_run+0x96/0xc0<br /> do_exit+0x3d0/0xc10<br /> <br /> BUG: kernel NULL pointer dereference, address: 0000000000000000<br /> RIP: 0010:ida_free+0x76/0x140<br /> Call Trace:<br /> amdgpu_pasid_free_delayed+0xe1/0x2a0 [amdgpu]<br /> amdgpu_driver_postclose_kms+0x2d8/0x340 [amdgpu]<br /> drm_file_free.part.13+0x216/0x270 [drm]<br /> drm_close_helper.isra.14+0x60/0x70 [drm]<br /> drm_release+0x6e/0xf0 [drm]<br /> __fput+0xcc/0x280<br /> ____fput+0xe/0x20<br /> task_work_run+0x96/0xc0<br /> do_exit+0x3d0/0xc10

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> lockd: set other missing fields when unlocking files<br /> <br /> vfs_lock_file() expects the struct file_lock to be fully initialised by<br /> the caller. Re-exported NFSv3 has been seen to Oops if the fl_file field<br /> is NULL.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> iommu/omap: Fix buffer overflow in debugfs<br /> <br /> There are two issues here:<br /> <br /> 1) The "len" variable needs to be checked before the very first write.<br /> Otherwise if omap2_iommu_dump_ctx() with "bytes" less than 32 it is a<br /> buffer overflow.<br /> 2) The snprintf() function returns the number of bytes that *would* have<br /> been copied if there were enough space. But we want to know the<br /> number of bytes which were *actually* copied so use scnprintf()<br /> instead.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> btrfs: fix extent map use-after-free when handling missing device in read_one_chunk<br /> <br /> Store the error code before freeing the extent_map. Though it&amp;#39;s<br /> reference counted structure, in that function it&amp;#39;s the first and last<br /> allocation so this would lead to a potential use-after-free.<br /> <br /> The error can happen eg. when chunk is stored on a missing device and<br /> the degraded mount option is missing.<br /> <br /> Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=216721

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> md: Replace snprintf with scnprintf<br /> <br /> Current code produces a warning as shown below when total characters<br /> in the constituent block device names plus the slashes exceeds 200.<br /> snprintf() returns the number of characters generated from the given<br /> input, which could cause the expression “200 – len” to wrap around<br /> to a large positive number. Fix this by using scnprintf() instead,<br /> which returns the actual number of characters written into the buffer.<br /> <br /> [ 1513.267938] ------------[ cut here ]------------<br /> [ 1513.267943] WARNING: CPU: 15 PID: 37247 at /lib/vsprintf.c:2509 vsnprintf+0x2c8/0x510<br /> [ 1513.267944] Modules linked in: <br /> [ 1513.267969] CPU: 15 PID: 37247 Comm: mdadm Not tainted 5.4.0-1085-azure #90~18.04.1-Ubuntu<br /> [ 1513.267969] Hardware name: Microsoft Corporation Virtual Machine/Virtual Machine, BIOS Hyper-V UEFI Release v4.1 05/09/2022<br /> [ 1513.267971] RIP: 0010:vsnprintf+0x2c8/0x510<br /> <br /> [ 1513.267982] Call Trace:<br /> [ 1513.267986] snprintf+0x45/0x70<br /> [ 1513.267990] ? disk_name+0x71/0xa0<br /> [ 1513.267993] dump_zones+0x114/0x240 [raid0]<br /> [ 1513.267996] ? _cond_resched+0x19/0x40<br /> [ 1513.267998] raid0_run+0x19e/0x270 [raid0]<br /> [ 1513.268000] md_run+0x5e0/0xc50<br /> [ 1513.268003] ? security_capable+0x3f/0x60<br /> [ 1513.268005] do_md_run+0x19/0x110<br /> [ 1513.268006] md_ioctl+0x195e/0x1f90<br /> [ 1513.268007] blkdev_ioctl+0x91f/0x9f0<br /> [ 1513.268010] block_ioctl+0x3d/0x50<br /> [ 1513.268012] do_vfs_ioctl+0xa9/0x640<br /> [ 1513.268014] ? __fput+0x162/0x260<br /> [ 1513.268016] ksys_ioctl+0x75/0x80<br /> [ 1513.268017] __x64_sys_ioctl+0x1a/0x20<br /> [ 1513.268019] do_syscall_64+0x5e/0x200<br /> [ 1513.268021] entry_SYSCALL_64_after_hwframe+0x44/0xa9

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> slimbus: qcom-ngd: cleanup in probe error path<br /> <br /> Add proper error path in probe() to cleanup resources previously<br /> acquired/allocated to fix warnings visible during probe deferral:<br /> <br /> notifier callback qcom_slim_ngd_ssr_notify already registered<br /> WARNING: CPU: 6 PID: 70 at kernel/notifier.c:28 notifier_chain_register+0x5c/0x90<br /> Modules linked in:<br /> CPU: 6 PID: 70 Comm: kworker/u16:1 Not tainted 6.0.0-rc3-next-20220830 #380<br /> Call trace:<br /> notifier_chain_register+0x5c/0x90<br /> srcu_notifier_chain_register+0x44/0x90<br /> qcom_register_ssr_notifier+0x38/0x4c<br /> qcom_slim_ngd_ctrl_probe+0xd8/0x400<br /> platform_probe+0x6c/0xe0<br /> really_probe+0xbc/0x2d4<br /> __driver_probe_device+0x78/0xe0<br /> driver_probe_device+0x3c/0x12c<br /> __device_attach_driver+0xb8/0x120<br /> bus_for_each_drv+0x78/0xd0<br /> __device_attach+0xa8/0x1c0<br /> device_initial_probe+0x18/0x24<br /> bus_probe_device+0xa0/0xac<br /> deferred_probe_work_func+0x88/0xc0<br /> process_one_work+0x1d4/0x320<br /> worker_thread+0x2cc/0x44c<br /> kthread+0x110/0x114<br /> ret_from_fork+0x10/0x20

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> wifi: ath9k: verify the expected usb_endpoints are present<br /> <br /> The bug arises when a USB device claims to be an ATH9K but doesn&amp;#39;t<br /> have the expected endpoints. (In this case there was an interrupt<br /> endpoint where the driver expected a bulk endpoint.) The kernel<br /> needs to be able to handle such devices without getting an internal error.<br /> <br /> usb 1-1: BOGUS urb xfer, pipe 3 != type 1<br /> WARNING: CPU: 3 PID: 500 at drivers/usb/core/urb.c:493 usb_submit_urb+0xce2/0x1430 drivers/usb/core/urb.c:493<br /> Modules linked in:<br /> CPU: 3 PID: 500 Comm: kworker/3:2 Not tainted 5.10.135-syzkaller #0<br /> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.12.0-1 04/01/2014<br /> Workqueue: events request_firmware_work_func<br /> RIP: 0010:usb_submit_urb+0xce2/0x1430 drivers/usb/core/urb.c:493<br /> Call Trace:<br /> ath9k_hif_usb_alloc_rx_urbs drivers/net/wireless/ath/ath9k/hif_usb.c:908 [inline]<br /> ath9k_hif_usb_alloc_urbs+0x75e/0x1010 drivers/net/wireless/ath/ath9k/hif_usb.c:1019<br /> ath9k_hif_usb_dev_init drivers/net/wireless/ath/ath9k/hif_usb.c:1109 [inline]<br /> ath9k_hif_usb_firmware_cb+0x142/0x530 drivers/net/wireless/ath/ath9k/hif_usb.c:1242<br /> request_firmware_work_func+0x12e/0x240 drivers/base/firmware_loader/main.c:1097<br /> process_one_work+0x9af/0x1600 kernel/workqueue.c:2279<br /> worker_thread+0x61d/0x12f0 kernel/workqueue.c:2425<br /> kthread+0x3b4/0x4a0 kernel/kthread.c:313<br /> ret_from_fork+0x22/0x30 arch/x86/entry/entry_64.S:299<br /> <br /> Found by Linux Verification Center (linuxtesting.org) with Syzkaller.

Rejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> io_uring/msg_ring: Fix NULL pointer dereference in io_msg_send_fd()<br /> <br /> Syzkaller produced the below call trace:<br /> <br /> BUG: KASAN: null-ptr-deref in io_msg_ring+0x3cb/0x9f0<br /> Write of size 8 at addr 0000000000000070 by task repro/16399<br /> <br /> CPU: 0 PID: 16399 Comm: repro Not tainted 6.1.0-rc1 #28<br /> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.11.0-2.el7<br /> Call Trace:<br /> <br /> dump_stack_lvl+0xcd/0x134<br /> ? io_msg_ring+0x3cb/0x9f0<br /> kasan_report+0xbc/0xf0<br /> ? io_msg_ring+0x3cb/0x9f0<br /> kasan_check_range+0x140/0x190<br /> io_msg_ring+0x3cb/0x9f0<br /> ? io_msg_ring_prep+0x300/0x300<br /> io_issue_sqe+0x698/0xca0<br /> io_submit_sqes+0x92f/0x1c30<br /> __do_sys_io_uring_enter+0xae4/0x24b0<br /> ....<br /> RIP: 0033:0x7f2eaf8f8289<br /> RSP: 002b:00007fff40939718 EFLAGS: 00000246 ORIG_RAX: 00000000000001aa<br /> RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007f2eaf8f8289<br /> RDX: 0000000000000000 RSI: 0000000000006f71 RDI: 0000000000000004<br /> RBP: 00007fff409397a0 R08: 0000000000000000 R09: 0000000000000039<br /> R10: 0000000000000000 R11: 0000000000000246 R12: 00000000004006d0<br /> R13: 00007fff40939880 R14: 0000000000000000 R15: 0000000000000000<br /> <br /> Kernel panic - not syncing: panic_on_warn set ...<br /> <br /> We don&amp;#39;t have a NULL check on file_ptr in io_msg_send_fd() function,<br /> so when file_ptr is NUL src_file is also NULL and get_file()<br /> dereferences a NULL pointer and leads to above crash.<br /> <br /> Add a NULL check to fix this issue.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> btrfs: do not BUG_ON() on ENOMEM when dropping extent items for a range<br /> <br /> If we get -ENOMEM while dropping file extent items in a given range, at<br /> btrfs_drop_extents(), due to failure to allocate memory when attempting to<br /> increment the reference count for an extent or drop the reference count,<br /> we handle it with a BUG_ON(). This is excessive, instead we can simply<br /> abort the transaction and return the error to the caller. In fact most<br /> callers of btrfs_drop_extents(), directly or indirectly, already abort<br /> the transaction if btrfs_drop_extents() returns any error.<br /> <br /> Also, we already have error paths at btrfs_drop_extents() that may return<br /> -ENOMEM and in those cases we abort the transaction, like for example<br /> anything that changes the b+tree may return -ENOMEM due to a failure to<br /> allocate a new extent buffer when COWing an existing extent buffer, such<br /> as a call to btrfs_duplicate_item() for example.<br /> <br /> So replace the BUG_ON() calls with proper logic to abort the transaction<br /> and return the error.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/msm/dp: fix bridge lifetime<br /> <br /> Device-managed resources allocated post component bind must be tied to<br /> the lifetime of the aggregate DRM device or they will not necessarily be<br /> released when binding of the aggregate device is deferred.<br /> <br /> This can lead resource leaks or failure to bind the aggregate device<br /> when binding is later retried and a second attempt to allocate the<br /> resources is made.<br /> <br /> For the DP bridges, previously allocated bridges will leak on probe<br /> deferral.<br /> <br /> Fix this by amending the DP parser interface and tying the lifetime of<br /> the bridge device to the DRM device rather than DP platform device.<br /> <br /> Patchwork: https://patchwork.freedesktop.org/patch/502667/

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> kcm: annotate data-races around kcm-&gt;rx_psock<br /> <br /> kcm-&gt;rx_psock can be read locklessly in kcm_rfree().<br /> Annotate the read and writes accordingly.<br /> <br /> We do the same for kcm-&gt;rx_wait in the following patch.<br /> <br /> syzbot reported:<br /> BUG: KCSAN: data-race in kcm_rfree / unreserve_rx_kcm<br /> <br /> write to 0xffff888123d827b8 of 8 bytes by task 2758 on cpu 1:<br /> unreserve_rx_kcm+0x72/0x1f0 net/kcm/kcmsock.c:313<br /> kcm_rcv_strparser+0x2b5/0x3a0 net/kcm/kcmsock.c:373<br /> __strp_recv+0x64c/0xd20 net/strparser/strparser.c:301<br /> strp_recv+0x6d/0x80 net/strparser/strparser.c:335<br /> tcp_read_sock+0x13e/0x5a0 net/ipv4/tcp.c:1703<br /> strp_read_sock net/strparser/strparser.c:358 [inline]<br /> do_strp_work net/strparser/strparser.c:406 [inline]<br /> strp_work+0xe8/0x180 net/strparser/strparser.c:415<br /> process_one_work+0x3d3/0x720 kernel/workqueue.c:2289<br /> worker_thread+0x618/0xa70 kernel/workqueue.c:2436<br /> kthread+0x1a9/0x1e0 kernel/kthread.c:376<br /> ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:306<br /> <br /> read to 0xffff888123d827b8 of 8 bytes by task 5859 on cpu 0:<br /> kcm_rfree+0x14c/0x220 net/kcm/kcmsock.c:181<br /> skb_release_head_state+0x8e/0x160 net/core/skbuff.c:841<br /> skb_release_all net/core/skbuff.c:852 [inline]<br /> __kfree_skb net/core/skbuff.c:868 [inline]<br /> kfree_skb_reason+0x5c/0x260 net/core/skbuff.c:891<br /> kfree_skb include/linux/skbuff.h:1216 [inline]<br /> kcm_recvmsg+0x226/0x2b0 net/kcm/kcmsock.c:1161<br /> ____sys_recvmsg+0x16c/0x2e0<br /> ___sys_recvmsg net/socket.c:2743 [inline]<br /> do_recvmmsg+0x2f1/0x710 net/socket.c:2837<br /> __sys_recvmmsg net/socket.c:2916 [inline]<br /> __do_sys_recvmmsg net/socket.c:2939 [inline]<br /> __se_sys_recvmmsg net/socket.c:2932 [inline]<br /> __x64_sys_recvmmsg+0xde/0x160 net/socket.c:2932<br /> do_syscall_x64 arch/x86/entry/common.c:50 [inline]<br /> do_syscall_64+0x2b/0x70 arch/x86/entry/common.c:80<br /> entry_SYSCALL_64_after_hwframe+0x63/0xcd<br /> <br /> value changed: 0xffff88812971ce00 -&gt; 0x0000000000000000<br /> <br /> Reported by Kernel Concurrency Sanitizer on:<br /> CPU: 0 PID: 5859 Comm: syz-executor.3 Not tainted 6.0.0-syzkaller-12189-g19d17ab7c68b-dirty #0<br /> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/22/2022