Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> nfs: fix panic when nfs4_ff_layout_prepare_ds() fails<br /> <br /> We&amp;#39;ve been seeing the following panic in production<br /> <br /> BUG: kernel NULL pointer dereference, address: 0000000000000065<br /> PGD 2f485f067 P4D 2f485f067 PUD 2cc5d8067 PMD 0<br /> RIP: 0010:ff_layout_cancel_io+0x3a/0x90 [nfs_layout_flexfiles]<br /> Call Trace:<br /> <br /> ? __die+0x78/0xc0<br /> ? page_fault_oops+0x286/0x380<br /> ? __rpc_execute+0x2c3/0x470 [sunrpc]<br /> ? rpc_new_task+0x42/0x1c0 [sunrpc]<br /> ? exc_page_fault+0x5d/0x110<br /> ? asm_exc_page_fault+0x22/0x30<br /> ? ff_layout_free_layoutreturn+0x110/0x110 [nfs_layout_flexfiles]<br /> ? ff_layout_cancel_io+0x3a/0x90 [nfs_layout_flexfiles]<br /> ? ff_layout_cancel_io+0x6f/0x90 [nfs_layout_flexfiles]<br /> pnfs_mark_matching_lsegs_return+0x1b0/0x360 [nfsv4]<br /> pnfs_error_mark_layout_for_return+0x9e/0x110 [nfsv4]<br /> ? ff_layout_send_layouterror+0x50/0x160 [nfs_layout_flexfiles]<br /> nfs4_ff_layout_prepare_ds+0x11f/0x290 [nfs_layout_flexfiles]<br /> ff_layout_pg_init_write+0xf0/0x1f0 [nfs_layout_flexfiles]<br /> __nfs_pageio_add_request+0x154/0x6c0 [nfs]<br /> nfs_pageio_add_request+0x26b/0x380 [nfs]<br /> nfs_do_writepage+0x111/0x1e0 [nfs]<br /> nfs_writepages_callback+0xf/0x30 [nfs]<br /> write_cache_pages+0x17f/0x380<br /> ? nfs_pageio_init_write+0x50/0x50 [nfs]<br /> ? nfs_writepages+0x6d/0x210 [nfs]<br /> ? nfs_writepages+0x6d/0x210 [nfs]<br /> nfs_writepages+0x125/0x210 [nfs]<br /> do_writepages+0x67/0x220<br /> ? generic_perform_write+0x14b/0x210<br /> filemap_fdatawrite_wbc+0x5b/0x80<br /> file_write_and_wait_range+0x6d/0xc0<br /> nfs_file_fsync+0x81/0x170 [nfs]<br /> ? nfs_file_mmap+0x60/0x60 [nfs]<br /> __x64_sys_fsync+0x53/0x90<br /> do_syscall_64+0x3d/0x90<br /> entry_SYSCALL_64_after_hwframe+0x46/0xb0<br /> <br /> Inspecting the core with drgn I was able to pull this<br /> <br /> &gt;&gt;&gt; prog.crashed_thread().stack_trace()[0]<br /> #0 at 0xffffffffa079657a (ff_layout_cancel_io+0x3a/0x84) in ff_layout_cancel_io at fs/nfs/flexfilelayout/flexfilelayout.c:2021:27<br /> &gt;&gt;&gt; prog.crashed_thread().stack_trace()[0][&amp;#39;idx&amp;#39;]<br /> (u32)1<br /> &gt;&gt;&gt; prog.crashed_thread().stack_trace()[0][&amp;#39;flseg&amp;#39;].mirror_array[1].mirror_ds<br /> (struct nfs4_ff_layout_ds *)0xffffffffffffffed<br /> <br /> This is clear from the stack trace, we call nfs4_ff_layout_prepare_ds()<br /> which could error out initializing the mirror_ds, and then we go to<br /> clean it all up and our check is only for if (!mirror-&gt;mirror_ds). This<br /> is inconsistent with the rest of the users of mirror_ds, which have<br /> <br /> if (IS_ERR_OR_NULL(mirror_ds))<br /> <br /> to keep from tripping over this exact scenario. Fix this up in<br /> ff_layout_cancel_io() to make sure we don&amp;#39;t panic when we get an error.<br /> I also spot checked all the other instances of checking mirror_ds and we<br /> appear to be doing the correct checks everywhere, only unconditionally<br /> dereferencing mirror_ds when we know it would be valid.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> f2fs: fix to truncate meta inode pages forcely<br /> <br /> Below race case can cause data corruption:<br /> <br /> Thread A GC thread<br /> - gc_data_segment<br /> - ra_data_block<br /> - locked meta_inode page<br /> - f2fs_inplace_write_data<br /> - invalidate_mapping_pages<br /> : fail to invalidate meta_inode page<br /> due to lock failure or dirty|writeback<br /> status<br /> - f2fs_submit_page_bio<br /> : write last dirty data to old blkaddr<br /> - move_data_block<br /> - load old data from meta_inode page<br /> - f2fs_submit_page_write<br /> : write old data to new blkaddr<br /> <br /> Because invalidate_mapping_pages() will skip invalidating page which<br /> has unclear status including locked, dirty, writeback and so on, so<br /> we need to use truncate_inode_pages_range() instead of<br /> invalidate_mapping_pages() to make sure meta_inode page will be dropped.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> NFSv4.2: fix nfs4_listxattr kernel BUG at mm/usercopy.c:102<br /> <br /> A call to listxattr() with a buffer size = 0 returns the actual<br /> size of the buffer needed for a subsequent call. When size &gt; 0,<br /> nfs4_listxattr() does not return an error because either<br /> generic_listxattr() or nfs4_listxattr_nfs4_label() consumes<br /> exactly all the bytes then size is 0 when calling<br /> nfs4_listxattr_nfs4_user() which then triggers the following<br /> kernel BUG:<br /> <br /> [ 99.403778] kernel BUG at mm/usercopy.c:102!<br /> [ 99.404063] Internal error: Oops - BUG: 00000000f2000800 [#1] SMP<br /> [ 99.408463] CPU: 0 PID: 3310 Comm: python3 Not tainted 6.6.0-61.fc40.aarch64 #1<br /> [ 99.415827] Call trace:<br /> [ 99.415985] usercopy_abort+0x70/0xa0<br /> [ 99.416227] __check_heap_object+0x134/0x158<br /> [ 99.416505] check_heap_object+0x150/0x188<br /> [ 99.416696] __check_object_size.part.0+0x78/0x168<br /> [ 99.416886] __check_object_size+0x28/0x40<br /> [ 99.417078] listxattr+0x8c/0x120<br /> [ 99.417252] path_listxattr+0x78/0xe0<br /> [ 99.417476] __arm64_sys_listxattr+0x28/0x40<br /> [ 99.417723] invoke_syscall+0x78/0x100<br /> [ 99.417929] el0_svc_common.constprop.0+0x48/0xf0<br /> [ 99.418186] do_el0_svc+0x24/0x38<br /> [ 99.418376] el0_svc+0x3c/0x110<br /> [ 99.418554] el0t_64_sync_handler+0x120/0x130<br /> [ 99.418788] el0t_64_sync+0x194/0x198<br /> [ 99.418994] Code: aa0003e3 d000a3e0 91310000 97f49bdb (d4210000)<br /> <br /> Issue is reproduced when generic_listxattr() returns &amp;#39;system.nfs4_acl&amp;#39;,<br /> thus calling lisxattr() with size = 16 will trigger the bug.<br /> <br /> Add check on nfs4_listxattr() to return ERANGE error when it is<br /> called with size &gt; 0 and the return value is greater than size.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> f2fs: fix NULL pointer dereference in f2fs_submit_page_write()<br /> <br /> BUG: kernel NULL pointer dereference, address: 0000000000000014<br /> RIP: 0010:f2fs_submit_page_write+0x6cf/0x780 [f2fs]<br /> Call Trace:<br /> <br /> ? show_regs+0x6e/0x80<br /> ? __die+0x29/0x70<br /> ? page_fault_oops+0x154/0x4a0<br /> ? prb_read_valid+0x20/0x30<br /> ? __irq_work_queue_local+0x39/0xd0<br /> ? irq_work_queue+0x36/0x70<br /> ? do_user_addr_fault+0x314/0x6c0<br /> ? exc_page_fault+0x7d/0x190<br /> ? asm_exc_page_fault+0x2b/0x30<br /> ? f2fs_submit_page_write+0x6cf/0x780 [f2fs]<br /> ? f2fs_submit_page_write+0x736/0x780 [f2fs]<br /> do_write_page+0x50/0x170 [f2fs]<br /> f2fs_outplace_write_data+0x61/0xb0 [f2fs]<br /> f2fs_do_write_data_page+0x3f8/0x660 [f2fs]<br /> f2fs_write_single_data_page+0x5bb/0x7a0 [f2fs]<br /> f2fs_write_cache_pages+0x3da/0xbe0 [f2fs]<br /> ...<br /> It is possible that other threads have added this fio to io-&gt;bio<br /> and submitted the io-&gt;bio before entering f2fs_submit_page_write().<br /> At this point io-&gt;bio = NULL.<br /> If is_end_zone_blkaddr(sbi, fio-&gt;new_blkaddr) of this fio is true,<br /> then an NULL pointer dereference error occurs at bio_get(io-&gt;bio).<br /> The original code for determining zone end was after "out:",<br /> which would have missed some fio who is zone end. I&amp;#39;ve moved<br /> this code before "skip:" to make sure it&amp;#39;s done for each fio.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> RDMA/srpt: Do not register event handler until srpt device is fully setup<br /> <br /> Upon rare occasions, KASAN reports a use-after-free Write<br /> in srpt_refresh_port().<br /> <br /> This seems to be because an event handler is registered before the<br /> srpt device is fully setup and a race condition upon error may leave a<br /> partially setup event handler in place.<br /> <br /> Instead, only register the event handler after srpt device initialization<br /> is complete.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> scsi: hisi_sas: Fix a deadlock issue related to automatic dump<br /> <br /> If we issue a disabling PHY command, the device attached with it will go<br /> offline, if a 2 bit ECC error occurs at the same time, a hung task may be<br /> found:<br /> <br /> [ 4613.652388] INFO: task kworker/u256:0:165233 blocked for more than 120 seconds.<br /> [ 4613.666297] "echo 0 &gt; /proc/sys/kernel/hung_task_timeout_secs" disables this message.<br /> [ 4613.674809] task:kworker/u256:0 state:D stack: 0 pid:165233 ppid: 2 flags:0x00000208<br /> [ 4613.683959] Workqueue: 0000:74:02.0_disco_q sas_revalidate_domain [libsas]<br /> [ 4613.691518] Call trace:<br /> [ 4613.694678] __switch_to+0xf8/0x17c<br /> [ 4613.698872] __schedule+0x660/0xee0<br /> [ 4613.703063] schedule+0xac/0x240<br /> [ 4613.706994] schedule_timeout+0x500/0x610<br /> [ 4613.711705] __down+0x128/0x36c<br /> [ 4613.715548] down+0x240/0x2d0<br /> [ 4613.719221] hisi_sas_internal_abort_timeout+0x1bc/0x260 [hisi_sas_main]<br /> [ 4613.726618] sas_execute_internal_abort+0x144/0x310 [libsas]<br /> [ 4613.732976] sas_execute_internal_abort_dev+0x44/0x60 [libsas]<br /> [ 4613.739504] hisi_sas_internal_task_abort_dev.isra.0+0xbc/0x1b0 [hisi_sas_main]<br /> [ 4613.747499] hisi_sas_dev_gone+0x174/0x250 [hisi_sas_main]<br /> [ 4613.753682] sas_notify_lldd_dev_gone+0xec/0x2e0 [libsas]<br /> [ 4613.759781] sas_unregister_common_dev+0x4c/0x7a0 [libsas]<br /> [ 4613.765962] sas_destruct_devices+0xb8/0x120 [libsas]<br /> [ 4613.771709] sas_do_revalidate_domain.constprop.0+0x1b8/0x31c [libsas]<br /> [ 4613.778930] sas_revalidate_domain+0x60/0xa4 [libsas]<br /> [ 4613.784716] process_one_work+0x248/0x950<br /> [ 4613.789424] worker_thread+0x318/0x934<br /> [ 4613.793878] kthread+0x190/0x200<br /> [ 4613.797810] ret_from_fork+0x10/0x18<br /> [ 4613.802121] INFO: task kworker/u256:4:316722 blocked for more than 120 seconds.<br /> [ 4613.816026] "echo 0 &gt; /proc/sys/kernel/hung_task_timeout_secs" disables this message.<br /> [ 4613.824538] task:kworker/u256:4 state:D stack: 0 pid:316722 ppid: 2 flags:0x00000208<br /> [ 4613.833670] Workqueue: 0000:74:02.0 hisi_sas_rst_work_handler [hisi_sas_main]<br /> [ 4613.841491] Call trace:<br /> [ 4613.844647] __switch_to+0xf8/0x17c<br /> [ 4613.848852] __schedule+0x660/0xee0<br /> [ 4613.853052] schedule+0xac/0x240<br /> [ 4613.856984] schedule_timeout+0x500/0x610<br /> [ 4613.861695] __down+0x128/0x36c<br /> [ 4613.865542] down+0x240/0x2d0<br /> [ 4613.869216] hisi_sas_controller_prereset+0x58/0x1fc [hisi_sas_main]<br /> [ 4613.876324] hisi_sas_rst_work_handler+0x40/0x8c [hisi_sas_main]<br /> [ 4613.883019] process_one_work+0x248/0x950<br /> [ 4613.887732] worker_thread+0x318/0x934<br /> [ 4613.892204] kthread+0x190/0x200<br /> [ 4613.896118] ret_from_fork+0x10/0x18<br /> [ 4613.900423] INFO: task kworker/u256:1:348985 blocked for more than 121 seconds.<br /> [ 4613.914341] "echo 0 &gt; /proc/sys/kernel/hung_task_timeout_secs" disables this message.<br /> [ 4613.922852] task:kworker/u256:1 state:D stack: 0 pid:348985 ppid: 2 flags:0x00000208<br /> [ 4613.931984] Workqueue: 0000:74:02.0_event_q sas_port_event_worker [libsas]<br /> [ 4613.939549] Call trace:<br /> [ 4613.942702] __switch_to+0xf8/0x17c<br /> [ 4613.946892] __schedule+0x660/0xee0<br /> [ 4613.951083] schedule+0xac/0x240<br /> [ 4613.955015] schedule_timeout+0x500/0x610<br /> [ 4613.959725] wait_for_common+0x200/0x610<br /> [ 4613.964349] wait_for_completion+0x3c/0x5c<br /> [ 4613.969146] flush_workqueue+0x198/0x790<br /> [ 4613.973776] sas_porte_broadcast_rcvd+0x1e8/0x320 [libsas]<br /> [ 4613.979960] sas_port_event_worker+0x54/0xa0 [libsas]<br /> [ 4613.985708] process_one_work+0x248/0x950<br /> [ 4613.990420] worker_thread+0x318/0x934<br /> [ 4613.994868] kthread+0x190/0x200<br /> [ 4613.998800] ret_from_fork+0x10/0x18<br /> <br /> This is because when the device goes offline, we obtain the hisi_hba<br /> semaphore and send the ABORT_DEV command to the device. However, the<br /> internal abort timed out due to the 2 bit ECC error and triggers automatic<br /> dump. In addition, since the hisi_hba semaphore has been obtained, the dump<br /> cannot be executed and the controller cannot be reset.<br /> <br /> Therefore, the deadlocks occur on the following circular dependencies<br /> ---truncated---

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/mediatek: Fix a null pointer crash in mtk_drm_crtc_finish_page_flip<br /> <br /> It&amp;#39;s possible that mtk_crtc-&gt;event is NULL in<br /> mtk_drm_crtc_finish_page_flip().<br /> <br /> pending_needs_vblank value is set by mtk_crtc-&gt;event, but in<br /> mtk_drm_crtc_atomic_flush(), it&amp;#39;s is not guarded by the same<br /> lock in mtk_drm_finish_page_flip(), thus a race condition happens.<br /> <br /> Consider the following case:<br /> <br /> CPU1 CPU2<br /> step 1:<br /> mtk_drm_crtc_atomic_begin()<br /> mtk_crtc-&gt;event is not null,<br /> step 1:<br /> mtk_drm_crtc_atomic_flush:<br /> mtk_drm_crtc_update_config(<br /> !!mtk_crtc-&gt;event)<br /> step 2:<br /> mtk_crtc_ddp_irq -&gt;<br /> mtk_drm_finish_page_flip:<br /> lock<br /> mtk_crtc-&gt;event set to null,<br /> pending_needs_vblank set to false<br /> unlock<br /> pending_needs_vblank set to true,<br /> <br /> step 2:<br /> mtk_crtc_ddp_irq -&gt;<br /> mtk_drm_finish_page_flip called again,<br /> pending_needs_vblank is still true<br /> //null pointer<br /> <br /> Instead of guarding the entire mtk_drm_crtc_atomic_flush(), it&amp;#39;s more<br /> efficient to just check if mtk_crtc-&gt;event is null before use.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> media: pvrusb2: fix uaf in pvr2_context_set_notify<br /> <br /> [Syzbot reported]<br /> BUG: KASAN: slab-use-after-free in pvr2_context_set_notify+0x2c4/0x310 drivers/media/usb/pvrusb2/pvrusb2-context.c:35<br /> Read of size 4 at addr ffff888113aeb0d8 by task kworker/1:1/26<br /> <br /> CPU: 1 PID: 26 Comm: kworker/1:1 Not tainted 6.8.0-rc1-syzkaller-00046-gf1a27f081c1f #0<br /> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/25/2024<br /> Workqueue: usb_hub_wq hub_event<br /> Call Trace:<br /> <br /> __dump_stack lib/dump_stack.c:88 [inline]<br /> dump_stack_lvl+0xd9/0x1b0 lib/dump_stack.c:106<br /> print_address_description mm/kasan/report.c:377 [inline]<br /> print_report+0xc4/0x620 mm/kasan/report.c:488<br /> kasan_report+0xda/0x110 mm/kasan/report.c:601<br /> pvr2_context_set_notify+0x2c4/0x310 drivers/media/usb/pvrusb2/pvrusb2-context.c:35<br /> pvr2_context_notify drivers/media/usb/pvrusb2/pvrusb2-context.c:95 [inline]<br /> pvr2_context_disconnect+0x94/0xb0 drivers/media/usb/pvrusb2/pvrusb2-context.c:272<br /> <br /> Freed by task 906:<br /> kasan_save_stack+0x33/0x50 mm/kasan/common.c:47<br /> kasan_save_track+0x14/0x30 mm/kasan/common.c:68<br /> kasan_save_free_info+0x3f/0x60 mm/kasan/generic.c:640<br /> poison_slab_object mm/kasan/common.c:241 [inline]<br /> __kasan_slab_free+0x106/0x1b0 mm/kasan/common.c:257<br /> kasan_slab_free include/linux/kasan.h:184 [inline]<br /> slab_free_hook mm/slub.c:2121 [inline]<br /> slab_free mm/slub.c:4299 [inline]<br /> kfree+0x105/0x340 mm/slub.c:4409<br /> pvr2_context_check drivers/media/usb/pvrusb2/pvrusb2-context.c:137 [inline]<br /> pvr2_context_thread_func+0x69d/0x960 drivers/media/usb/pvrusb2/pvrusb2-context.c:158<br /> <br /> [Analyze]<br /> Task A set disconnect_flag = !0, which resulted in Task B&amp;#39;s condition being met<br /> and releasing mp, leading to this issue.<br /> <br /> [Fix]<br /> Place the disconnect_flag assignment operation after all code in pvr2_context_disconnect()<br /> to avoid this issue.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> crypto: xilinx - call finalize with bh disabled<br /> <br /> When calling crypto_finalize_request, BH should be disabled to avoid<br /> triggering the following calltrace:<br /> <br /> ------------[ cut here ]------------<br /> WARNING: CPU: 2 PID: 74 at crypto/crypto_engine.c:58 crypto_finalize_request+0xa0/0x118<br /> Modules linked in: cryptodev(O)<br /> CPU: 2 PID: 74 Comm: firmware:zynqmp Tainted: G O 6.8.0-rc1-yocto-standard #323<br /> Hardware name: ZynqMP ZCU102 Rev1.0 (DT)<br /> pstate: 40000005 (nZcv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)<br /> pc : crypto_finalize_request+0xa0/0x118<br /> lr : crypto_finalize_request+0x104/0x118<br /> sp : ffffffc085353ce0<br /> x29: ffffffc085353ce0 x28: 0000000000000000 x27: ffffff8808ea8688<br /> x26: ffffffc081715038 x25: 0000000000000000 x24: ffffff880100db00<br /> x23: ffffff880100da80 x22: 0000000000000000 x21: 0000000000000000<br /> x20: ffffff8805b14000 x19: ffffff880100da80 x18: 0000000000010450<br /> x17: 0000000000000000 x16: 0000000000000000 x15: 0000000000000000<br /> x14: 0000000000000003 x13: 0000000000000000 x12: ffffff880100dad0<br /> x11: 0000000000000000 x10: ffffffc0832dcd08 x9 : ffffffc0812416d8<br /> x8 : 00000000000001f4 x7 : ffffffc0830d2830 x6 : 0000000000000001<br /> x5 : ffffffc082091000 x4 : ffffffc082091658 x3 : 0000000000000000<br /> x2 : ffffffc7f9653000 x1 : 0000000000000000 x0 : ffffff8802d20000<br /> Call trace:<br /> crypto_finalize_request+0xa0/0x118<br /> crypto_finalize_aead_request+0x18/0x30<br /> zynqmp_handle_aes_req+0xcc/0x388<br /> crypto_pump_work+0x168/0x2d8<br /> kthread_worker_fn+0xfc/0x3a0<br /> kthread+0x118/0x138<br /> ret_from_fork+0x10/0x20<br /> irq event stamp: 40<br /> hardirqs last enabled at (39): [] _raw_spin_unlock_irqrestore+0x70/0xb0<br /> hardirqs last disabled at (40): [] el1_dbg+0x28/0x90<br /> softirqs last enabled at (36): [] kernel_neon_begin+0x8c/0xf0<br /> softirqs last disabled at (34): [] kernel_neon_begin+0x60/0xf0<br /> ---[ end trace 0000000000000000 ]---

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> dm: call the resume method on internal suspend<br /> <br /> There is this reported crash when experimenting with the lvm2 testsuite.<br /> The list corruption is caused by the fact that the postsuspend and resume<br /> methods were not paired correctly; there were two consecutive calls to the<br /> origin_postsuspend function. The second call attempts to remove the<br /> "hash_list" entry from a list, while it was already removed by the first<br /> call.<br /> <br /> Fix __dm_internal_resume so that it calls the preresume and resume<br /> methods of the table&amp;#39;s targets.<br /> <br /> If a preresume method of some target fails, we are in a tricky situation.<br /> We can&amp;#39;t return an error because dm_internal_resume isn&amp;#39;t supposed to<br /> return errors. We can&amp;#39;t return success, because then the "resume" and<br /> "postsuspend" methods would not be paired correctly. So, we set the<br /> DMF_SUSPENDED flag and we fake normal suspend - it may confuse userspace<br /> tools, but it won&amp;#39;t cause a kernel crash.<br /> <br /> ------------[ cut here ]------------<br /> kernel BUG at lib/list_debug.c:56!<br /> invalid opcode: 0000 [#1] PREEMPT SMP<br /> CPU: 1 PID: 8343 Comm: dmsetup Not tainted 6.8.0-rc6 #4<br /> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.14.0-2 04/01/2014<br /> RIP: 0010:__list_del_entry_valid_or_report+0x77/0xc0<br /> <br /> RSP: 0018:ffff8881b831bcc0 EFLAGS: 00010282<br /> RAX: 000000000000004e RBX: ffff888143b6eb80 RCX: 0000000000000000<br /> RDX: 0000000000000001 RSI: ffffffff819053d0 RDI: 00000000ffffffff<br /> RBP: ffff8881b83a3400 R08: 00000000fffeffff R09: 0000000000000058<br /> R10: 0000000000000000 R11: ffffffff81a24080 R12: 0000000000000001<br /> R13: ffff88814538e000 R14: ffff888143bc6dc0 R15: ffffffffa02e4bb0<br /> FS: 00000000f7c0f780(0000) GS:ffff8893f0a40000(0000) knlGS:0000000000000000<br /> CS: 0010 DS: 002b ES: 002b CR0: 0000000080050033<br /> CR2: 0000000057fb5000 CR3: 0000000143474000 CR4: 00000000000006b0<br /> Call Trace:<br /> <br /> ? die+0x2d/0x80<br /> ? do_trap+0xeb/0xf0<br /> ? __list_del_entry_valid_or_report+0x77/0xc0<br /> ? do_error_trap+0x60/0x80<br /> ? __list_del_entry_valid_or_report+0x77/0xc0<br /> ? exc_invalid_op+0x49/0x60<br /> ? __list_del_entry_valid_or_report+0x77/0xc0<br /> ? asm_exc_invalid_op+0x16/0x20<br /> ? table_deps+0x1b0/0x1b0 [dm_mod]<br /> ? __list_del_entry_valid_or_report+0x77/0xc0<br /> origin_postsuspend+0x1a/0x50 [dm_snapshot]<br /> dm_table_postsuspend_targets+0x34/0x50 [dm_mod]<br /> dm_suspend+0xd8/0xf0 [dm_mod]<br /> dev_suspend+0x1f2/0x2f0 [dm_mod]<br /> ? table_deps+0x1b0/0x1b0 [dm_mod]<br /> ctl_ioctl+0x300/0x5f0 [dm_mod]<br /> dm_compat_ctl_ioctl+0x7/0x10 [dm_mod]<br /> __x64_compat_sys_ioctl+0x104/0x170<br /> do_syscall_64+0x184/0x1b0<br /> entry_SYSCALL_64_after_hwframe+0x46/0x4e<br /> RIP: 0033:0xf7e6aead<br /> <br /> ---[ end trace 0000000000000000 ]---

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> wifi: b43: Stop/wake correct queue in DMA Tx path when QoS is disabled<br /> <br /> When QoS is disabled, the queue priority value will not map to the correct<br /> ieee80211 queue since there is only one queue. Stop/wake queue 0 when QoS<br /> is disabled to prevent trying to stop/wake a non-existent queue and failing<br /> to stop/wake the actual queue instantiated.<br /> <br /> Log of issue before change (with kernel parameter qos=0):<br /> [ +5.112651] ------------[ cut here ]------------<br /> [ +0.000005] WARNING: CPU: 7 PID: 25513 at net/mac80211/util.c:449 __ieee80211_wake_queue+0xd5/0x180 [mac80211]<br /> [ +0.000067] Modules linked in: b43(O) snd_seq_dummy snd_hrtimer snd_seq snd_seq_device nft_chain_nat xt_MASQUERADE nf_nat xfrm_user xfrm_algo xt_addrtype overlay ccm af_packet amdgpu snd_hda_codec_cirrus snd_hda_codec_generic ledtrig_audio drm_exec amdxcp gpu_sched xt_conntrack nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 ip6t_rpfilter ipt_rpfilter xt_pkttype xt_LOG nf_log_syslog xt_tcpudp nft_compat nf_tables nfnetlink sch_fq_codel btusb uinput iTCO_wdt ctr btrtl intel_pmc_bxt i915 intel_rapl_msr mei_hdcp mei_pxp joydev at24 watchdog btintel atkbd libps2 serio radeon btbcm vivaldi_fmap btmtk intel_rapl_common snd_hda_codec_hdmi bluetooth uvcvideo nls_iso8859_1 applesmc nls_cp437 x86_pkg_temp_thermal snd_hda_intel intel_powerclamp vfat videobuf2_vmalloc coretemp fat snd_intel_dspcfg crc32_pclmul uvc polyval_clmulni snd_intel_sdw_acpi loop videobuf2_memops snd_hda_codec tun drm_suballoc_helper polyval_generic drm_ttm_helper drm_buddy tap ecdh_generic videobuf2_v4l2 gf128mul macvlan ttm ghash_clmulni_intel ecc tg3<br /> [ +0.000044] videodev bridge snd_hda_core rapl crc16 drm_display_helper cec mousedev snd_hwdep evdev intel_cstate bcm5974 hid_appleir videobuf2_common stp mac_hid libphy snd_pcm drm_kms_helper acpi_als mei_me intel_uncore llc mc snd_timer intel_gtt industrialio_triggered_buffer apple_mfi_fastcharge i2c_i801 mei snd lpc_ich agpgart ptp i2c_smbus thunderbolt apple_gmux i2c_algo_bit kfifo_buf video industrialio soundcore pps_core wmi tiny_power_button sbs sbshc button ac cordic bcma mac80211 cfg80211 ssb rfkill libarc4 kvm_intel kvm drm irqbypass fuse backlight firmware_class efi_pstore configfs efivarfs dmi_sysfs ip_tables x_tables autofs4 dm_crypt cbc encrypted_keys trusted asn1_encoder tee tpm rng_core input_leds hid_apple led_class hid_generic usbhid hid sd_mod t10_pi crc64_rocksoft crc64 crc_t10dif crct10dif_generic ahci libahci libata uhci_hcd ehci_pci ehci_hcd crct10dif_pclmul crct10dif_common sha512_ssse3 sha512_generic sha256_ssse3 sha1_ssse3 aesni_intel usbcore scsi_mod libaes crypto_simd cryptd scsi_common<br /> [ +0.000055] usb_common rtc_cmos btrfs blake2b_generic libcrc32c crc32c_generic crc32c_intel xor raid6_pq dm_snapshot dm_bufio dm_mod dax [last unloaded: b43(O)]<br /> [ +0.000009] CPU: 7 PID: 25513 Comm: irq/17-b43 Tainted: G W O 6.6.7 #1-NixOS<br /> [ +0.000003] Hardware name: Apple Inc. MacBookPro8,3/Mac-942459F5819B171B, BIOS 87.0.0.0.0 06/13/2019<br /> [ +0.000001] RIP: 0010:__ieee80211_wake_queue+0xd5/0x180 [mac80211]<br /> [ +0.000046] Code: 00 45 85 e4 0f 85 9b 00 00 00 48 8d bd 40 09 00 00 f0 48 0f ba ad 48 09 00 00 00 72 0f 5b 5d 41 5c 41 5d 41 5e e9 cb 6d 3c d0 0b 5b 5d 41 5c 41 5d 41 5e c3 cc cc cc cc 48 8d b4 16 94 00 00<br /> [ +0.000002] RSP: 0018:ffffc90003c77d60 EFLAGS: 00010097<br /> [ +0.000001] RAX: 0000000000000001 RBX: 0000000000000002 RCX: 0000000000000000<br /> [ +0.000001] RDX: 0000000000000000 RSI: 0000000000000002 RDI: ffff88820b924900<br /> [ +0.000002] RBP: ffff88820b924900 R08: ffffc90003c77d90 R09: 000000000003bfd0<br /> [ +0.000001] R10: ffff88820b924900 R11: ffffc90003c77c68 R12: 0000000000000000<br /> [ +0.000001] R13: 0000000000000000 R14: ffffc90003c77d90 R15: ffffffffc0fa6f40<br /> [ +0.000001] FS: 0000000000000000(0000) GS:ffff88846fb80000(0000) knlGS:0000000000000000<br /> [ +0.000001] CS: 0010 DS: 0<br /> ---truncated---

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> powerpc/rtas: use correct function name for resetting TCE tables<br /> <br /> The PAPR spec spells the function name as<br /> <br /> "ibm,reset-pe-dma-windows"<br /> <br /> but in practice firmware uses the singular form:<br /> <br /> "ibm,reset-pe-dma-window"<br /> <br /> in the device tree. Since we have the wrong spelling in the RTAS<br /> function table, reverse lookups (token -&gt; name) fail and warn:<br /> <br /> unexpected failed lookup for token 86<br /> WARNING: CPU: 1 PID: 545 at arch/powerpc/kernel/rtas.c:659 __do_enter_rtas_trace+0x2a4/0x2b4<br /> CPU: 1 PID: 545 Comm: systemd-udevd Not tainted 6.8.0-rc4 #30<br /> Hardware name: IBM,9105-22A POWER10 (raw) 0x800200 0xf000006 of:IBM,FW1060.00 (NL1060_028) hv:phyp pSeries<br /> NIP [c0000000000417f0] __do_enter_rtas_trace+0x2a4/0x2b4<br /> LR [c0000000000417ec] __do_enter_rtas_trace+0x2a0/0x2b4<br /> Call Trace:<br /> __do_enter_rtas_trace+0x2a0/0x2b4 (unreliable)<br /> rtas_call+0x1f8/0x3e0<br /> enable_ddw.constprop.0+0x4d0/0xc84<br /> dma_iommu_dma_supported+0xe8/0x24c<br /> dma_set_mask+0x5c/0xd8<br /> mlx5_pci_init.constprop.0+0xf0/0x46c [mlx5_core]<br /> probe_one+0xfc/0x32c [mlx5_core]<br /> local_pci_probe+0x68/0x12c<br /> pci_call_probe+0x68/0x1ec<br /> pci_device_probe+0xbc/0x1a8<br /> really_probe+0x104/0x570<br /> __driver_probe_device+0xb8/0x224<br /> driver_probe_device+0x54/0x130<br /> __driver_attach+0x158/0x2b0<br /> bus_for_each_dev+0xa8/0x120<br /> driver_attach+0x34/0x48<br /> bus_add_driver+0x174/0x304<br /> driver_register+0x8c/0x1c4<br /> __pci_register_driver+0x68/0x7c<br /> mlx5_init+0xb8/0x118 [mlx5_core]<br /> do_one_initcall+0x60/0x388<br /> do_init_module+0x7c/0x2a4<br /> init_module_from_file+0xb4/0x108<br /> idempotent_init_module+0x184/0x34c<br /> sys_finit_module+0x90/0x114<br /> <br /> And oopses are possible when lockdep is enabled or the RTAS<br /> tracepoints are active, since those paths dereference the result of<br /> the lookup.<br /> <br /> Use the correct spelling to match firmware&amp;#39;s behavior, adjusting the<br /> related constants to match.