Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> arm64: entry: fix ARM64_WORKAROUND_SPECULATIVE_UNPRIV_LOAD<br /> <br /> Currently the ARM64_WORKAROUND_SPECULATIVE_UNPRIV_LOAD workaround isn&amp;#39;t<br /> quite right, as it is supposed to be applied after the last explicit<br /> memory access, but is immediately followed by an LDR.<br /> <br /> The ARM64_WORKAROUND_SPECULATIVE_UNPRIV_LOAD workaround is used to<br /> handle Cortex-A520 erratum 2966298 and Cortex-A510 erratum 3117295,<br /> which are described in:<br /> <br /> * https://developer.arm.com/documentation/SDEN2444153/0600/?lang=en<br /> * https://developer.arm.com/documentation/SDEN1873361/1600/?lang=en<br /> <br /> In both cases the workaround is described as:<br /> <br /> | If pagetable isolation is disabled, the context switch logic in the<br /> | kernel can be updated to execute the following sequence on affected<br /> | cores before exiting to EL0, and after all explicit memory accesses:<br /> |<br /> | 1. A non-shareable TLBI to any context and/or address, including<br /> | unused contexts or addresses, such as a `TLBI VALE1 Xzr`.<br /> |<br /> | 2. A DSB NSH to guarantee completion of the TLBI.<br /> <br /> The important part being that the TLBI+DSB must be placed "after all<br /> explicit memory accesses".<br /> <br /> Unfortunately, as-implemented, the TLBI+DSB is immediately followed by<br /> an LDR, as we have:<br /> <br /> | alternative_if ARM64_WORKAROUND_SPECULATIVE_UNPRIV_LOAD<br /> | tlbi vale1, xzr<br /> | dsb nsh<br /> | alternative_else_nop_endif<br /> | alternative_if_not ARM64_UNMAP_KERNEL_AT_EL0<br /> | ldr lr, [sp, #S_LR]<br /> | add sp, sp, #PT_REGS_SIZE // restore sp<br /> | eret<br /> | alternative_else_nop_endif<br /> |<br /> | [ ... KPTI exception return path ... ]<br /> <br /> This patch fixes this by reworking the logic to place the TLBI+DSB<br /> immediately before the ERET, after all explicit memory accesses.<br /> <br /> The ERET is currently in a separate alternative block, and alternatives<br /> cannot be nested. To account for this, the alternative block for<br /> ARM64_UNMAP_KERNEL_AT_EL0 is replaced with a single alternative branch<br /> to skip the KPTI logic, with the new shape of the logic being:<br /> <br /> | alternative_insn "b .L_skip_tramp_exit_\@", nop, ARM64_UNMAP_KERNEL_AT_EL0<br /> | [ ... KPTI exception return path ... ]<br /> | .L_skip_tramp_exit_\@:<br /> |<br /> | ldr lr, [sp, #S_LR]<br /> | add sp, sp, #PT_REGS_SIZE // restore sp<br /> |<br /> | alternative_if ARM64_WORKAROUND_SPECULATIVE_UNPRIV_LOAD<br /> | tlbi vale1, xzr<br /> | dsb nsh<br /> | alternative_else_nop_endif<br /> | eret<br /> <br /> The new structure means that the workaround is only applied when KPTI is<br /> not in use; this is fine as noted in the documented implications of the<br /> erratum:<br /> <br /> | Pagetable isolation between EL0 and higher level ELs prevents the<br /> | issue from occurring.<br /> <br /> ... and as per the workaround description quoted above, the workaround<br /> is only necessary "If pagetable isolation is disabled".

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> blk-mq: fix IO hang from sbitmap wakeup race<br /> <br /> In blk_mq_mark_tag_wait(), __add_wait_queue() may be re-ordered<br /> with the following blk_mq_get_driver_tag() in case of getting driver<br /> tag failure.<br /> <br /> Then in __sbitmap_queue_wake_up(), waitqueue_active() may not observe<br /> the added waiter in blk_mq_mark_tag_wait() and wake up nothing, meantime<br /> blk_mq_mark_tag_wait() can&amp;#39;t get driver tag successfully.<br /> <br /> This issue can be reproduced by running the following test in loop, and<br /> fio hang can be observed in

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/amdgpu: Fix variable &amp;#39;mca_funcs&amp;#39; dereferenced before NULL check in &amp;#39;amdgpu_mca_smu_get_mca_entry()&amp;#39;<br /> <br /> Fixes the below:<br /> <br /> drivers/gpu/drm/amd/amdgpu/amdgpu_mca.c:377 amdgpu_mca_smu_get_mca_entry() warn: variable dereferenced before check &amp;#39;mca_funcs&amp;#39; (see line 368)<br /> <br /> 357 int amdgpu_mca_smu_get_mca_entry(struct amdgpu_device *adev,<br /> enum amdgpu_mca_error_type type,<br /> 358 int idx, struct mca_bank_entry *entry)<br /> 359 {<br /> 360 const struct amdgpu_mca_smu_funcs *mca_funcs =<br /> adev-&gt;mca.mca_funcs;<br /> 361 int count;<br /> 362<br /> 363 switch (type) {<br /> 364 case AMDGPU_MCA_ERROR_TYPE_UE:<br /> 365 count = mca_funcs-&gt;max_ue_count;<br /> <br /> mca_funcs is dereferenced here.<br /> <br /> 366 break;<br /> 367 case AMDGPU_MCA_ERROR_TYPE_CE:<br /> 368 count = mca_funcs-&gt;max_ce_count;<br /> <br /> mca_funcs is dereferenced here.<br /> <br /> 369 break;<br /> 370 default:<br /> 371 return -EINVAL;<br /> 372 }<br /> 373<br /> 374 if (idx &gt;= count)<br /> 375 return -EINVAL;<br /> 376<br /> 377 if (mca_funcs &amp;&amp; mca_funcs-&gt;mca_get_mca_entry)<br /> ^^^^^^^^^<br /> <br /> Checked too late!

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> netfilter: nft_ct: sanitize layer 3 and 4 protocol number in custom expectations<br /> <br /> - Disallow families other than NFPROTO_{IPV4,IPV6,INET}.<br /> - Disallow layer 4 protocol with no ports, since destination port is a<br /> mandatory attribute for this object.

in OpenHarmony v3.2.4 and prior versions allow a local attacker cause apps crash through get permission.

in OpenHarmony v4.0.0 and prior versions allow a local attacker cause DOS through use after free.

in OpenHarmony v4.0.0 and prior versions allow a local attacker arbitrary code execution through out-of-bounds write.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/sched: fix null-ptr-deref in init entity<br /> <br /> The bug can be triggered by sending an amdgpu_cs_wait_ioctl<br /> to the AMDGPU DRM driver on any ASICs with valid context.<br /> The bug was reported by Joonkyo Jung .<br /> For example the following code:<br /> <br /> static void Syzkaller2(int fd)<br /> {<br /> union drm_amdgpu_ctx arg1;<br /> union drm_amdgpu_wait_cs arg2;<br /> <br /> arg1.in.op = AMDGPU_CTX_OP_ALLOC_CTX;<br /> ret = drmIoctl(fd, 0x140106442 /* amdgpu_ctx_ioctl */, &amp;arg1);<br /> <br /> arg2.in.handle = 0x0;<br /> arg2.in.timeout = 0x2000000000000;<br /> arg2.in.ip_type = AMD_IP_VPE /* 0x9 */;<br /> arg2-&gt;in.ip_instance = 0x0;<br /> arg2.in.ring = 0x0;<br /> arg2.in.ctx_id = arg1.out.alloc.ctx_id;<br /> <br /> drmIoctl(fd, 0xc0206449 /* AMDGPU_WAIT_CS * /, &amp;arg2);<br /> }<br /> <br /> The ioctl AMDGPU_WAIT_CS without previously submitted job could be assumed that<br /> the error should be returned, but the following commit 1decbf6bb0b4dc56c9da6c5e57b994ebfc2be3aa<br /> modified the logic and allowed to have sched_rq equal to NULL.<br /> <br /> As a result when there is no job the ioctl AMDGPU_WAIT_CS returns success.<br /> The change fixes null-ptr-deref in init entity and the stack below demonstrates<br /> the error condition:<br /> <br /> [ +0.000007] BUG: kernel NULL pointer dereference, address: 0000000000000028<br /> [ +0.007086] #PF: supervisor read access in kernel mode<br /> [ +0.005234] #PF: error_code(0x0000) - not-present page<br /> [ +0.005232] PGD 0 P4D 0<br /> [ +0.002501] Oops: 0000 [#1] PREEMPT SMP KASAN NOPTI<br /> [ +0.005034] CPU: 10 PID: 9229 Comm: amd_basic Tainted: G B W L 6.7.0+ #4<br /> [ +0.007797] Hardware name: ASUS System Product Name/ROG STRIX B550-F GAMING (WI-FI), BIOS 1401 12/03/2020<br /> [ +0.009798] RIP: 0010:drm_sched_entity_init+0x2d3/0x420 [gpu_sched]<br /> [ +0.006426] Code: 80 00 00 00 00 00 00 00 e8 1a 81 82 e0 49 89 9c 24 c0 00 00 00 4c 89 ef e8 4a 80 82 e0 49 8b 5d 00 48 8d 7b 28 e8 3d 80 82 e0 83 7b 28 00 0f 84 28 01 00 00 4d 8d ac 24 98 00 00 00 49 8d 5c<br /> [ +0.019094] RSP: 0018:ffffc90014c1fa40 EFLAGS: 00010282<br /> [ +0.005237] RAX: 0000000000000001 RBX: 0000000000000000 RCX: ffffffff8113f3fa<br /> [ +0.007326] RDX: fffffbfff0a7889d RSI: 0000000000000008 RDI: ffffffff853c44e0<br /> [ +0.007264] RBP: ffffc90014c1fa80 R08: 0000000000000001 R09: fffffbfff0a7889c<br /> [ +0.007266] R10: ffffffff853c44e7 R11: 0000000000000001 R12: ffff8881a719b010<br /> [ +0.007263] R13: ffff88810d412748 R14: 0000000000000002 R15: 0000000000000000<br /> [ +0.007264] FS: 00007ffff7045540(0000) GS:ffff8883cc900000(0000) knlGS:0000000000000000<br /> [ +0.008236] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> [ +0.005851] CR2: 0000000000000028 CR3: 000000011912e000 CR4: 0000000000350ef0<br /> [ +0.007175] Call Trace:<br /> [ +0.002561] <br /> [ +0.002141] ? show_regs+0x6a/0x80<br /> [ +0.003473] ? __die+0x25/0x70<br /> [ +0.003124] ? page_fault_oops+0x214/0x720<br /> [ +0.004179] ? preempt_count_sub+0x18/0xc0<br /> [ +0.004093] ? __pfx_page_fault_oops+0x10/0x10<br /> [ +0.004590] ? srso_return_thunk+0x5/0x5f<br /> [ +0.004000] ? vprintk_default+0x1d/0x30<br /> [ +0.004063] ? srso_return_thunk+0x5/0x5f<br /> [ +0.004087] ? vprintk+0x5c/0x90<br /> [ +0.003296] ? drm_sched_entity_init+0x2d3/0x420 [gpu_sched]<br /> [ +0.005807] ? srso_return_thunk+0x5/0x5f<br /> [ +0.004090] ? _printk+0xb3/0xe0<br /> [ +0.003293] ? __pfx__printk+0x10/0x10<br /> [ +0.003735] ? asm_sysvec_apic_timer_interrupt+0x1b/0x20<br /> [ +0.005482] ? do_user_addr_fault+0x345/0x770<br /> [ +0.004361] ? exc_page_fault+0x64/0xf0<br /> [ +0.003972] ? asm_exc_page_fault+0x27/0x30<br /> [ +0.004271] ? add_taint+0x2a/0xa0<br /> [ +0.003476] ? drm_sched_entity_init+0x2d3/0x420 [gpu_sched]<br /> [ +0.005812] amdgpu_ctx_get_entity+0x3f9/0x770 [amdgpu]<br /> [ +0.009530] ? finish_task_switch.isra.0+0x129/0x470<br /> [ +0.005068] ? __pfx_amdgpu_ctx_get_entity+0x10/0x10 [amdgpu]<br /> [ +0.010063] ? __kasan_check_write+0x14/0x20<br /> [ +0.004356] ? srso_return_thunk+0x5/0x5f<br /> [ +0.004001] ? mutex_unlock+0x81/0xd0<br /> [ +0.003802] ? srso_return_thunk+0x5/0x5f<br /> [ +0.004096] amdgpu_cs_wait_ioctl+0xf6/0x270 [amdgpu]<br /> [ +0.009355] ? __pfx_<br /> ---truncated---

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> bcachefs: grab s_umount only if snapshotting<br /> <br /> When I was testing mongodb over bcachefs with compression,<br /> there is a lockdep warning when snapshotting mongodb data volume.<br /> <br /> $ cat test.sh<br /> prog=bcachefs<br /> <br /> $prog subvolume create /mnt/data<br /> $prog subvolume create /mnt/data/snapshots<br /> <br /> while true;do<br /> $prog subvolume snapshot /mnt/data /mnt/data/snapshots/$(date +%s)<br /> sleep 1s<br /> done<br /> <br /> $ cat /etc/mongodb.conf<br /> systemLog:<br /> destination: file<br /> logAppend: true<br /> path: /mnt/data/mongod.log<br /> <br /> storage:<br /> dbPath: /mnt/data/<br /> <br /> lockdep reports:<br /> [ 3437.452330] ======================================================<br /> [ 3437.452750] WARNING: possible circular locking dependency detected<br /> [ 3437.453168] 6.7.0-rc7-custom+ #85 Tainted: G E<br /> [ 3437.453562] ------------------------------------------------------<br /> [ 3437.453981] bcachefs/35533 is trying to acquire lock:<br /> [ 3437.454325] ffffa0a02b2b1418 (sb_writers#10){.+.+}-{0:0}, at: filename_create+0x62/0x190<br /> [ 3437.454875]<br /> but task is already holding lock:<br /> [ 3437.455268] ffffa0a02b2b10e0 (&amp;type-&gt;s_umount_key#48){.+.+}-{3:3}, at: bch2_fs_file_ioctl+0x232/0xc90 [bcachefs]<br /> [ 3437.456009]<br /> which lock already depends on the new lock.<br /> <br /> [ 3437.456553]<br /> the existing dependency chain (in reverse order) is:<br /> [ 3437.457054]<br /> -&gt; #3 (&amp;type-&gt;s_umount_key#48){.+.+}-{3:3}:<br /> [ 3437.457507] down_read+0x3e/0x170<br /> [ 3437.457772] bch2_fs_file_ioctl+0x232/0xc90 [bcachefs]<br /> [ 3437.458206] __x64_sys_ioctl+0x93/0xd0<br /> [ 3437.458498] do_syscall_64+0x42/0xf0<br /> [ 3437.458779] entry_SYSCALL_64_after_hwframe+0x6e/0x76<br /> [ 3437.459155]<br /> -&gt; #2 (&amp;c-&gt;snapshot_create_lock){++++}-{3:3}:<br /> [ 3437.459615] down_read+0x3e/0x170<br /> [ 3437.459878] bch2_truncate+0x82/0x110 [bcachefs]<br /> [ 3437.460276] bchfs_truncate+0x254/0x3c0 [bcachefs]<br /> [ 3437.460686] notify_change+0x1f1/0x4a0<br /> [ 3437.461283] do_truncate+0x7f/0xd0<br /> [ 3437.461555] path_openat+0xa57/0xce0<br /> [ 3437.461836] do_filp_open+0xb4/0x160<br /> [ 3437.462116] do_sys_openat2+0x91/0xc0<br /> [ 3437.462402] __x64_sys_openat+0x53/0xa0<br /> [ 3437.462701] do_syscall_64+0x42/0xf0<br /> [ 3437.462982] entry_SYSCALL_64_after_hwframe+0x6e/0x76<br /> [ 3437.463359]<br /> -&gt; #1 (&amp;sb-&gt;s_type-&gt;i_mutex_key#15){+.+.}-{3:3}:<br /> [ 3437.463843] down_write+0x3b/0xc0<br /> [ 3437.464223] bch2_write_iter+0x5b/0xcc0 [bcachefs]<br /> [ 3437.464493] vfs_write+0x21b/0x4c0<br /> [ 3437.464653] ksys_write+0x69/0xf0<br /> [ 3437.464839] do_syscall_64+0x42/0xf0<br /> [ 3437.465009] entry_SYSCALL_64_after_hwframe+0x6e/0x76<br /> [ 3437.465231]<br /> -&gt; #0 (sb_writers#10){.+.+}-{0:0}:<br /> [ 3437.465471] __lock_acquire+0x1455/0x21b0<br /> [ 3437.465656] lock_acquire+0xc6/0x2b0<br /> [ 3437.465822] mnt_want_write+0x46/0x1a0<br /> [ 3437.465996] filename_create+0x62/0x190<br /> [ 3437.466175] user_path_create+0x2d/0x50<br /> [ 3437.466352] bch2_fs_file_ioctl+0x2ec/0xc90 [bcachefs]<br /> [ 3437.466617] __x64_sys_ioctl+0x93/0xd0<br /> [ 3437.466791] do_syscall_64+0x42/0xf0<br /> [ 3437.466957] entry_SYSCALL_64_after_hwframe+0x6e/0x76<br /> [ 3437.467180]<br /> other info that might help us debug this:<br /> <br /> [ 3437.469670] 2 locks held by bcachefs/35533:<br /> other info that might help us debug this:<br /> <br /> [ 3437.467507] Chain exists of:<br /> sb_writers#10 --&gt; &amp;c-&gt;snapshot_create_lock --&gt; &amp;type-&gt;s_umount_key#48<br /> <br /> [ 3437.467979] Possible unsafe locking scenario:<br /> <br /> [ 3437.468223] CPU0 CPU1<br /> [ 3437.468405] ---- ----<br /> [ 3437.468585] rlock(&amp;type-&gt;s_umount_key#48);<br /> [ 3437.468758] lock(&amp;c-&gt;snapshot_create_lock);<br /> [ 3437.469030] lock(&amp;type-&gt;s_umount_key#48);<br /> [ 3437.469291] rlock(sb_writers#10);<br /> [ 3437.469434]<br /> *** DEADLOCK ***<br /> <br /> [ 3437.469<br /> ---truncated---

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/amdgpu: fix use-after-free bug<br /> <br /> The bug can be triggered by sending a single amdgpu_gem_userptr_ioctl<br /> to the AMDGPU DRM driver on any ASICs with an invalid address and size.<br /> The bug was reported by Joonkyo Jung .<br /> For example the following code:<br /> <br /> static void Syzkaller1(int fd)<br /> {<br /> struct drm_amdgpu_gem_userptr arg;<br /> int ret;<br /> <br /> arg.addr = 0xffffffffffff0000;<br /> arg.size = 0x80000000; /*2 Gb*/<br /> arg.flags = 0x7;<br /> ret = drmIoctl(fd, 0xc1186451/*amdgpu_gem_userptr_ioctl*/, &amp;arg);<br /> }<br /> <br /> Due to the address and size are not valid there is a failure in<br /> amdgpu_hmm_register-&gt;mmu_interval_notifier_insert-&gt;__mmu_interval_notifier_insert-&gt;<br /> check_shl_overflow, but we even the amdgpu_hmm_register failure we still call<br /> amdgpu_hmm_unregister into amdgpu_gem_object_free which causes access to a bad address.<br /> The following stack is below when the issue is reproduced when Kazan is enabled:<br /> <br /> [ +0.000014] Hardware name: ASUS System Product Name/ROG STRIX B550-F GAMING (WI-FI), BIOS 1401 12/03/2020<br /> [ +0.000009] RIP: 0010:mmu_interval_notifier_remove+0x327/0x340<br /> [ +0.000017] Code: ff ff 49 89 44 24 08 48 b8 00 01 00 00 00 00 ad de 4c 89 f7 49 89 47 40 48 83 c0 22 49 89 47 48 e8 ce d1 2d 01 e9 32 ff ff ff 0b e9 16 ff ff ff 4c 89 ef e8 fa 14 b3 ff e9 36 ff ff ff e8 80<br /> [ +0.000014] RSP: 0018:ffffc90002657988 EFLAGS: 00010246<br /> [ +0.000013] RAX: 0000000000000000 RBX: 1ffff920004caf35 RCX: ffffffff8160565b<br /> [ +0.000011] RDX: dffffc0000000000 RSI: 0000000000000004 RDI: ffff8881a9f78260<br /> [ +0.000010] RBP: ffffc90002657a70 R08: 0000000000000001 R09: fffff520004caf25<br /> [ +0.000010] R10: 0000000000000003 R11: ffffffff8161d1d6 R12: ffff88810e988c00<br /> [ +0.000010] R13: ffff888126fb5a00 R14: ffff88810e988c0c R15: ffff8881a9f78260<br /> [ +0.000011] FS: 00007ff9ec848540(0000) GS:ffff8883cc880000(0000) knlGS:0000000000000000<br /> [ +0.000012] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> [ +0.000010] CR2: 000055b3f7e14328 CR3: 00000001b5770000 CR4: 0000000000350ef0<br /> [ +0.000010] Call Trace:<br /> [ +0.000006] <br /> [ +0.000007] ? show_regs+0x6a/0x80<br /> [ +0.000018] ? __warn+0xa5/0x1b0<br /> [ +0.000019] ? mmu_interval_notifier_remove+0x327/0x340<br /> [ +0.000018] ? report_bug+0x24a/0x290<br /> [ +0.000022] ? handle_bug+0x46/0x90<br /> [ +0.000015] ? exc_invalid_op+0x19/0x50<br /> [ +0.000016] ? asm_exc_invalid_op+0x1b/0x20<br /> [ +0.000017] ? kasan_save_stack+0x26/0x50<br /> [ +0.000017] ? mmu_interval_notifier_remove+0x23b/0x340<br /> [ +0.000019] ? mmu_interval_notifier_remove+0x327/0x340<br /> [ +0.000019] ? mmu_interval_notifier_remove+0x23b/0x340<br /> [ +0.000020] ? __pfx_mmu_interval_notifier_remove+0x10/0x10<br /> [ +0.000017] ? kasan_save_alloc_info+0x1e/0x30<br /> [ +0.000018] ? srso_return_thunk+0x5/0x5f<br /> [ +0.000014] ? __kasan_kmalloc+0xb1/0xc0<br /> [ +0.000018] ? srso_return_thunk+0x5/0x5f<br /> [ +0.000013] ? __kasan_check_read+0x11/0x20<br /> [ +0.000020] amdgpu_hmm_unregister+0x34/0x50 [amdgpu]<br /> [ +0.004695] amdgpu_gem_object_free+0x66/0xa0 [amdgpu]<br /> [ +0.004534] ? __pfx_amdgpu_gem_object_free+0x10/0x10 [amdgpu]<br /> [ +0.004291] ? do_syscall_64+0x5f/0xe0<br /> [ +0.000023] ? srso_return_thunk+0x5/0x5f<br /> [ +0.000017] drm_gem_object_free+0x3b/0x50 [drm]<br /> [ +0.000489] amdgpu_gem_userptr_ioctl+0x306/0x500 [amdgpu]<br /> [ +0.004295] ? __pfx_amdgpu_gem_userptr_ioctl+0x10/0x10 [amdgpu]<br /> [ +0.004270] ? srso_return_thunk+0x5/0x5f<br /> [ +0.000014] ? __this_cpu_preempt_check+0x13/0x20<br /> [ +0.000015] ? srso_return_thunk+0x5/0x5f<br /> [ +0.000013] ? sysvec_apic_timer_interrupt+0x57/0xc0<br /> [ +0.000020] ? srso_return_thunk+0x5/0x5f<br /> [ +0.000014] ? asm_sysvec_apic_timer_interrupt+0x1b/0x20<br /> [ +0.000022] ? drm_ioctl_kernel+0x17b/0x1f0 [drm]<br /> [ +0.000496] ? __pfx_amdgpu_gem_userptr_ioctl+0x10/0x10 [amdgpu]<br /> [ +0.004272] ? drm_ioctl_kernel+0x190/0x1f0 [drm]<br /> [ +0.000492] drm_ioctl_kernel+0x140/0x1f0 [drm]<br /> [ +0.000497] ? __pfx_amdgpu_gem_userptr_ioctl+0x10/0x10 [amdgpu]<br /> [ +0.004297] ? __pfx_drm_ioctl_kernel+0x10/0x10 [d<br /> ---truncated---

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> xhci: handle isoc Babble and Buffer Overrun events properly<br /> <br /> xHCI 4.9 explicitly forbids assuming that the xHC has released its<br /> ownership of a multi-TRB TD when it reports an error on one of the<br /> early TRBs. Yet the driver makes such assumption and releases the TD,<br /> allowing the remaining TRBs to be freed or overwritten by new TDs.<br /> <br /> The xHC should also report completion of the final TRB due to its IOC<br /> flag being set by us, regardless of prior errors. This event cannot<br /> be recognized if the TD has already been freed earlier, resulting in<br /> "Transfer event TRB DMA ptr not part of current TD" error message.<br /> <br /> Fix this by reusing the logic for processing isoc Transaction Errors.<br /> This also handles hosts which fail to report the final completion.<br /> <br /> Fix transfer length reporting on Babble errors. They may be caused by<br /> device malfunction, no guarantee that the buffer has been filled.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/amdkfd: Fix lock dependency warning with srcu<br /> <br /> ======================================================<br /> WARNING: possible circular locking dependency detected<br /> 6.5.0-kfd-yangp #2289 Not tainted<br /> ------------------------------------------------------<br /> kworker/0:2/996 is trying to acquire lock:<br /> (srcu){.+.+}-{0:0}, at: __synchronize_srcu+0x5/0x1a0<br /> <br /> but task is already holding lock:<br /> ((work_completion)(&amp;svms-&gt;deferred_list_work)){+.+.}-{0:0}, at:<br /> process_one_work+0x211/0x560<br /> <br /> which lock already depends on the new lock.<br /> <br /> the existing dependency chain (in reverse order) is:<br /> <br /> -&gt; #3 ((work_completion)(&amp;svms-&gt;deferred_list_work)){+.+.}-{0:0}:<br /> __flush_work+0x88/0x4f0<br /> svm_range_list_lock_and_flush_work+0x3d/0x110 [amdgpu]<br /> svm_range_set_attr+0xd6/0x14c0 [amdgpu]<br /> kfd_ioctl+0x1d1/0x630 [amdgpu]<br /> __x64_sys_ioctl+0x88/0xc0<br /> <br /> -&gt; #2 (&amp;info-&gt;lock#2){+.+.}-{3:3}:<br /> __mutex_lock+0x99/0xc70<br /> amdgpu_amdkfd_gpuvm_restore_process_bos+0x54/0x740 [amdgpu]<br /> restore_process_helper+0x22/0x80 [amdgpu]<br /> restore_process_worker+0x2d/0xa0 [amdgpu]<br /> process_one_work+0x29b/0x560<br /> worker_thread+0x3d/0x3d0<br /> <br /> -&gt; #1 ((work_completion)(&amp;(&amp;process-&gt;restore_work)-&gt;work)){+.+.}-{0:0}:<br /> __flush_work+0x88/0x4f0<br /> __cancel_work_timer+0x12c/0x1c0<br /> kfd_process_notifier_release_internal+0x37/0x1f0 [amdgpu]<br /> __mmu_notifier_release+0xad/0x240<br /> exit_mmap+0x6a/0x3a0<br /> mmput+0x6a/0x120<br /> do_exit+0x322/0xb90<br /> do_group_exit+0x37/0xa0<br /> __x64_sys_exit_group+0x18/0x20<br /> do_syscall_64+0x38/0x80<br /> <br /> -&gt; #0 (srcu){.+.+}-{0:0}:<br /> __lock_acquire+0x1521/0x2510<br /> lock_sync+0x5f/0x90<br /> __synchronize_srcu+0x4f/0x1a0<br /> __mmu_notifier_release+0x128/0x240<br /> exit_mmap+0x6a/0x3a0<br /> mmput+0x6a/0x120<br /> svm_range_deferred_list_work+0x19f/0x350 [amdgpu]<br /> process_one_work+0x29b/0x560<br /> worker_thread+0x3d/0x3d0<br /> <br /> other info that might help us debug this:<br /> Chain exists of:<br /> srcu --&gt; &amp;info-&gt;lock#2 --&gt; (work_completion)(&amp;svms-&gt;deferred_list_work)<br /> <br /> Possible unsafe locking scenario:<br /> <br /> CPU0 CPU1<br /> ---- ----<br /> lock((work_completion)(&amp;svms-&gt;deferred_list_work));<br /> lock(&amp;info-&gt;lock#2);<br /> lock((work_completion)(&amp;svms-&gt;deferred_list_work));<br /> sync(srcu);