Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> powerpc/rtas: avoid scheduling in rtas_os_term()<br /> <br /> It&amp;#39;s unsafe to use rtas_busy_delay() to handle a busy status from<br /> the ibm,os-term RTAS function in rtas_os_term():<br /> <br /> Kernel panic - not syncing: Attempted to kill init! exitcode=0x0000000b<br /> BUG: sleeping function called from invalid context at arch/powerpc/kernel/rtas.c:618<br /> in_atomic(): 1, irqs_disabled(): 1, non_block: 0, pid: 1, name: swapper/0<br /> preempt_count: 2, expected: 0<br /> CPU: 7 PID: 1 Comm: swapper/0 Tainted: G D 6.0.0-rc5-02182-gf8553a572277-dirty #9<br /> Call Trace:<br /> [c000000007b8f000] [c000000001337110] dump_stack_lvl+0xb4/0x110 (unreliable)<br /> [c000000007b8f040] [c0000000002440e4] __might_resched+0x394/0x3c0<br /> [c000000007b8f0e0] [c00000000004f680] rtas_busy_delay+0x120/0x1b0<br /> [c000000007b8f100] [c000000000052d04] rtas_os_term+0xb8/0xf4<br /> [c000000007b8f180] [c0000000001150fc] pseries_panic+0x50/0x68<br /> [c000000007b8f1f0] [c000000000036354] ppc_panic_platform_handler+0x34/0x50<br /> [c000000007b8f210] [c0000000002303c4] notifier_call_chain+0xd4/0x1c0<br /> [c000000007b8f2b0] [c0000000002306cc] atomic_notifier_call_chain+0xac/0x1c0<br /> [c000000007b8f2f0] [c0000000001d62b8] panic+0x228/0x4d0<br /> [c000000007b8f390] [c0000000001e573c] do_exit+0x140c/0x1420<br /> [c000000007b8f480] [c0000000001e586c] make_task_dead+0xdc/0x200<br /> <br /> Use rtas_busy_delay_time() instead, which signals without side effects<br /> whether to attempt the ibm,os-term RTAS call again.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> iommu/amd: Fix pci device refcount leak in ppr_notifier()<br /> <br /> As comment of pci_get_domain_bus_and_slot() says, it returns<br /> a pci device with refcount increment, when finish using it,<br /> the caller must decrement the reference count by calling<br /> pci_dev_put(). So call it before returning from ppr_notifier()<br /> to avoid refcount leak.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drbd: only clone bio if we have a backing device<br /> <br /> Commit c347a787e34cb (drbd: set -&gt;bi_bdev in drbd_req_new) moved a<br /> bio_set_dev call (which has since been removed) to "earlier", from<br /> drbd_request_prepare to drbd_req_new.<br /> <br /> The problem is that this accesses device-&gt;ldev-&gt;backing_bdev, which is<br /> not NULL-checked at this point. When we don&amp;#39;t have an ldev (i.e. when<br /> the DRBD device is diskless), this leads to a null pointer deref.<br /> <br /> So, only allocate the private_bio if we actually have a disk. This is<br /> also a small optimization, since we don&amp;#39;t clone the bio to only to<br /> immediately free it again in the diskless case.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> fs/ntfs3: Validate data run offset<br /> <br /> This adds sanity checks for data run offset. We should make sure data<br /> run offset is legit before trying to unpack them, otherwise we may<br /> encounter use-after-free or some unexpected memory access behaviors.<br /> <br /> [ 82.940342] BUG: KASAN: use-after-free in run_unpack+0x2e3/0x570<br /> [ 82.941180] Read of size 1 at addr ffff888008a8487f by task mount/240<br /> [ 82.941670]<br /> [ 82.942069] CPU: 0 PID: 240 Comm: mount Not tainted 5.19.0+ #15<br /> [ 82.942482] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.14.0-0-g155821a1990b-prebuilt.qemu.org 04/01/2014<br /> [ 82.943720] Call Trace:<br /> [ 82.944204] <br /> [ 82.944471] dump_stack_lvl+0x49/0x63<br /> [ 82.944908] print_report.cold+0xf5/0x67b<br /> [ 82.945141] ? __wait_on_bit+0x106/0x120<br /> [ 82.945750] ? run_unpack+0x2e3/0x570<br /> [ 82.946626] kasan_report+0xa7/0x120<br /> [ 82.947046] ? run_unpack+0x2e3/0x570<br /> [ 82.947280] __asan_load1+0x51/0x60<br /> [ 82.947483] run_unpack+0x2e3/0x570<br /> [ 82.947709] ? memcpy+0x4e/0x70<br /> [ 82.947927] ? run_pack+0x7a0/0x7a0<br /> [ 82.948158] run_unpack_ex+0xad/0x3f0<br /> [ 82.948399] ? mi_enum_attr+0x14a/0x200<br /> [ 82.948717] ? run_unpack+0x570/0x570<br /> [ 82.949072] ? ni_enum_attr_ex+0x1b2/0x1c0<br /> [ 82.949332] ? ni_fname_type.part.0+0xd0/0xd0<br /> [ 82.949611] ? mi_read+0x262/0x2c0<br /> [ 82.949970] ? ntfs_cmp_names_cpu+0x125/0x180<br /> [ 82.950249] ntfs_iget5+0x632/0x1870<br /> [ 82.950621] ? ntfs_get_block_bmap+0x70/0x70<br /> [ 82.951192] ? evict+0x223/0x280<br /> [ 82.951525] ? iput.part.0+0x286/0x320<br /> [ 82.951969] ntfs_fill_super+0x1321/0x1e20<br /> [ 82.952436] ? put_ntfs+0x1d0/0x1d0<br /> [ 82.952822] ? vsprintf+0x20/0x20<br /> [ 82.953188] ? mutex_unlock+0x81/0xd0<br /> [ 82.953379] ? set_blocksize+0x95/0x150<br /> [ 82.954001] get_tree_bdev+0x232/0x370<br /> [ 82.954438] ? put_ntfs+0x1d0/0x1d0<br /> [ 82.954700] ntfs_fs_get_tree+0x15/0x20<br /> [ 82.955049] vfs_get_tree+0x4c/0x130<br /> [ 82.955292] path_mount+0x645/0xfd0<br /> [ 82.955615] ? putname+0x80/0xa0<br /> [ 82.955955] ? finish_automount+0x2e0/0x2e0<br /> [ 82.956310] ? kmem_cache_free+0x110/0x390<br /> [ 82.956723] ? putname+0x80/0xa0<br /> [ 82.957023] do_mount+0xd6/0xf0<br /> [ 82.957411] ? path_mount+0xfd0/0xfd0<br /> [ 82.957638] ? __kasan_check_write+0x14/0x20<br /> [ 82.957948] __x64_sys_mount+0xca/0x110<br /> [ 82.958310] do_syscall_64+0x3b/0x90<br /> [ 82.958719] entry_SYSCALL_64_after_hwframe+0x63/0xcd<br /> [ 82.959341] RIP: 0033:0x7fd0d1ce948a<br /> [ 82.960193] Code: 48 8b 0d 11 fa 2a 00 f7 d8 64 89 01 48 83 c8 ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 49 89 ca b8 a5 00 00 008<br /> [ 82.961532] RSP: 002b:00007ffe59ff69a8 EFLAGS: 00000202 ORIG_RAX: 00000000000000a5<br /> [ 82.962527] RAX: ffffffffffffffda RBX: 0000564dcc107060 RCX: 00007fd0d1ce948a<br /> [ 82.963266] RDX: 0000564dcc107260 RSI: 0000564dcc1072e0 RDI: 0000564dcc10fce0<br /> [ 82.963686] RBP: 0000000000000000 R08: 0000564dcc107280 R09: 0000000000000020<br /> [ 82.964272] R10: 00000000c0ed0000 R11: 0000000000000202 R12: 0000564dcc10fce0<br /> [ 82.964785] R13: 0000564dcc107260 R14: 0000000000000000 R15: 00000000ffffffff

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> coresight: cti: Fix hang in cti_disable_hw()<br /> <br /> cti_enable_hw() and cti_disable_hw() are called from an atomic context<br /> so shouldn&amp;#39;t use runtime PM because it can result in a sleep when<br /> communicating with firmware.<br /> <br /> Since commit 3c6656337852 ("Revert "firmware: arm_scmi: Add clock<br /> management to the SCMI power domain""), this causes a hang on Juno when<br /> running the Perf Coresight tests or running this command:<br /> <br /> perf record -e cs_etm//u -- ls<br /> <br /> This was also missed until the revert commit because pm_runtime_put()<br /> was called with the wrong device until commit 692c9a499b28 ("coresight:<br /> cti: Correct the parameter for pm_runtime_put")<br /> <br /> With lock and scheduler debugging enabled the following is output:<br /> <br /> coresight cti_sys0: cti_enable_hw -- dev:cti_sys0 parent: 20020000.cti<br /> BUG: sleeping function called from invalid context at drivers/base/power/runtime.c:1151<br /> in_atomic(): 1, irqs_disabled(): 128, non_block: 0, pid: 330, name: perf-exec<br /> preempt_count: 2, expected: 0<br /> RCU nest depth: 0, expected: 0<br /> INFO: lockdep is turned off.<br /> irq event stamp: 0<br /> hardirqs last enabled at (0): [] 0x0<br /> hardirqs last disabled at (0): [] copy_process+0xa0c/0x1948<br /> softirqs last enabled at (0): [] copy_process+0xa0c/0x1948<br /> softirqs last disabled at (0): [] 0x0<br /> CPU: 3 PID: 330 Comm: perf-exec Not tainted 6.0.0-00053-g042116d99298 #7<br /> Hardware name: ARM LTD ARM Juno Development Platform/ARM Juno Development Platform, BIOS EDK II Sep 13 2022<br /> Call trace:<br /> dump_backtrace+0x134/0x140<br /> show_stack+0x20/0x58<br /> dump_stack_lvl+0x8c/0xb8<br /> dump_stack+0x18/0x34<br /> __might_resched+0x180/0x228<br /> __might_sleep+0x50/0x88<br /> __pm_runtime_resume+0xac/0xb0<br /> cti_enable+0x44/0x120<br /> coresight_control_assoc_ectdev+0xc0/0x150<br /> coresight_enable_path+0xb4/0x288<br /> etm_event_start+0x138/0x170<br /> etm_event_add+0x48/0x70<br /> event_sched_in.isra.122+0xb4/0x280<br /> merge_sched_in+0x1fc/0x3d0<br /> visit_groups_merge.constprop.137+0x16c/0x4b0<br /> ctx_sched_in+0x114/0x1f0<br /> perf_event_sched_in+0x60/0x90<br /> ctx_resched+0x68/0xb0<br /> perf_event_exec+0x138/0x508<br /> begin_new_exec+0x52c/0xd40<br /> load_elf_binary+0x6b8/0x17d0<br /> bprm_execve+0x360/0x7f8<br /> do_execveat_common.isra.47+0x218/0x238<br /> __arm64_sys_execve+0x48/0x60<br /> invoke_syscall+0x4c/0x110<br /> el0_svc_common.constprop.4+0xfc/0x120<br /> do_el0_svc+0x34/0xc0<br /> el0_svc+0x40/0x98<br /> el0t_64_sync_handler+0x98/0xc0<br /> el0t_64_sync+0x170/0x174<br /> <br /> Fix the issue by removing the runtime PM calls completely. They are not<br /> needed here because it must have already been done when building the<br /> path for a trace.<br /> <br /> [ Fix build warnings ]

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/msm: fix use-after-free on probe deferral<br /> <br /> The bridge counter was never reset when tearing down the DRM device so<br /> that stale pointers to deallocated structures would be accessed on the<br /> next tear down (e.g. after a second late bind deferral).<br /> <br /> Given enough bridges and a few probe deferrals this could currently also<br /> lead to data beyond the bridge array being corrupted.<br /> <br /> Patchwork: https://patchwork.freedesktop.org/patch/502665/

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> scsi: qla2xxx: Fix crash when I/O abort times out<br /> <br /> While performing CPU hotplug, a crash with the following stack was seen:<br /> <br /> Call Trace:<br /> qla24xx_process_response_queue+0x42a/0x970 [qla2xxx]<br /> qla2x00_start_nvme_mq+0x3a2/0x4b0 [qla2xxx]<br /> qla_nvme_post_cmd+0x166/0x240 [qla2xxx]<br /> nvme_fc_start_fcp_op.part.0+0x119/0x2e0 [nvme_fc]<br /> blk_mq_dispatch_rq_list+0x17b/0x610<br /> __blk_mq_sched_dispatch_requests+0xb0/0x140<br /> blk_mq_sched_dispatch_requests+0x30/0x60<br /> __blk_mq_run_hw_queue+0x35/0x90<br /> __blk_mq_delay_run_hw_queue+0x161/0x180<br /> blk_execute_rq+0xbe/0x160<br /> __nvme_submit_sync_cmd+0x16f/0x220 [nvme_core]<br /> nvmf_connect_admin_queue+0x11a/0x170 [nvme_fabrics]<br /> nvme_fc_create_association.cold+0x50/0x3dc [nvme_fc]<br /> nvme_fc_connect_ctrl_work+0x19/0x30 [nvme_fc]<br /> process_one_work+0x1e8/0x3c0<br /> <br /> On abort timeout, completion was called without checking if the I/O was<br /> already completed.<br /> <br /> Verify that I/O and abort request are indeed outstanding before attempting<br /> completion.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> thermal: intel_powerclamp: Use get_cpu() instead of smp_processor_id() to avoid crash<br /> <br /> When CPU 0 is offline and intel_powerclamp is used to inject<br /> idle, it generates kernel BUG:<br /> <br /> BUG: using smp_processor_id() in preemptible [00000000] code: bash/15687<br /> caller is debug_smp_processor_id+0x17/0x20<br /> CPU: 4 PID: 15687 Comm: bash Not tainted 5.19.0-rc7+ #57<br /> Call Trace:<br /> <br /> dump_stack_lvl+0x49/0x63<br /> dump_stack+0x10/0x16<br /> check_preemption_disabled+0xdd/0xe0<br /> debug_smp_processor_id+0x17/0x20<br /> powerclamp_set_cur_state+0x7f/0xf9 [intel_powerclamp]<br /> ...<br /> ...<br /> <br /> Here CPU 0 is the control CPU by default and changed to the current CPU,<br /> if CPU 0 offlined. This check has to be performed under cpus_read_lock(),<br /> hence the above warning.<br /> <br /> Use get_cpu() instead of smp_processor_id() to avoid this BUG.<br /> <br /> [ rjw: Subject edits ]

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 /> dm cache: Fix UAF in destroy()<br /> <br /> Dm_cache also has the same UAF problem when dm_resume()<br /> and dm_destroy() are concurrent.<br /> <br /> Therefore, cancelling timer again in destroy().

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> binfmt_misc: fix shift-out-of-bounds in check_special_flags<br /> <br /> UBSAN reported a shift-out-of-bounds warning:<br /> <br /> left shift of 1 by 31 places cannot be represented in type &amp;#39;int&amp;#39;<br /> Call Trace:<br /> <br /> __dump_stack lib/dump_stack.c:88 [inline]<br /> dump_stack_lvl+0x8d/0xcf lib/dump_stack.c:106<br /> ubsan_epilogue+0xa/0x44 lib/ubsan.c:151<br /> __ubsan_handle_shift_out_of_bounds+0x1e7/0x208 lib/ubsan.c:322<br /> check_special_flags fs/binfmt_misc.c:241 [inline]<br /> create_entry fs/binfmt_misc.c:456 [inline]<br /> bm_register_write+0x9d3/0xa20 fs/binfmt_misc.c:654<br /> vfs_write+0x11e/0x580 fs/read_write.c:582<br /> ksys_write+0xcf/0x120 fs/read_write.c:637<br /> do_syscall_x64 arch/x86/entry/common.c:50 [inline]<br /> do_syscall_64+0x34/0x80 arch/x86/entry/common.c:80<br /> entry_SYSCALL_64_after_hwframe+0x63/0xcd<br /> RIP: 0033:0x4194e1<br /> <br /> Since the type of Node&amp;#39;s flags is unsigned long, we should define these<br /> macros with same type too.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> eth: alx: take rtnl_lock on resume<br /> <br /> Zbynek reports that alx trips an rtnl assertion on resume:<br /> <br /> RTNL: assertion failed at net/core/dev.c (2891)<br /> RIP: 0010:netif_set_real_num_tx_queues+0x1ac/0x1c0<br /> Call Trace:<br /> <br /> __alx_open+0x230/0x570 [alx]<br /> alx_resume+0x54/0x80 [alx]<br /> ? pci_legacy_resume+0x80/0x80<br /> dpm_run_callback+0x4a/0x150<br /> device_resume+0x8b/0x190<br /> async_resume+0x19/0x30<br /> async_run_entry_fn+0x30/0x130<br /> process_one_work+0x1e5/0x3b0<br /> <br /> indeed the driver does not hold rtnl_lock during its internal close<br /> and re-open functions during suspend/resume. Note that this is not<br /> a huge bug as the driver implements its own locking, and does not<br /> implement changing the number of queues, but we need to silence<br /> the splat.