Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> rtc: gamecube: Fix refcount leak in gamecube_rtc_read_offset_from_sram<br /> <br /> The of_find_compatible_node() function returns a node pointer with<br /> refcount incremented, We should use of_node_put() on it when done<br /> Add the missing of_node_put() to release the refcount.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> scsi: qla2xxx: Suppress a kernel complaint in qla_create_qpair()<br /> <br /> [ 12.323788] BUG: using smp_processor_id() in preemptible [00000000] code: systemd-udevd/1020<br /> [ 12.332297] caller is qla2xxx_create_qpair+0x32a/0x5d0 [qla2xxx]<br /> [ 12.338417] CPU: 7 PID: 1020 Comm: systemd-udevd Tainted: G I --------- --- 5.14.0-29.el9.x86_64 #1<br /> [ 12.348827] Hardware name: Dell Inc. PowerEdge R610/0F0XJ6, BIOS 6.6.0 05/22/2018<br /> [ 12.356356] Call Trace:<br /> [ 12.358821] dump_stack_lvl+0x34/0x44<br /> [ 12.362514] check_preemption_disabled+0xd9/0xe0<br /> [ 12.367164] qla2xxx_create_qpair+0x32a/0x5d0 [qla2xxx]<br /> [ 12.372481] qla2x00_probe_one+0xa3a/0x1b80 [qla2xxx]<br /> [ 12.377617] ? _raw_spin_lock_irqsave+0x19/0x40<br /> [ 12.384284] local_pci_probe+0x42/0x80<br /> [ 12.390162] ? pci_match_device+0xd7/0x110<br /> [ 12.396366] pci_device_probe+0xfd/0x1b0<br /> [ 12.402372] really_probe+0x1e7/0x3e0<br /> [ 12.408114] __driver_probe_device+0xfe/0x180<br /> [ 12.414544] driver_probe_device+0x1e/0x90<br /> [ 12.420685] __driver_attach+0xc0/0x1c0<br /> [ 12.426536] ? __device_attach_driver+0xe0/0xe0<br /> [ 12.433061] ? __device_attach_driver+0xe0/0xe0<br /> [ 12.439538] bus_for_each_dev+0x78/0xc0<br /> [ 12.445294] bus_add_driver+0x12b/0x1e0<br /> [ 12.451021] driver_register+0x8f/0xe0<br /> [ 12.456631] ? 0xffffffffc07bc000<br /> [ 12.461773] qla2x00_module_init+0x1be/0x229 [qla2xxx]<br /> [ 12.468776] do_one_initcall+0x44/0x200<br /> [ 12.474401] ? load_module+0xad3/0xba0<br /> [ 12.479908] ? kmem_cache_alloc_trace+0x45/0x410<br /> [ 12.486268] do_init_module+0x5c/0x280<br /> [ 12.491730] __do_sys_init_module+0x12e/0x1b0<br /> [ 12.497785] do_syscall_64+0x3b/0x90<br /> [ 12.503029] entry_SYSCALL_64_after_hwframe+0x44/0xae<br /> [ 12.509764] RIP: 0033:0x7f554f73ab2e

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> KVM: SVM: fix panic on out-of-bounds guest IRQ<br /> <br /> As guest_irq is coming from KVM_IRQFD API call, it may trigger<br /> crash in svm_update_pi_irte() due to out-of-bounds:<br /> <br /> crash&gt; bt<br /> PID: 22218 TASK: ffff951a6ad74980 CPU: 73 COMMAND: "vcpu8"<br /> #0 [ffffb1ba6707fa40] machine_kexec at ffffffff8565b397<br /> #1 [ffffb1ba6707fa90] __crash_kexec at ffffffff85788a6d<br /> #2 [ffffb1ba6707fb58] crash_kexec at ffffffff8578995d<br /> #3 [ffffb1ba6707fb70] oops_end at ffffffff85623c0d<br /> #4 [ffffb1ba6707fb90] no_context at ffffffff856692c9<br /> #5 [ffffb1ba6707fbf8] exc_page_fault at ffffffff85f95b51<br /> #6 [ffffb1ba6707fc50] asm_exc_page_fault at ffffffff86000ace<br /> [exception RIP: svm_update_pi_irte+227]<br /> RIP: ffffffffc0761b53 RSP: ffffb1ba6707fd08 RFLAGS: 00010086<br /> RAX: ffffb1ba6707fd78 RBX: ffffb1ba66d91000 RCX: 0000000000000001<br /> RDX: 00003c803f63f1c0 RSI: 000000000000019a RDI: ffffb1ba66db2ab8<br /> RBP: 000000000000019a R8: 0000000000000040 R9: ffff94ca41b82200<br /> R10: ffffffffffffffcf R11: 0000000000000001 R12: 0000000000000001<br /> R13: 0000000000000001 R14: ffffffffffffffcf R15: 000000000000005f<br /> ORIG_RAX: ffffffffffffffff CS: 0010 SS: 0018<br /> #7 [ffffb1ba6707fdb8] kvm_irq_routing_update at ffffffffc09f19a1 [kvm]<br /> #8 [ffffb1ba6707fde0] kvm_set_irq_routing at ffffffffc09f2133 [kvm]<br /> #9 [ffffb1ba6707fe18] kvm_vm_ioctl at ffffffffc09ef544 [kvm]<br /> RIP: 00007f143c36488b RSP: 00007f143a4e04b8 RFLAGS: 00000246<br /> RAX: ffffffffffffffda RBX: 00007f05780041d0 RCX: 00007f143c36488b<br /> RDX: 00007f05780041d0 RSI: 000000004008ae6a RDI: 0000000000000020<br /> RBP: 00000000000004e8 R8: 0000000000000008 R9: 00007f05780041e0<br /> R10: 00007f0578004560 R11: 0000000000000246 R12: 00000000000004e0<br /> R13: 000000000000001a R14: 00007f1424001c60 R15: 00007f0578003bc0<br /> ORIG_RAX: 0000000000000010 CS: 0033 SS: 002b<br /> <br /> Vmx have been fix this in commit 3a8b0677fc61 (KVM: VMX: Do not BUG() on<br /> out-of-bounds guest IRQ), so we can just copy source from that to fix<br /> this.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> scsi: qla2xxx: Fix scheduling while atomic<br /> <br /> The driver makes a call into midlayer (fc_remote_port_delete) which can put<br /> the thread to sleep. The thread that originates the call is in interrupt<br /> context. The combination of the two trigger a crash. Schedule the call in<br /> non-interrupt context where it is more safe.<br /> <br /> kernel: BUG: scheduling while atomic: swapper/7/0/0x00010000<br /> kernel: Call Trace:<br /> kernel: <br /> kernel: dump_stack+0x66/0x81<br /> kernel: __schedule_bug.cold.90+0x5/0x1d<br /> kernel: __schedule+0x7af/0x960<br /> kernel: schedule+0x28/0x80<br /> kernel: schedule_timeout+0x26d/0x3b0<br /> kernel: wait_for_completion+0xb4/0x140<br /> kernel: ? wake_up_q+0x70/0x70<br /> kernel: __wait_rcu_gp+0x12c/0x160<br /> kernel: ? sdev_evt_alloc+0xc0/0x180 [scsi_mod]<br /> kernel: synchronize_sched+0x6c/0x80<br /> kernel: ? call_rcu_bh+0x20/0x20<br /> kernel: ? __bpf_trace_rcu_invoke_callback+0x10/0x10<br /> kernel: sdev_evt_alloc+0xfd/0x180 [scsi_mod]<br /> kernel: starget_for_each_device+0x85/0xb0 [scsi_mod]<br /> kernel: ? scsi_init_io+0x360/0x3d0 [scsi_mod]<br /> kernel: scsi_init_io+0x388/0x3d0 [scsi_mod]<br /> kernel: device_for_each_child+0x54/0x90<br /> kernel: fc_remote_port_delete+0x70/0xe0 [scsi_transport_fc]<br /> kernel: qla2x00_schedule_rport_del+0x62/0xf0 [qla2xxx]<br /> kernel: qla2x00_mark_device_lost+0x9c/0xd0 [qla2xxx]<br /> kernel: qla24xx_handle_plogi_done_event+0x55f/0x570 [qla2xxx]<br /> kernel: qla2x00_async_login_sp_done+0xd2/0x100 [qla2xxx]<br /> kernel: qla24xx_logio_entry+0x13a/0x3c0 [qla2xxx]<br /> kernel: qla24xx_process_response_queue+0x306/0x400 [qla2xxx]<br /> kernel: qla24xx_msix_rsp_q+0x3f/0xb0 [qla2xxx]<br /> kernel: __handle_irq_event_percpu+0x40/0x180<br /> kernel: handle_irq_event_percpu+0x30/0x80<br /> kernel: handle_irq_event+0x36/0x60

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> scsi: qla2xxx: Fix premature hw access after PCI error<br /> <br /> After a recoverable PCI error has been detected and recovered, qla driver<br /> needs to check to see if the error condition still persist and/or wait<br /> for the OS to give the resume signal.<br /> <br /> Sep 8 22:26:03 localhost kernel: WARNING: CPU: 9 PID: 124606 at qla_tmpl.c:440<br /> qla27xx_fwdt_entry_t266+0x55/0x60 [qla2xxx]<br /> Sep 8 22:26:03 localhost kernel: RIP: 0010:qla27xx_fwdt_entry_t266+0x55/0x60<br /> [qla2xxx]<br /> Sep 8 22:26:03 localhost kernel: Call Trace:<br /> Sep 8 22:26:03 localhost kernel: ? qla27xx_walk_template+0xb1/0x1b0 [qla2xxx]<br /> Sep 8 22:26:03 localhost kernel: ? qla27xx_execute_fwdt_template+0x12a/0x160<br /> [qla2xxx]<br /> Sep 8 22:26:03 localhost kernel: ? qla27xx_fwdump+0xa0/0x1c0 [qla2xxx]<br /> Sep 8 22:26:03 localhost kernel: ? qla2xxx_pci_mmio_enabled+0xfb/0x120<br /> [qla2xxx]<br /> Sep 8 22:26:03 localhost kernel: ? report_mmio_enabled+0x44/0x80<br /> Sep 8 22:26:03 localhost kernel: ? report_slot_reset+0x80/0x80<br /> Sep 8 22:26:03 localhost kernel: ? pci_walk_bus+0x70/0x90<br /> Sep 8 22:26:03 localhost kernel: ? aer_dev_correctable_show+0xc0/0xc0<br /> Sep 8 22:26:03 localhost kernel: ? pcie_do_recovery+0x1bb/0x240<br /> Sep 8 22:26:03 localhost kernel: ? aer_recover_work_func+0xaa/0xd0<br /> Sep 8 22:26:03 localhost kernel: ? process_one_work+0x1a7/0x360<br /> ..<br /> Sep 8 22:26:03 localhost kernel: qla2xxx [0000:42:00.2]-8041:22: detected PCI<br /> disconnect.<br /> Sep 8 22:26:03 localhost kernel: qla2xxx [0000:42:00.2]-107ff:22:<br /> qla27xx_fwdt_entry_t262: dump ram MB failed. Area 5h start 198013h end 198013h<br /> Sep 8 22:26:03 localhost kernel: qla2xxx [0000:42:00.2]-107ff:22: Unable to<br /> capture FW dump<br /> Sep 8 22:26:03 localhost kernel: qla2xxx [0000:42:00.2]-1015:22: cmd=0x0,<br /> waited 5221 msecs<br /> Sep 8 22:26:03 localhost kernel: qla2xxx [0000:42:00.2]-680d:22: mmio<br /> enabled returning.<br /> Sep 8 22:26:03 localhost kernel: qla2xxx [0000:42:00.2]-d04c:22: MBX<br /> Command timeout for cmd 0, iocontrol=ffffffff jiffies=10140f2e5<br /> mb[0-3]=[0xffff 0xffff 0xffff 0xffff]

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> rxrpc: Fix call timer start racing with call destruction<br /> <br /> The rxrpc_call struct has a timer used to handle various timed events<br /> relating to a call. This timer can get started from the packet input<br /> routines that are run in softirq mode with just the RCU read lock held.<br /> Unfortunately, because only the RCU read lock is held - and neither ref or<br /> other lock is taken - the call can start getting destroyed at the same time<br /> a packet comes in addressed to that call. This causes the timer - which<br /> was already stopped - to get restarted. Later, the timer dispatch code may<br /> then oops if the timer got deallocated first.<br /> <br /> Fix this by trying to take a ref on the rxrpc_call struct and, if<br /> successful, passing that ref along to the timer. If the timer was already<br /> running, the ref is discarded.<br /> <br /> The timer completion routine can then pass the ref along to the call&amp;#39;s work<br /> item when it queues it. If the timer or work item where already<br /> queued/running, the extra ref is discarded.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> can: mcba_usb: properly check endpoint type<br /> <br /> Syzbot reported warning in usb_submit_urb() which is caused by wrong<br /> endpoint type. We should check that in endpoint is actually present to<br /> prevent this warning.<br /> <br /> Found pipes are now saved to struct mcba_priv and code uses them<br /> directly instead of making pipes in place.<br /> <br /> Fail log:<br /> <br /> | usb 5-1: BOGUS urb xfer, pipe 3 != type 1<br /> | WARNING: CPU: 1 PID: 49 at drivers/usb/core/urb.c:502 usb_submit_urb+0xed2/0x18a0 drivers/usb/core/urb.c:502<br /> | Modules linked in:<br /> | CPU: 1 PID: 49 Comm: kworker/1:2 Not tainted 5.17.0-rc6-syzkaller-00184-g38f80f42147f #0<br /> | Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.14.0-2 04/01/2014<br /> | Workqueue: usb_hub_wq hub_event<br /> | RIP: 0010:usb_submit_urb+0xed2/0x18a0 drivers/usb/core/urb.c:502<br /> | ...<br /> | Call Trace:<br /> | <br /> | mcba_usb_start drivers/net/can/usb/mcba_usb.c:662 [inline]<br /> | mcba_usb_probe+0x8a3/0xc50 drivers/net/can/usb/mcba_usb.c:858<br /> | usb_probe_interface+0x315/0x7f0 drivers/usb/core/driver.c:396<br /> | call_driver_probe drivers/base/dd.c:517 [inline]

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> XArray: Fix xas_create_range() when multi-order entry present<br /> <br /> If there is already an entry present that is of order &gt;= XA_CHUNK_SHIFT<br /> when we call xas_create_range(), xas_create_range() will misinterpret<br /> that entry as a node and dereference xa_node-&gt;parent, generally leading<br /> to a crash that looks something like this:<br /> <br /> general protection fault, probably for non-canonical address 0xdffffc0000000001:<br /> 0000 [#1] PREEMPT SMP KASAN<br /> KASAN: null-ptr-deref in range [0x0000000000000008-0x000000000000000f]<br /> CPU: 0 PID: 32 Comm: khugepaged Not tainted 5.17.0-rc8-syzkaller-00003-g56e337f2cf13 #0<br /> RIP: 0010:xa_parent_locked include/linux/xarray.h:1207 [inline]<br /> RIP: 0010:xas_create_range+0x2d9/0x6e0 lib/xarray.c:725<br /> <br /> It&amp;#39;s deterministically reproducable once you know what the problem is,<br /> but producing it in a live kernel requires khugepaged to hit a race.<br /> While the problem has been present since xas_create_range() was<br /> introduced, I&amp;#39;m not aware of a way to hit it before the page cache was<br /> converted to use multi-index entries.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: dsa: felix: fix possible NULL pointer dereference<br /> <br /> As the possible failure of the allocation, kzalloc() may return NULL<br /> pointer.<br /> Therefore, it should be better to check the &amp;#39;sgi&amp;#39; in order to prevent<br /> the dereference of NULL pointer.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> Bluetooth: fix null ptr deref on hci_sync_conn_complete_evt<br /> <br /> This event is just specified for SCO and eSCO link types.<br /> On the reception of a HCI_Synchronous_Connection_Complete for a BDADDR<br /> of an existing LE connection, LE link type and a status that triggers the<br /> second case of the packet processing a NULL pointer dereference happens,<br /> as conn-&gt;link is NULL.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> io_uring: fix memory leak of uid in files registration<br /> <br /> When there are no files for __io_sqe_files_scm() to process in the<br /> range, it&amp;#39;ll free everything and return. However, it forgets to put uid.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> watch_queue: Free the page array when watch_queue is dismantled<br /> <br /> Commit 7ea1a0124b6d ("watch_queue: Free the alloc bitmap when the<br /> watch_queue is torn down") took care of the bitmap, but not the page<br /> array.<br /> <br /> BUG: memory leak<br /> unreferenced object 0xffff88810d9bc140 (size 32):<br /> comm "syz-executor335", pid 3603, jiffies 4294946994 (age 12.840s)<br /> hex dump (first 32 bytes):<br /> 40 a7 40 04 00 ea ff ff 00 00 00 00 00 00 00 00 @.@.............<br /> 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................<br /> backtrace:<br /> kmalloc_array include/linux/slab.h:621 [inline]<br /> kcalloc include/linux/slab.h:652 [inline]<br /> watch_queue_set_size+0x12f/0x2e0 kernel/watch_queue.c:251<br /> pipe_ioctl+0x82/0x140 fs/pipe.c:632<br /> vfs_ioctl fs/ioctl.c:51 [inline]<br /> __do_sys_ioctl fs/ioctl.c:874 [inline]<br /> __se_sys_ioctl fs/ioctl.c:860 [inline]<br /> __x64_sys_ioctl+0xfc/0x140 fs/ioctl.c:860<br /> do_syscall_x64 arch/x86/entry/common.c:50 [inline]