Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/i915: Make intel_get_crtc_new_encoder() less oopsy<br /> <br /> The point of the WARN was to print something, not oops<br /> straight up. Currently that is precisely what happens<br /> if we can&amp;#39;t find the connector for the crtc in the atomic<br /> state. Get the dev pointer from the atomic state instead<br /> of the potentially NULL encoder to avoid that.<br /> <br /> (cherry picked from commit 3b6692357f70498f617ea1b31a0378070a0acf1c)

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> clk: imx: scu: use _safe list iterator to avoid a use after free<br /> <br /> This loop is freeing "clk" so it needs to use list_for_each_entry_safe().<br /> Otherwise it dereferences a freed variable to get the next item on the<br /> loop.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> clk: rs9: Fix suspend/resume<br /> <br /> Disabling the cache in commit 2ff4ba9e3702 ("clk: rs9: Fix I2C accessors")<br /> without removing cache synchronization in resume path results in a<br /> kernel panic as map-&gt;cache_ops is unset, due to REGCACHE_NONE.<br /> Enable flat cache again to support resume again. num_reg_defaults_raw<br /> is necessary to read the cache defaults from hardware. Some registers<br /> are strapped in hardware and cannot be provided in software.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> fprobe: Release rethook after the ftrace_ops is unregistered<br /> <br /> While running bpf selftests it&amp;#39;s possible to get following fault:<br /> <br /> general protection fault, probably for non-canonical address \<br /> 0x6b6b6b6b6b6b6b6b: 0000 [#1] PREEMPT SMP DEBUG_PAGEALLOC NOPTI<br /> ...<br /> Call Trace:<br /> <br /> fprobe_handler+0xc1/0x270<br /> ? __pfx_bpf_testmod_init+0x10/0x10<br /> ? __pfx_bpf_testmod_init+0x10/0x10<br /> ? bpf_fentry_test1+0x5/0x10<br /> ? bpf_fentry_test1+0x5/0x10<br /> ? bpf_testmod_init+0x22/0x80<br /> ? do_one_initcall+0x63/0x2e0<br /> ? rcu_is_watching+0xd/0x40<br /> ? kmalloc_trace+0xaf/0xc0<br /> ? do_init_module+0x60/0x250<br /> ? __do_sys_finit_module+0xac/0x120<br /> ? do_syscall_64+0x37/0x90<br /> ? entry_SYSCALL_64_after_hwframe+0x72/0xdc<br /> <br /> <br /> In unregister_fprobe function we can&amp;#39;t release fp-&gt;rethook while it&amp;#39;s<br /> possible there are some of its users still running on another cpu.<br /> <br /> Moving rethook_free call after fp-&gt;ops is unregistered with<br /> unregister_ftrace_function call.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> rcu-tasks: Avoid pr_info() with spin lock in cblist_init_generic()<br /> <br /> pr_info() is called with rtp-&gt;cbs_gbl_lock spin lock locked. Because<br /> pr_info() calls printk() that might sleep, this will result in BUG<br /> like below:<br /> <br /> [ 0.206455] cblist_init_generic: Setting adjustable number of callback queues.<br /> [ 0.206463]<br /> [ 0.206464] =============================<br /> [ 0.206464] [ BUG: Invalid wait context ]<br /> [ 0.206465] 5.19.0-00428-g9de1f9c8ca51 #5 Not tainted<br /> [ 0.206466] -----------------------------<br /> [ 0.206466] swapper/0/1 is trying to lock:<br /> [ 0.206467] ffffffffa0167a58 (&amp;port_lock_key){....}-{3:3}, at: serial8250_console_write+0x327/0x4a0<br /> [ 0.206473] other info that might help us debug this:<br /> [ 0.206473] context-{5:5}<br /> [ 0.206474] 3 locks held by swapper/0/1:<br /> [ 0.206474] #0: ffffffff9eb597e0 (rcu_tasks.cbs_gbl_lock){....}-{2:2}, at: cblist_init_generic.constprop.0+0x14/0x1f0<br /> [ 0.206478] #1: ffffffff9eb579c0 (console_lock){+.+.}-{0:0}, at: _printk+0x63/0x7e<br /> [ 0.206482] #2: ffffffff9ea77780 (console_owner){....}-{0:0}, at: console_emit_next_record.constprop.0+0x111/0x330<br /> [ 0.206485] stack backtrace:<br /> [ 0.206486] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 5.19.0-00428-g9de1f9c8ca51 #5<br /> [ 0.206488] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.0-1.fc36 04/01/2014<br /> [ 0.206489] Call Trace:<br /> [ 0.206490] <br /> [ 0.206491] dump_stack_lvl+0x6a/0x9f<br /> [ 0.206493] __lock_acquire.cold+0x2d7/0x2fe<br /> [ 0.206496] ? stack_trace_save+0x46/0x70<br /> [ 0.206497] lock_acquire+0xd1/0x2f0<br /> [ 0.206499] ? serial8250_console_write+0x327/0x4a0<br /> [ 0.206500] ? __lock_acquire+0x5c7/0x2720<br /> [ 0.206502] _raw_spin_lock_irqsave+0x3d/0x90<br /> [ 0.206504] ? serial8250_console_write+0x327/0x4a0<br /> [ 0.206506] serial8250_console_write+0x327/0x4a0<br /> [ 0.206508] console_emit_next_record.constprop.0+0x180/0x330<br /> [ 0.206511] console_unlock+0xf7/0x1f0<br /> [ 0.206512] vprintk_emit+0xf7/0x330<br /> [ 0.206514] _printk+0x63/0x7e<br /> [ 0.206516] cblist_init_generic.constprop.0.cold+0x24/0x32<br /> [ 0.206518] rcu_init_tasks_generic+0x5/0xd9<br /> [ 0.206522] kernel_init_freeable+0x15b/0x2a2<br /> [ 0.206523] ? rest_init+0x160/0x160<br /> [ 0.206526] kernel_init+0x11/0x120<br /> [ 0.206527] ret_from_fork+0x1f/0x30<br /> [ 0.206530] <br /> [ 0.207018] cblist_init_generic: Setting shift to 1 and lim to 1.<br /> <br /> This patch moves pr_info() so that it is called without<br /> rtp-&gt;cbs_gbl_lock locked.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ip_vti: fix potential slab-use-after-free in decode_session6<br /> <br /> When ip_vti device is set to the qdisc of the sfb type, the cb field<br /> of the sent skb may be modified during enqueuing. Then,<br /> slab-use-after-free may occur when ip_vti device sends IPv6 packets.<br /> As commit f855691975bb ("xfrm6: Fix the nexthdr offset in<br /> _decode_session6.") showed, xfrm_decode_session was originally intended<br /> only for the receive path. IP6CB(skb)-&gt;nhoff is not set during<br /> transmission. Therefore, set the cb field in the skb to 0 before<br /> sending packets.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> tracing/histograms: Add histograms to hist_vars if they have referenced variables<br /> <br /> Hist triggers can have referenced variables without having direct<br /> variables fields. This can be the case if referenced variables are added<br /> for trigger actions. In this case the newly added references will not<br /> have field variables. Not taking such referenced variables into<br /> consideration can result in a bug where it would be possible to remove<br /> hist trigger with variables being refenced. This will result in a bug<br /> that is easily reproducable like so<br /> <br /> $ cd /sys/kernel/tracing<br /> $ echo &amp;#39;synthetic_sys_enter char[] comm; long id&amp;#39; &gt;&gt; synthetic_events<br /> $ echo &amp;#39;hist:keys=common_pid.execname,id.syscall:vals=hitcount:comm=common_pid.execname&amp;#39; &gt;&gt; events/raw_syscalls/sys_enter/trigger<br /> $ echo &amp;#39;hist:keys=common_pid.execname,id.syscall:onmatch(raw_syscalls.sys_enter).synthetic_sys_enter($comm, id)&amp;#39; &gt;&gt; events/raw_syscalls/sys_enter/trigger<br /> $ echo &amp;#39;!hist:keys=common_pid.execname,id.syscall:vals=hitcount:comm=common_pid.execname&amp;#39; &gt;&gt; events/raw_syscalls/sys_enter/trigger<br /> <br /> [ 100.263533] ==================================================================<br /> [ 100.264634] BUG: KASAN: slab-use-after-free in resolve_var_refs+0xc7/0x180<br /> [ 100.265520] Read of size 8 at addr ffff88810375d0f0 by task bash/439<br /> [ 100.266320]<br /> [ 100.266533] CPU: 2 PID: 439 Comm: bash Not tainted 6.5.0-rc1 #4<br /> [ 100.267277] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.0-20220807_005459-localhost 04/01/2014<br /> [ 100.268561] Call Trace:<br /> [ 100.268902] <br /> [ 100.269189] dump_stack_lvl+0x4c/0x70<br /> [ 100.269680] print_report+0xc5/0x600<br /> [ 100.270165] ? resolve_var_refs+0xc7/0x180<br /> [ 100.270697] ? kasan_complete_mode_report_info+0x80/0x1f0<br /> [ 100.271389] ? resolve_var_refs+0xc7/0x180<br /> [ 100.271913] kasan_report+0xbd/0x100<br /> [ 100.272380] ? resolve_var_refs+0xc7/0x180<br /> [ 100.272920] __asan_load8+0x71/0xa0<br /> [ 100.273377] resolve_var_refs+0xc7/0x180<br /> [ 100.273888] event_hist_trigger+0x749/0x860<br /> [ 100.274505] ? kasan_save_stack+0x2a/0x50<br /> [ 100.275024] ? kasan_set_track+0x29/0x40<br /> [ 100.275536] ? __pfx_event_hist_trigger+0x10/0x10<br /> [ 100.276138] ? ksys_write+0xd1/0x170<br /> [ 100.276607] ? do_syscall_64+0x3c/0x90<br /> [ 100.277099] ? entry_SYSCALL_64_after_hwframe+0x6e/0xd8<br /> [ 100.277771] ? destroy_hist_data+0x446/0x470<br /> [ 100.278324] ? event_hist_trigger_parse+0xa6c/0x3860<br /> [ 100.278962] ? __pfx_event_hist_trigger_parse+0x10/0x10<br /> [ 100.279627] ? __kasan_check_write+0x18/0x20<br /> [ 100.280177] ? mutex_unlock+0x85/0xd0<br /> [ 100.280660] ? __pfx_mutex_unlock+0x10/0x10<br /> [ 100.281200] ? kfree+0x7b/0x120<br /> [ 100.281619] ? ____kasan_slab_free+0x15d/0x1d0<br /> [ 100.282197] ? event_trigger_write+0xac/0x100<br /> [ 100.282764] ? __kasan_slab_free+0x16/0x20<br /> [ 100.283293] ? __kmem_cache_free+0x153/0x2f0<br /> [ 100.283844] ? sched_mm_cid_remote_clear+0xb1/0x250<br /> [ 100.284550] ? __pfx_sched_mm_cid_remote_clear+0x10/0x10<br /> [ 100.285221] ? event_trigger_write+0xbc/0x100<br /> [ 100.285781] ? __kasan_check_read+0x15/0x20<br /> [ 100.286321] ? __bitmap_weight+0x66/0xa0<br /> [ 100.286833] ? _find_next_bit+0x46/0xe0<br /> [ 100.287334] ? task_mm_cid_work+0x37f/0x450<br /> [ 100.287872] event_triggers_call+0x84/0x150<br /> [ 100.288408] trace_event_buffer_commit+0x339/0x430<br /> [ 100.289073] ? ring_buffer_event_data+0x3f/0x60<br /> [ 100.292189] trace_event_raw_event_sys_enter+0x8b/0xe0<br /> [ 100.295434] syscall_trace_enter.constprop.0+0x18f/0x1b0<br /> [ 100.298653] syscall_enter_from_user_mode+0x32/0x40<br /> [ 100.301808] do_syscall_64+0x1a/0x90<br /> [ 100.304748] entry_SYSCALL_64_after_hwframe+0x6e/0xd8<br /> [ 100.307775] RIP: 0033:0x7f686c75c1cb<br /> [ 100.310617] Code: 73 01 c3 48 8b 0d 65 3c 10 00 f7 d8 64 89 01 48 83 c8 ff c3 66 2e 0f 1f 84 00 00 00 00 00 90 f3 0f 1e fa b8 21 00 00 00 0f 05 3d 01 f0 ff ff 73 01 c3 48 8b 0d 35 3c 10 00 f7 d8 64 89 01 48<br /> [ 100.317847] RSP: 002b:00007ffc60137a38 EFLAGS: 00000246 ORIG_RAX: 0000000000000021<br /> [ 100.321200] RA<br /> ---truncated---

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: wwan: iosm: fix NULL pointer dereference when removing device<br /> <br /> In suspend and resume cycle, the removal and rescan of device ends<br /> up in NULL pointer dereference.<br /> <br /> During driver initialization, if the ipc_imem_wwan_channel_init()<br /> fails to get the valid device capabilities it returns an error and<br /> further no resource (wwan struct) will be allocated. Now in this<br /> situation if driver removal procedure is initiated it would result<br /> in NULL pointer exception since unallocated wwan struct is dereferenced<br /> inside ipc_wwan_deinit().<br /> <br /> ipc_imem_run_state_worker() to handle the called functions return value<br /> and to release the resource in failure case. It also reports the link<br /> down event in failure cases. The user space application can handle this<br /> event to do a device reset for restoring the device communication.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/msm: fix vram leak on bind errors<br /> <br /> Make sure to release the VRAM buffer also in a case a subcomponent fails<br /> to bind.<br /> <br /> Patchwork: https://patchwork.freedesktop.org/patch/525094/

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> cpufreq: amd-pstate-ut: Fix kernel panic when loading the driver<br /> <br /> After loading the amd-pstate-ut driver, amd_pstate_ut_check_perf()<br /> and amd_pstate_ut_check_freq() use cpufreq_cpu_get() to get the policy<br /> of the CPU and mark it as busy.<br /> <br /> In these functions, cpufreq_cpu_put() should be used to release the<br /> policy, but it is not, so any other entity trying to access the policy<br /> is blocked indefinitely.<br /> <br /> One such scenario is when amd_pstate mode is changed, leading to the<br /> following splat:<br /> <br /> [ 1332.103727] INFO: task bash:2929 blocked for more than 120 seconds.<br /> [ 1332.110001] Not tainted 6.5.0-rc2-amd-pstate-ut #5<br /> [ 1332.115315] "echo 0 &gt; /proc/sys/kernel/hung_task_timeout_secs" disables this message.<br /> [ 1332.123140] task:bash state:D stack:0 pid:2929 ppid:2873 flags:0x00004006<br /> [ 1332.123143] Call Trace:<br /> [ 1332.123145] <br /> [ 1332.123148] __schedule+0x3c1/0x16a0<br /> [ 1332.123154] ? _raw_read_lock_irqsave+0x2d/0x70<br /> [ 1332.123157] schedule+0x6f/0x110<br /> [ 1332.123160] schedule_timeout+0x14f/0x160<br /> [ 1332.123162] ? preempt_count_add+0x86/0xd0<br /> [ 1332.123165] __wait_for_common+0x92/0x190<br /> [ 1332.123168] ? __pfx_schedule_timeout+0x10/0x10<br /> [ 1332.123170] wait_for_completion+0x28/0x30<br /> [ 1332.123173] cpufreq_policy_put_kobj+0x4d/0x90<br /> [ 1332.123177] cpufreq_policy_free+0x157/0x1d0<br /> [ 1332.123178] ? preempt_count_add+0x58/0xd0<br /> [ 1332.123180] cpufreq_remove_dev+0xb6/0x100<br /> [ 1332.123182] subsys_interface_unregister+0x114/0x120<br /> [ 1332.123185] ? preempt_count_add+0x58/0xd0<br /> [ 1332.123187] ? __pfx_amd_pstate_change_driver_mode+0x10/0x10<br /> [ 1332.123190] cpufreq_unregister_driver+0x3b/0xd0<br /> [ 1332.123192] amd_pstate_change_driver_mode+0x1e/0x50<br /> [ 1332.123194] store_status+0xe9/0x180<br /> [ 1332.123197] dev_attr_store+0x1b/0x30<br /> [ 1332.123199] sysfs_kf_write+0x42/0x50<br /> [ 1332.123202] kernfs_fop_write_iter+0x143/0x1d0<br /> [ 1332.123204] vfs_write+0x2df/0x400<br /> [ 1332.123208] ksys_write+0x6b/0xf0<br /> [ 1332.123210] __x64_sys_write+0x1d/0x30<br /> [ 1332.123213] do_syscall_64+0x60/0x90<br /> [ 1332.123216] ? fpregs_assert_state_consistent+0x2e/0x50<br /> [ 1332.123219] ? exit_to_user_mode_prepare+0x49/0x1a0<br /> [ 1332.123223] ? irqentry_exit_to_user_mode+0xd/0x20<br /> [ 1332.123225] ? irqentry_exit+0x3f/0x50<br /> [ 1332.123226] ? exc_page_fault+0x8e/0x190<br /> [ 1332.123228] entry_SYSCALL_64_after_hwframe+0x6e/0xd8<br /> [ 1332.123232] RIP: 0033:0x7fa74c514a37<br /> [ 1332.123234] RSP: 002b:00007ffe31dd0788 EFLAGS: 00000246 ORIG_RAX: 0000000000000001<br /> [ 1332.123238] RAX: ffffffffffffffda RBX: 0000000000000008 RCX: 00007fa74c514a37<br /> [ 1332.123239] RDX: 0000000000000008 RSI: 000055e27c447aa0 RDI: 0000000000000001<br /> [ 1332.123241] RBP: 000055e27c447aa0 R08: 00007fa74c5d1460 R09: 000000007fffffff<br /> [ 1332.123242] R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000008<br /> [ 1332.123244] R13: 00007fa74c61a780 R14: 00007fa74c616600 R15: 00007fa74c615a00<br /> [ 1332.123247] <br /> <br /> Fix this by calling cpufreq_cpu_put() wherever necessary.<br /> <br /> [ rjw: Subject and changelog edits ]

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ocfs2: fix defrag path triggering jbd2 ASSERT<br /> <br /> code path:<br /> <br /> ocfs2_ioctl_move_extents<br /> ocfs2_move_extents<br /> ocfs2_defrag_extent<br /> __ocfs2_move_extent<br /> + ocfs2_journal_access_di<br /> + ocfs2_split_extent //sub-paths call jbd2_journal_restart<br /> + ocfs2_journal_dirty //crash by jbs2 ASSERT<br /> <br /> crash stacks:<br /> <br /> PID: 11297 TASK: ffff974a676dcd00 CPU: 67 COMMAND: "defragfs.ocfs2"<br /> #0 [ffffb25d8dad3900] machine_kexec at ffffffff8386fe01<br /> #1 [ffffb25d8dad3958] __crash_kexec at ffffffff8395959d<br /> #2 [ffffb25d8dad3a20] crash_kexec at ffffffff8395a45d<br /> #3 [ffffb25d8dad3a38] oops_end at ffffffff83836d3f<br /> #4 [ffffb25d8dad3a58] do_trap at ffffffff83833205<br /> #5 [ffffb25d8dad3aa0] do_invalid_op at ffffffff83833aa6<br /> #6 [ffffb25d8dad3ac0] invalid_op at ffffffff84200d18<br /> [exception RIP: jbd2_journal_dirty_metadata+0x2ba]<br /> RIP: ffffffffc09ca54a RSP: ffffb25d8dad3b70 RFLAGS: 00010207<br /> RAX: 0000000000000000 RBX: ffff9706eedc5248 RCX: 0000000000000000<br /> RDX: 0000000000000001 RSI: ffff97337029ea28 RDI: ffff9706eedc5250<br /> RBP: ffff9703c3520200 R8: 000000000f46b0b2 R9: 0000000000000000<br /> R10: 0000000000000001 R11: 00000001000000fe R12: ffff97337029ea28<br /> R13: 0000000000000000 R14: ffff9703de59bf60 R15: ffff9706eedc5250<br /> ORIG_RAX: ffffffffffffffff CS: 0010 SS: 0018<br /> #7 [ffffb25d8dad3ba8] ocfs2_journal_dirty at ffffffffc137fb95 [ocfs2]<br /> #8 [ffffb25d8dad3be8] __ocfs2_move_extent at ffffffffc139a950 [ocfs2]<br /> #9 [ffffb25d8dad3c80] ocfs2_defrag_extent at ffffffffc139b2d2 [ocfs2]<br /> <br /> Analysis<br /> <br /> This bug has the same root cause of &amp;#39;commit 7f27ec978b0e ("ocfs2: call<br /> ocfs2_journal_access_di() before ocfs2_journal_dirty() in<br /> ocfs2_write_end_nolock()")&amp;#39;. For this bug, jbd2_journal_restart() is<br /> called by ocfs2_split_extent() during defragmenting.<br /> <br /> How to fix<br /> <br /> For ocfs2_split_extent() can handle journal operations totally by itself. <br /> Caller doesn&amp;#39;t need to call journal access/dirty pair, and caller only<br /> needs to call journal start/stop pair. The fix method is to remove<br /> journal access/dirty from __ocfs2_move_extent().<br /> <br /> The discussion for this patch:<br /> https://oss.oracle.com/pipermail/ocfs2-devel/2023-February/000647.html

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> wifi: brcmfmac: Check for probe() id argument being NULL<br /> <br /> The probe() id argument may be NULL in 2 scenarios:<br /> <br /> 1. brcmf_pcie_pm_leave_D3() calling brcmf_pcie_probe() to reprobe<br /> the device.<br /> <br /> 2. If a user tries to manually bind the driver from sysfs then the sdio /<br /> pcie / usb probe() function gets called with NULL as id argument.<br /> <br /> 1. Is being hit by users causing the following oops on resume and causing<br /> wifi to stop working:<br /> <br /> BUG: kernel NULL pointer dereference, address: 0000000000000018<br /> <br /> Hardware name: Dell Inc. XPS 13 9350/0PWNCR, BIDS 1.13.0 02/10/2020<br /> Workgueue: events_unbound async_run_entry_fn<br /> RIP: 0010:brcmf_pcie_probe+Ox16b/0x7a0 [brcmfmac]<br /> <br /> Call Trace:<br /> <br /> brcmf_pcie_pm_leave_D3+0xc5/8x1a0 [brcmfmac be3b4cefca451e190fa35be8f00db1bbec293887]<br /> ? pci_pm_resume+0x5b/0xf0<br /> ? pci_legacy_resume+0x80/0x80<br /> dpm_run_callback+0x47/0x150<br /> device_resume+0xa2/0x1f0<br /> async_resume+0x1d/0x30<br /> <br /> <br /> Fix this by checking for id being NULL.<br /> <br /> In the PCI and USB cases try a manual lookup of the id so that manually<br /> binding the driver through sysfs and more importantly brcmf_pcie_probe()<br /> on resume will work.<br /> <br /> For the SDIO case there is no helper to do a manual sdio_device_id lookup,<br /> so just directly error out on a NULL id there.