Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> media: imx-jpeg: Prevent decoding NV12M jpegs into single-planar buffers<br /> <br /> If the application queues an NV12M jpeg as output buffer, but then<br /> queues a single planar capture buffer, the kernel will crash with<br /> "Unable to handle kernel NULL pointer dereference" in mxc_jpeg_addrs,<br /> prevent this by finishing the job with error.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ntfs: add sanity check on allocation size<br /> <br /> ntfs_read_inode_mount invokes ntfs_malloc_nofs with zero allocation<br /> size. It triggers one BUG in the __ntfs_malloc function.<br /> <br /> Fix this by adding sanity check on ni-&gt;attr_list_size.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> btrfs: do not double complete bio on errors during compressed reads<br /> <br /> I hit some weird panics while fixing up the error handling from<br /> btrfs_lookup_bio_sums(). Turns out the compression path will complete<br /> the bio we use if we set up any of the compression bios and then return<br /> an error, and then btrfs_submit_data_bio() will also call bio_endio() on<br /> the bio.<br /> <br /> Fix this by making btrfs_submit_compressed_read() responsible for<br /> calling bio_endio() on the bio if there are any errors. Currently it<br /> was only doing it if we created the compression bios, otherwise it was<br /> depending on btrfs_submit_data_bio() to do the right thing. This<br /> creates the above problem, so fix up btrfs_submit_compressed_read() to<br /> always call bio_endio() in case of an error, and then simply return from<br /> btrfs_submit_data_bio() if we had to call<br /> btrfs_submit_compressed_read().

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> btrfs: do not clean up repair bio if submit fails<br /> <br /> The submit helper will always run bio_endio() on the bio if it fails to<br /> submit, so cleaning up the bio just leads to a variety of use-after-free<br /> and NULL pointer dereference bugs because we race with the endio<br /> function that is cleaning up the bio. Instead just return BLK_STS_OK as<br /> the repair function has to continue to process the rest of the pages,<br /> and the endio for the repair bio will do the appropriate cleanup for the<br /> page that it was given.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> wireguard: socket: free skb in send6 when ipv6 is disabled<br /> <br /> I got a memory leak report:<br /> <br /> unreferenced object 0xffff8881191fc040 (size 232):<br /> comm "kworker/u17:0", pid 23193, jiffies 4295238848 (age 3464.870s)<br /> hex dump (first 32 bytes):<br /> 00 00 00 00 00 00 00 00 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 /> [] slab_post_alloc_hook+0x84/0x3b0<br /> [] kmem_cache_alloc_node+0x167/0x340<br /> [] __alloc_skb+0x1db/0x200<br /> [] wg_socket_send_buffer_to_peer+0x3d/0xc0<br /> [] wg_packet_send_handshake_initiation+0xfa/0x110<br /> [] wg_packet_handshake_send_worker+0x21/0x30<br /> [] process_one_work+0x2e8/0x770<br /> [] worker_thread+0x4a/0x4b0<br /> [] kthread+0x120/0x160<br /> [] ret_from_fork+0x1f/0x30<br /> <br /> In function wg_socket_send_buffer_as_reply_to_skb() or wg_socket_send_<br /> buffer_to_peer(), the semantics of send6() is required to free skb. But<br /> when CONFIG_IPV6 is disable, kfree_skb() is missing. This patch adds it<br /> to fix this bug.

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]