Vulnerabilities

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 /> 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 /> 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: 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 /> 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]

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 /> Bluetooth: hci_event: Ignore multiple conn complete events<br /> <br /> When one of the three connection complete events is received multiple<br /> times for the same handle, the device is registered multiple times which<br /> leads to memory corruptions. Therefore, consequent events for a single<br /> connection are ignored.<br /> <br /> The conn-&gt;state can hold different values, therefore HCI_CONN_HANDLE_UNSET<br /> is introduced to identify new connections. To make sure the events do not<br /> contain this or another invalid handle HCI_CONN_HANDLE_MAX and checks<br /> are introduced.<br /> <br /> Buglink: https://bugzilla.kernel.org/show_bug.cgi?id=215497

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.

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 /> 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 /> net: preserve skb_end_offset() in skb_unclone_keeptruesize()<br /> <br /> syzbot found another way to trigger the infamous WARN_ON_ONCE(delta truesize value,<br /> we also need to make sure TCP wont fill new tailroom<br /> that pskb_expand_head() was able to get from a<br /> addr = kmalloc(...) followed by ksize(addr)<br /> <br /> Split skb_unclone_keeptruesize() into two parts:<br /> <br /> 1) Inline skb_unclone_keeptruesize() for the common case,<br /> when skb is not cloned.<br /> <br /> 2) Out of line __skb_unclone_keeptruesize() for the &amp;#39;slow path&amp;#39;.<br /> <br /> WARNING: CPU: 1 PID: 6490 at net/core/skbuff.c:5295 skb_try_coalesce+0x1235/0x1560 net/core/skbuff.c:5295<br /> Modules linked in:<br /> CPU: 1 PID: 6490 Comm: syz-executor161 Not tainted 5.17.0-rc4-syzkaller-00229-g4f12b742eb2b #0<br /> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011<br /> RIP: 0010:skb_try_coalesce+0x1235/0x1560 net/core/skbuff.c:5295<br /> Code: bf 01 00 00 00 0f b7 c0 89 c6 89 44 24 20 e8 62 24 4e fa 8b 44 24 20 83 e8 01 0f 85 e5 f0 ff ff e9 87 f4 ff ff e8 cb 20 4e fa 0b e9 06 f9 ff ff e8 af b2 95 fa e9 69 f0 ff ff e8 95 b2 95 fa<br /> RSP: 0018:ffffc900063af268 EFLAGS: 00010293<br /> RAX: 0000000000000000 RBX: 00000000ffffffd5 RCX: 0000000000000000<br /> RDX: ffff88806fc05700 RSI: ffffffff872abd55 RDI: 0000000000000003<br /> RBP: ffff88806e675500 R08: 00000000ffffffd5 R09: 0000000000000000<br /> R10: ffffffff872ab659 R11: 0000000000000000 R12: ffff88806dd554e8<br /> R13: ffff88806dd9bac0 R14: ffff88806dd9a2c0 R15: 0000000000000155<br /> FS: 00007f18014f9700(0000) GS:ffff8880b9c00000(0000) knlGS:0000000000000000<br /> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> CR2: 0000000020002000 CR3: 000000006be7a000 CR4: 00000000003506f0<br /> DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000<br /> DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400<br /> Call Trace:<br /> <br /> tcp_try_coalesce net/ipv4/tcp_input.c:4651 [inline]<br /> tcp_try_coalesce+0x393/0x920 net/ipv4/tcp_input.c:4630<br /> tcp_queue_rcv+0x8a/0x6e0 net/ipv4/tcp_input.c:4914<br /> tcp_data_queue+0x11fd/0x4bb0 net/ipv4/tcp_input.c:5025<br /> tcp_rcv_established+0x81e/0x1ff0 net/ipv4/tcp_input.c:5947<br /> tcp_v4_do_rcv+0x65e/0x980 net/ipv4/tcp_ipv4.c:1719<br /> sk_backlog_rcv include/net/sock.h:1037 [inline]<br /> __release_sock+0x134/0x3b0 net/core/sock.c:2779<br /> release_sock+0x54/0x1b0 net/core/sock.c:3311<br /> sk_wait_data+0x177/0x450 net/core/sock.c:2821<br /> tcp_recvmsg_locked+0xe28/0x1fd0 net/ipv4/tcp.c:2457<br /> tcp_recvmsg+0x137/0x610 net/ipv4/tcp.c:2572<br /> inet_recvmsg+0x11b/0x5e0 net/ipv4/af_inet.c:850<br /> sock_recvmsg_nosec net/socket.c:948 [inline]<br /> sock_recvmsg net/socket.c:966 [inline]<br /> sock_recvmsg net/socket.c:962 [inline]<br /> ____sys_recvmsg+0x2c4/0x600 net/socket.c:2632<br /> ___sys_recvmsg+0x127/0x200 net/socket.c:2674<br /> __sys_recvmsg+0xe2/0x1a0 net/socket.c:2704<br /> do_syscall_x64 arch/x86/entry/common.c:50 [inline]<br /> do_syscall_64+0x35/0xb0 arch/x86/entry/common.c:80<br /> entry_SYSCALL_64_after_hwframe+0x44/0xae