Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> usb: isp1760: Fix out-of-bounds array access<br /> <br /> Running the driver through kasan gives an interesting splat:<br /> <br /> BUG: KASAN: global-out-of-bounds in isp1760_register+0x180/0x70c<br /> Read of size 20 at addr f1db2e64 by task swapper/0/1<br /> (...)<br /> isp1760_register from isp1760_plat_probe+0x1d8/0x220<br /> (...)<br /> <br /> This happens because the loop reading the regmap fields for the<br /> different ISP1760 variants look like this:<br /> <br /> for (i = 0; i

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> x86/kexec: fix memory leak of elf header buffer<br /> <br /> This is reported by kmemleak detector:<br /> <br /> unreferenced object 0xffffc900002a9000 (size 4096):<br /> comm "kexec", pid 14950, jiffies 4295110793 (age 373.951s)<br /> hex dump (first 32 bytes):<br /> 7f 45 4c 46 02 01 01 00 00 00 00 00 00 00 00 00 .ELF............<br /> 04 00 3e 00 01 00 00 00 00 00 00 00 00 00 00 00 ..&gt;.............<br /> backtrace:<br /> [] __vmalloc_node_range+0x101/0x170<br /> [] __vmalloc_node+0xb4/0x160<br /> [] crash_prepare_elf64_headers+0x8e/0xcd0<br /> [] crash_load_segments+0x260/0x470<br /> [] bzImage64_load+0x814/0xad0<br /> [] arch_kexec_kernel_image_load+0x1be/0x2a0<br /> [] kimage_file_alloc_init+0x2ec/0x5a0<br /> [] __do_sys_kexec_file_load+0x28d/0x530<br /> [] do_syscall_64+0x3b/0x90<br /> [] entry_SYSCALL_64_after_hwframe+0x44/0xae<br /> <br /> In crash_prepare_elf64_headers(), a buffer is allocated via vmalloc() to<br /> store elf headers. While it&amp;#39;s not freed back to system correctly when<br /> kdump kernel is reloaded or unloaded. Then memory leak is caused. Fix it<br /> by introducing x86 specific function arch_kimage_file_post_load_cleanup(),<br /> and freeing the buffer there.<br /> <br /> And also remove the incorrect elf header buffer freeing code. Before<br /> calling arch specific kexec_file loading function, the image instance has<br /> been initialized. So &amp;#39;image-&gt;elf_headers&amp;#39; must be NULL. It doesn&amp;#39;t make<br /> sense to free the elf header buffer in the place.<br /> <br /> Three different people have reported three bugs about the memory leak on<br /> x86_64 inside Redhat.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> loop: implement -&gt;free_disk<br /> <br /> Ensure that the lo_device which is stored in the gendisk private<br /> data is valid until the gendisk is freed. Currently the loop driver<br /> uses a lot of effort to make sure a device is not freed when it is<br /> still in use, but to to fix a potential deadlock this will be relaxed<br /> a bit soon.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/virtio: fix NULL pointer dereference in virtio_gpu_conn_get_modes<br /> <br /> drm_cvt_mode may return NULL and we should check it.<br /> <br /> This bug is found by syzkaller:<br /> <br /> FAULT_INJECTION stacktrace:<br /> [ 168.567394] FAULT_INJECTION: forcing a failure.<br /> name failslab, interval 1, probability 0, space 0, times 1<br /> [ 168.567403] CPU: 1 PID: 6425 Comm: syz Kdump: loaded Not tainted 4.19.90-vhulk2201.1.0.h1035.kasan.eulerosv2r10.aarch64 #1<br /> [ 168.567406] Hardware name: QEMU KVM Virtual Machine, BIOS 0.0.0 02/06/2015<br /> [ 168.567408] Call trace:<br /> [ 168.567414] dump_backtrace+0x0/0x310<br /> [ 168.567418] show_stack+0x28/0x38<br /> [ 168.567423] dump_stack+0xec/0x15c<br /> [ 168.567427] should_fail+0x3ac/0x3d0<br /> [ 168.567437] __should_failslab+0xb8/0x120<br /> [ 168.567441] should_failslab+0x28/0xc0<br /> [ 168.567445] kmem_cache_alloc_trace+0x50/0x640<br /> [ 168.567454] drm_mode_create+0x40/0x90<br /> [ 168.567458] drm_cvt_mode+0x48/0xc78<br /> [ 168.567477] virtio_gpu_conn_get_modes+0xa8/0x140 [virtio_gpu]<br /> [ 168.567485] drm_helper_probe_single_connector_modes+0x3a4/0xd80<br /> [ 168.567492] drm_mode_getconnector+0x2e0/0xa70<br /> [ 168.567496] drm_ioctl_kernel+0x11c/0x1d8<br /> [ 168.567514] drm_ioctl+0x558/0x6d0<br /> [ 168.567522] do_vfs_ioctl+0x160/0xf30<br /> [ 168.567525] ksys_ioctl+0x98/0xd8<br /> [ 168.567530] __arm64_sys_ioctl+0x50/0xc8<br /> [ 168.567536] el0_svc_common+0xc8/0x320<br /> [ 168.567540] el0_svc_handler+0xf8/0x160<br /> [ 168.567544] el0_svc+0x10/0x218<br /> <br /> KASAN stacktrace:<br /> [ 168.567561] BUG: KASAN: null-ptr-deref in virtio_gpu_conn_get_modes+0xb4/0x140 [virtio_gpu]<br /> [ 168.567565] Read of size 4 at addr 0000000000000054 by task syz/6425<br /> [ 168.567566]<br /> [ 168.567571] CPU: 1 PID: 6425 Comm: syz Kdump: loaded Not tainted 4.19.90-vhulk2201.1.0.h1035.kasan.eulerosv2r10.aarch64 #1<br /> [ 168.567573] Hardware name: QEMU KVM Virtual Machine, BIOS 0.0.0 02/06/2015<br /> [ 168.567575] Call trace:<br /> [ 168.567578] dump_backtrace+0x0/0x310<br /> [ 168.567582] show_stack+0x28/0x38<br /> [ 168.567586] dump_stack+0xec/0x15c<br /> [ 168.567591] kasan_report+0x244/0x2f0<br /> [ 168.567594] __asan_load4+0x58/0xb0<br /> [ 168.567607] virtio_gpu_conn_get_modes+0xb4/0x140 [virtio_gpu]<br /> [ 168.567612] drm_helper_probe_single_connector_modes+0x3a4/0xd80<br /> [ 168.567617] drm_mode_getconnector+0x2e0/0xa70<br /> [ 168.567621] drm_ioctl_kernel+0x11c/0x1d8<br /> [ 168.567624] drm_ioctl+0x558/0x6d0<br /> [ 168.567628] do_vfs_ioctl+0x160/0xf30<br /> [ 168.567632] ksys_ioctl+0x98/0xd8<br /> [ 168.567636] __arm64_sys_ioctl+0x50/0xc8<br /> [ 168.567641] el0_svc_common+0xc8/0x320<br /> [ 168.567645] el0_svc_handler+0xf8/0x160<br /> [ 168.567649] el0_svc+0x10/0x218

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ath11k: Change max no of active probe SSID and BSSID to fw capability<br /> <br /> The maximum number of SSIDs in a for active probe requests is currently<br /> reported as 16 (WLAN_SCAN_PARAMS_MAX_SSID) when registering the driver.<br /> The scan_req_params structure only has the capacity to hold 10 SSIDs.<br /> This leads to a buffer overflow which can be triggered from<br /> wpa_supplicant in userspace. When copying the SSIDs into the<br /> scan_req_params structure in the ath11k_mac_op_hw_scan route, it can<br /> overwrite the extraie pointer.<br /> <br /> Firmware supports 16 ssid * 4 bssid, for each ssid 4 bssid combo probe<br /> request will be sent, so totally 64 probe requests supported. So<br /> set both max ssid and bssid to 16 and 4 respectively. Remove the<br /> redundant macros of ssid and bssid.<br /> <br /> Tested-on: IPQ8074 hw2.0 AHB WLAN.HK.2.7.0.1-01300-QCAHKSWPL_SILICONZ-1

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> scsi: lpfc: Protect memory leak for NPIV ports sending PLOGI_RJT<br /> <br /> There is a potential memory leak in lpfc_ignore_els_cmpl() and<br /> lpfc_els_rsp_reject() that was allocated from NPIV PLOGI_RJT<br /> (lpfc_rcv_plogi()&amp;#39;s login_mbox).<br /> <br /> Check if cmdiocb-&gt;context_un.mbox was allocated in lpfc_ignore_els_cmpl(),<br /> and then free it back to phba-&gt;mbox_mem_pool along with mbox-&gt;ctx_buf for<br /> service parameters.<br /> <br /> For lpfc_els_rsp_reject() failure, free both the ctx_buf for service<br /> parameters and the login_mbox.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> scsi: lpfc: Fix SCSI I/O completion and abort handler deadlock<br /> <br /> During stress I/O tests with 500+ vports, hard LOCKUP call traces are<br /> observed.<br /> <br /> CPU A:<br /> native_queued_spin_lock_slowpath+0x192<br /> _raw_spin_lock_irqsave+0x32<br /> lpfc_handle_fcp_err+0x4c6<br /> lpfc_fcp_io_cmd_wqe_cmpl+0x964<br /> lpfc_sli4_fp_handle_cqe+0x266<br /> __lpfc_sli4_process_cq+0x105<br /> __lpfc_sli4_hba_process_cq+0x3c<br /> lpfc_cq_poll_hdler+0x16<br /> irq_poll_softirq+0x76<br /> __softirqentry_text_start+0xe4<br /> irq_exit+0xf7<br /> do_IRQ+0x7f<br /> <br /> CPU B:<br /> native_queued_spin_lock_slowpath+0x5b<br /> _raw_spin_lock+0x1c<br /> lpfc_abort_handler+0x13e<br /> scmd_eh_abort_handler+0x85<br /> process_one_work+0x1a7<br /> worker_thread+0x30<br /> kthread+0x112<br /> ret_from_fork+0x1f<br /> <br /> Diagram of lockup:<br /> <br /> CPUA CPUB<br /> ---- ----<br /> lpfc_cmd-&gt;buf_lock<br /> phba-&gt;hbalock<br /> lpfc_cmd-&gt;buf_lock<br /> phba-&gt;hbalock<br /> <br /> Fix by reordering the taking of the lpfc_cmd-&gt;buf_lock and phba-&gt;hbalock in<br /> lpfc_abort_handler routine so that it tries to take the lpfc_cmd-&gt;buf_lock<br /> first before phba-&gt;hbalock.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> scsi: lpfc: Fix call trace observed during I/O with CMF enabled<br /> <br /> The following was seen with CMF enabled:<br /> <br /> BUG: using smp_processor_id() in preemptible<br /> code: systemd-udevd/31711<br /> kernel: caller is lpfc_update_cmf_cmd+0x214/0x420 [lpfc]<br /> kernel: CPU: 12 PID: 31711 Comm: systemd-udevd<br /> kernel: Call Trace:<br /> kernel: <br /> kernel: dump_stack_lvl+0x44/0x57<br /> kernel: check_preemption_disabled+0xbf/0xe0<br /> kernel: lpfc_update_cmf_cmd+0x214/0x420 [lpfc]<br /> kernel: lpfc_nvme_fcp_io_submit+0x23b4/0x4df0 [lpfc]<br /> <br /> this_cpu_ptr() calls smp_processor_id() in a preemptible context.<br /> <br /> Fix by using per_cpu_ptr() with raw_smp_processor_id() instead.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ALSA: jack: Access input_dev under mutex<br /> <br /> It is possible when using ASoC that input_dev is unregistered while<br /> calling snd_jack_report, which causes NULL pointer dereference.<br /> In order to prevent this serialize access to input_dev using mutex lock.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> rtw89: ser: fix CAM leaks occurring in L2 reset<br /> <br /> The CAM, meaning address CAM and bssid CAM here, will get leaks during<br /> SER (system error recover) L2 reset process and ieee80211_restart_hw()<br /> which is called by L2 reset process eventually.<br /> <br /> The normal flow would be like<br /> -&gt; add interface (acquire 1)<br /> -&gt; enter ips (release 1)<br /> -&gt; leave ips (acquire 1)<br /> -&gt; connection (occupy 1) <br /> <br /> The ieee80211_restart_hw() flow (under connection)<br /> -&gt; ieee80211 reconfig<br /> -&gt; add interface (acquire 1)<br /> -&gt; leave ips (acquire 1)<br /> -&gt; connection (occupy (A) + 2) <br /> <br /> Originally, CAM is released before HW restart only if connection is under<br /> security. Now, release CAM whatever connection it is to fix leak in (A).<br /> OTOH, check if CAM is already valid to avoid acquiring multiple times to<br /> fix (B).<br /> <br /> Besides, if AP mode, release address CAM of all stations before HW restart.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> rcu-tasks: Fix race in schedule and flush work<br /> <br /> While booting secondary CPUs, cpus_read_[lock/unlock] is not keeping<br /> online cpumask stable. The transient online mask results in below<br /> calltrace.<br /> <br /> [ 0.324121] CPU1: Booted secondary processor 0x0000000001 [0x410fd083]<br /> [ 0.346652] Detected PIPT I-cache on CPU2<br /> [ 0.347212] CPU2: Booted secondary processor 0x0000000002 [0x410fd083]<br /> [ 0.377255] Detected PIPT I-cache on CPU3<br /> [ 0.377823] CPU3: Booted secondary processor 0x0000000003 [0x410fd083]<br /> [ 0.379040] ------------[ cut here ]------------<br /> [ 0.383662] WARNING: CPU: 0 PID: 10 at kernel/workqueue.c:3084 __flush_work+0x12c/0x138<br /> [ 0.384850] Modules linked in:<br /> [ 0.385403] CPU: 0 PID: 10 Comm: rcu_tasks_rude_ Not tainted 5.17.0-rc3-v8+ #13<br /> [ 0.386473] Hardware name: Raspberry Pi 4 Model B Rev 1.4 (DT)<br /> [ 0.387289] pstate: 20000005 (nzCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)<br /> [ 0.388308] pc : __flush_work+0x12c/0x138<br /> [ 0.388970] lr : __flush_work+0x80/0x138<br /> [ 0.389620] sp : ffffffc00aaf3c60<br /> [ 0.390139] x29: ffffffc00aaf3d20 x28: ffffffc009c16af0 x27: ffffff80f761df48<br /> [ 0.391316] x26: 0000000000000004 x25: 0000000000000003 x24: 0000000000000100<br /> [ 0.392493] x23: ffffffffffffffff x22: ffffffc009c16b10 x21: ffffffc009c16b28<br /> [ 0.393668] x20: ffffffc009e53861 x19: ffffff80f77fbf40 x18: 00000000d744fcc9<br /> [ 0.394842] x17: 000000000000000b x16: 00000000000001c2 x15: ffffffc009e57550<br /> [ 0.396016] x14: 0000000000000000 x13: ffffffffffffffff x12: 0000000100000000<br /> [ 0.397190] x11: 0000000000000462 x10: ffffff8040258008 x9 : 0000000100000000<br /> [ 0.398364] x8 : 0000000000000000 x7 : ffffffc0093c8bf4 x6 : 0000000000000000<br /> [ 0.399538] x5 : 0000000000000000 x4 : ffffffc00a976e40 x3 : ffffffc00810444c<br /> [ 0.400711] x2 : 0000000000000004 x1 : 0000000000000000 x0 : 0000000000000000<br /> [ 0.401886] Call trace:<br /> [ 0.402309] __flush_work+0x12c/0x138<br /> [ 0.402941] schedule_on_each_cpu+0x228/0x278<br /> [ 0.403693] rcu_tasks_rude_wait_gp+0x130/0x144<br /> [ 0.404502] rcu_tasks_kthread+0x220/0x254<br /> [ 0.405264] kthread+0x174/0x1ac<br /> [ 0.405837] ret_from_fork+0x10/0x20<br /> [ 0.406456] irq event stamp: 102<br /> [ 0.406966] hardirqs last enabled at (101): [] _raw_spin_unlock_irq+0x78/0xb4<br /> [ 0.408304] hardirqs last disabled at (102): [] el1_dbg+0x24/0x5c<br /> [ 0.409410] softirqs last enabled at (54): [] local_bh_enable+0xc/0x2c<br /> [ 0.410645] softirqs last disabled at (50): [] local_bh_disable+0xc/0x2c<br /> [ 0.411890] ---[ end trace 0000000000000000 ]---<br /> [ 0.413000] smp: Brought up 1 node, 4 CPUs<br /> [ 0.413762] SMP: Total of 4 processors activated.<br /> [ 0.414566] CPU features: detected: 32-bit EL0 Support<br /> [ 0.415414] CPU features: detected: 32-bit EL1 Support<br /> [ 0.416278] CPU features: detected: CRC32 instructions<br /> [ 0.447021] Callback from call_rcu_tasks_rude() invoked.<br /> [ 0.506693] Callback from call_rcu_tasks() invoked.<br /> <br /> This commit therefore fixes this issue by applying a single-CPU<br /> optimization to the RCU Tasks Rude grace-period process. The key point<br /> here is that the purpose of this RCU flavor is to force a schedule on<br /> each online CPU since some past event. But the rcu_tasks_rude_wait_gp()<br /> function runs in the context of the RCU Tasks Rude&amp;#39;s grace-period kthread,<br /> so there must already have been a context switch on the current CPU since<br /> the call to either synchronize_rcu_tasks_rude() or call_rcu_tasks_rude().<br /> So if there is only a single CPU online, RCU Tasks Rude&amp;#39;s grace-period<br /> kthread does not need to anything at all.<br /> <br /> It turns out that the rcu_tasks_rude_wait_gp() function&amp;#39;s call to<br /> schedule_on_each_cpu() causes problems during early boot. During that<br /> time, there is only one online CPU, namely the boot CPU. Therefore,<br /> applying this single-CPU optimization fixes early-boot instances of<br /> this problem.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> scsi: lpfc: Fix null pointer dereference after failing to issue FLOGI and PLOGI<br /> <br /> If lpfc_issue_els_flogi() fails and returns non-zero status, the node<br /> reference count is decremented to trigger the release of the nodelist<br /> structure. However, if there is a prior registration or dev-loss-evt work<br /> pending, the node may be released prematurely. When dev-loss-evt<br /> completes, the released node is referenced causing a use-after-free null<br /> pointer dereference.<br /> <br /> Similarly, when processing non-zero ELS PLOGI completion status in<br /> lpfc_cmpl_els_plogi(), the ndlp flags are checked for a transport<br /> registration before triggering node removal. If dev-loss-evt work is<br /> pending, the node may be released prematurely and a subsequent call to<br /> lpfc_dev_loss_tmo_handler() results in a use after free ndlp dereference.<br /> <br /> Add test for pending dev-loss before decrementing the node reference count<br /> for FLOGI, PLOGI, PRLI, and ADISC handling.