Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> skmsg: pass gfp argument to alloc_sk_msg()<br /> <br /> syzbot found that alloc_sk_msg() could be called from a<br /> non sleepable context. sk_psock_verdict_recv() uses<br /> rcu_read_lock() protection.<br /> <br /> We need the callers to pass a gfp_t argument to avoid issues.<br /> <br /> syzbot report was:<br /> <br /> BUG: sleeping function called from invalid context at include/linux/sched/mm.h:274<br /> in_atomic(): 0, irqs_disabled(): 0, non_block: 0, pid: 3613, name: syz-executor414<br /> preempt_count: 0, expected: 0<br /> RCU nest depth: 1, expected: 0<br /> INFO: lockdep is turned off.<br /> CPU: 0 PID: 3613 Comm: syz-executor414 Not tainted 6.0.0-syzkaller-09589-g55be6084c8e0 #0<br /> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/22/2022<br /> Call Trace:<br /> <br /> __dump_stack lib/dump_stack.c:88 [inline]<br /> dump_stack_lvl+0x1e3/0x2cb lib/dump_stack.c:106<br /> __might_resched+0x538/0x6a0 kernel/sched/core.c:9877<br /> might_alloc include/linux/sched/mm.h:274 [inline]<br /> slab_pre_alloc_hook mm/slab.h:700 [inline]<br /> slab_alloc_node mm/slub.c:3162 [inline]<br /> slab_alloc mm/slub.c:3256 [inline]<br /> kmem_cache_alloc_trace+0x59/0x310 mm/slub.c:3287<br /> kmalloc include/linux/slab.h:600 [inline]<br /> kzalloc include/linux/slab.h:733 [inline]<br /> alloc_sk_msg net/core/skmsg.c:507 [inline]<br /> sk_psock_skb_ingress_self+0x5c/0x330 net/core/skmsg.c:600<br /> sk_psock_verdict_apply+0x395/0x440 net/core/skmsg.c:1014<br /> sk_psock_verdict_recv+0x34d/0x560 net/core/skmsg.c:1201<br /> tcp_read_skb+0x4a1/0x790 net/ipv4/tcp.c:1770<br /> tcp_rcv_established+0x129d/0x1a10 net/ipv4/tcp_input.c:5971<br /> tcp_v4_do_rcv+0x479/0xac0 net/ipv4/tcp_ipv4.c:1681<br /> sk_backlog_rcv include/net/sock.h:1109 [inline]<br /> __release_sock+0x1d8/0x4c0 net/core/sock.c:2906<br /> release_sock+0x5d/0x1c0 net/core/sock.c:3462<br /> tcp_sendmsg+0x36/0x40 net/ipv4/tcp.c:1483<br /> sock_sendmsg_nosec net/socket.c:714 [inline]<br /> sock_sendmsg net/socket.c:734 [inline]<br /> __sys_sendto+0x46d/0x5f0 net/socket.c:2117<br /> __do_sys_sendto net/socket.c:2129 [inline]<br /> __se_sys_sendto net/socket.c:2125 [inline]<br /> __x64_sys_sendto+0xda/0xf0 net/socket.c:2125<br /> do_syscall_x64 arch/x86/entry/common.c:50 [inline]<br /> do_syscall_64+0x2b/0x70 arch/x86/entry/common.c:80<br /> entry_SYSCALL_64_after_hwframe+0x63/0xcd

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> i2c: mux: reg: check return value after calling platform_get_resource()<br /> <br /> It will cause null-ptr-deref in resource_size(), if platform_get_resource()<br /> returns NULL, move calling resource_size() after devm_ioremap_resource() that<br /> will check &amp;#39;res&amp;#39; to avoid null-ptr-deref.<br /> And use devm_platform_get_and_ioremap_resource() to simplify code.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> skbuff: Account for tail adjustment during pull operations<br /> <br /> Extending the tail can have some unexpected side effects if a program uses<br /> a helper like BPF_FUNC_skb_pull_data to read partial content beyond the<br /> head skb headlen when all the skbs in the gso frag_list are linear with no<br /> head_frag -<br /> <br /> kernel BUG at net/core/skbuff.c:4219!<br /> pc : skb_segment+0xcf4/0xd2c<br /> lr : skb_segment+0x63c/0xd2c<br /> Call trace:<br /> skb_segment+0xcf4/0xd2c<br /> __udp_gso_segment+0xa4/0x544<br /> udp4_ufo_fragment+0x184/0x1c0<br /> inet_gso_segment+0x16c/0x3a4<br /> skb_mac_gso_segment+0xd4/0x1b0<br /> __skb_gso_segment+0xcc/0x12c<br /> udp_rcv_segment+0x54/0x16c<br /> udp_queue_rcv_skb+0x78/0x144<br /> udp_unicast_rcv_skb+0x8c/0xa4<br /> __udp4_lib_rcv+0x490/0x68c<br /> udp_rcv+0x20/0x30<br /> ip_protocol_deliver_rcu+0x1b0/0x33c<br /> ip_local_deliver+0xd8/0x1f0<br /> ip_rcv+0x98/0x1a4<br /> deliver_ptype_list_skb+0x98/0x1ec<br /> __netif_receive_skb_core+0x978/0xc60<br /> <br /> Fix this by marking these skbs as GSO_DODGY so segmentation can handle<br /> the tail updates accordingly.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> powercap: intel_rapl: fix UBSAN shift-out-of-bounds issue<br /> <br /> When value

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> fs: fix UAF/GPF bug in nilfs_mdt_destroy<br /> <br /> In alloc_inode, inode_init_always() could return -ENOMEM if<br /> security_inode_alloc() fails, which causes inode-&gt;i_private<br /> uninitialized. Then nilfs_is_metadata_file_inode() returns<br /> true and nilfs_free_inode() wrongly calls nilfs_mdt_destroy(),<br /> which frees the uninitialized inode-&gt;i_private<br /> and leads to crashes(e.g., UAF/GPF).<br /> <br /> Fix this by moving security_inode_alloc just prior to<br /> this_cpu_inc(nr_inodes)

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/msm/dsi: fix memory corruption with too many bridges<br /> <br /> Add the missing sanity check on the bridge counter to avoid corrupting<br /> data beyond the fixed-sized bridge array in case there are ever more<br /> than eight bridges.<br /> <br /> Patchwork: https://patchwork.freedesktop.org/patch/502668/

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/vkms: Fix null-ptr-deref in vkms_release()<br /> <br /> A null-ptr-deref is triggered when it tries to destroy the workqueue in<br /> vkms-&gt;output.composer_workq in vkms_release().<br /> <br /> KASAN: null-ptr-deref in range [0x0000000000000118-0x000000000000011f]<br /> CPU: 5 PID: 17193 Comm: modprobe Not tainted 6.0.0-11331-gd465bff130bf #24<br /> RIP: 0010:destroy_workqueue+0x2f/0x710<br /> ...<br /> Call Trace:<br /> <br /> ? vkms_config_debugfs_init+0x50/0x50 [vkms]<br /> __devm_drm_dev_alloc+0x15a/0x1c0 [drm]<br /> vkms_init+0x245/0x1000 [vkms]<br /> do_one_initcall+0xd0/0x4f0<br /> do_init_module+0x1a4/0x680<br /> load_module+0x6249/0x7110<br /> __do_sys_finit_module+0x140/0x200<br /> do_syscall_64+0x35/0x80<br /> entry_SYSCALL_64_after_hwframe+0x46/0xb0<br /> <br /> The reason is that an OOM happened which triggers the destroy of the<br /> workqueue, however, the workqueue is alloced in the later process,<br /> thus a null-ptr-deref happened. A simple call graph is shown as below:<br /> <br /> vkms_init()<br /> vkms_create()<br /> devm_drm_dev_alloc()<br /> __devm_drm_dev_alloc()<br /> devm_drm_dev_init()<br /> devm_add_action_or_reset()<br /> devm_add_action() # an error happened<br /> devm_drm_dev_init_release()<br /> drm_dev_put()<br /> kref_put()<br /> drm_dev_release()<br /> vkms_release()<br /> destroy_workqueue() # null-ptr-deref happened<br /> vkms_modeset_init()<br /> vkms_output_init()<br /> vkms_crtc_init() # where the workqueue get allocated<br /> <br /> Fix this by checking if composer_workq is NULL before passing it to<br /> the destroy_workqueue() in vkms_release().

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> i2c: designware: Fix handling of real but unexpected device interrupts<br /> <br /> Commit c7b79a752871 ("mfd: intel-lpss: Add Intel Alder Lake PCH-S PCI<br /> IDs") caused a regression on certain Gigabyte motherboards for Intel<br /> Alder Lake-S where system crashes to NULL pointer dereference in<br /> i2c_dw_xfer_msg() when system resumes from S3 sleep state ("deep").<br /> <br /> I was able to debug the issue on Gigabyte Z690 AORUS ELITE and made<br /> following notes:<br /> <br /> - Issue happens when resuming from S3 but not when resuming from<br /> "s2idle"<br /> - PCI device 00:15.0 == i2c_designware.0 is already in D0 state when<br /> system enters into pci_pm_resume_noirq() while all other i2c_designware<br /> PCI devices are in D3. Devices were runtime suspended and in D3 prior<br /> entering into suspend<br /> - Interrupt comes after pci_pm_resume_noirq() when device interrupts are<br /> re-enabled<br /> - According to register dump the interrupt really comes from the<br /> i2c_designware.0. Controller is enabled, I2C target address register<br /> points to a one detectable I2C device address 0x60 and the<br /> DW_IC_RAW_INTR_STAT register START_DET, STOP_DET, ACTIVITY and<br /> TX_EMPTY bits are set indicating completed I2C transaction.<br /> <br /> My guess is that the firmware uses this controller to communicate with<br /> an on-board I2C device during resume but does not disable the controller<br /> before giving control to an operating system.<br /> <br /> I was told the UEFI update fixes this but never the less it revealed the<br /> driver is not ready to handle TX_EMPTY (or RX_FULL) interrupt when device<br /> is supposed to be idle and state variables are not set (especially the<br /> dev-&gt;msgs pointer which may point to NULL or stale old data).<br /> <br /> Introduce a new software status flag STATUS_ACTIVE indicating when the<br /> controller is active in driver point of view. Now treat all interrupts<br /> that occur when is not set as unexpected and mask all interrupts from<br /> the controller.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/amdkfd: Fix kfd_process_device_init_vm error handling<br /> <br /> Should only destroy the ib_mem and let process cleanup worker to free<br /> the outstanding BOs. Reset the pointer in pdd-&gt;qpd structure, to avoid<br /> NULL pointer access in process destroy worker.<br /> <br /> BUG: kernel NULL pointer dereference, address: 0000000000000010<br /> Call Trace:<br /> amdgpu_amdkfd_gpuvm_unmap_gtt_bo_from_kernel+0x46/0xb0 [amdgpu]<br /> kfd_process_device_destroy_cwsr_dgpu+0x40/0x70 [amdgpu]<br /> kfd_process_destroy_pdds+0x71/0x190 [amdgpu]<br /> kfd_process_wq_release+0x2a2/0x3b0 [amdgpu]<br /> process_one_work+0x2a1/0x600<br /> worker_thread+0x39/0x3d0

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> staging: vt6655: fix some erroneous memory clean-up loops<br /> <br /> In some initialization functions of this driver, memory is allocated with<br /> &amp;#39;i&amp;#39; acting as an index variable and increasing from 0. The commit in<br /> "Fixes" introduces some clean-up codes in case of allocation failure,<br /> which free memory in reverse order with &amp;#39;i&amp;#39; decreasing to 0. However,<br /> there are some problems:<br /> - The case i=0 is left out. Thus memory is leaked.<br /> - In case memory allocation fails right from the start, the memory<br /> freeing loops will start with i=-1 and invalid memory locations will<br /> be accessed.<br /> <br /> One of these loops has been fixed in commit c8ff91535880 ("staging:<br /> vt6655: fix potential memory leak"). Fix the remaining erroneous loops.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: sched: sfb: fix null pointer access issue when sfb_init() fails<br /> <br /> When the default qdisc is sfb, if the qdisc of dev_queue fails to be<br /> inited during mqprio_init(), sfb_reset() is invoked to clear resources.<br /> In this case, the q-&gt;qdisc is NULL, and it will cause gpf issue.<br /> <br /> The process is as follows:<br /> qdisc_create_dflt()<br /> sfb_init()<br /> tcf_block_get() ---&gt;failed, q-&gt;qdisc is NULL<br /> ...<br /> qdisc_put()<br /> ...<br /> sfb_reset()<br /> qdisc_reset(q-&gt;qdisc) ---&gt;q-&gt;qdisc is NULL<br /> ops = qdisc-&gt;ops<br /> <br /> The following is the Call Trace information:<br /> general protection fault, probably for non-canonical address<br /> 0xdffffc0000000003: 0000 [#1] PREEMPT SMP KASAN<br /> KASAN: null-ptr-deref in range [0x0000000000000018-0x000000000000001f]<br /> RIP: 0010:qdisc_reset+0x2b/0x6f0<br /> Call Trace:<br /> <br /> sfb_reset+0x37/0xd0<br /> qdisc_reset+0xed/0x6f0<br /> qdisc_destroy+0x82/0x4c0<br /> qdisc_put+0x9e/0xb0<br /> qdisc_create_dflt+0x2c3/0x4a0<br /> mqprio_init+0xa71/0x1760<br /> qdisc_create+0x3eb/0x1000<br /> tc_modify_qdisc+0x408/0x1720<br /> rtnetlink_rcv_msg+0x38e/0xac0<br /> netlink_rcv_skb+0x12d/0x3a0<br /> netlink_unicast+0x4a2/0x740<br /> netlink_sendmsg+0x826/0xcc0<br /> sock_sendmsg+0xc5/0x100<br /> ____sys_sendmsg+0x583/0x690<br /> ___sys_sendmsg+0xe8/0x160<br /> __sys_sendmsg+0xbf/0x160<br /> do_syscall_64+0x35/0x80<br /> entry_SYSCALL_64_after_hwframe+0x46/0xb0<br /> RIP: 0033:0x7f2164122d04<br />

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> usb: dwc3: core: fix some leaks in probe<br /> <br /> The dwc3_get_properties() function calls:<br /> <br /> dwc-&gt;usb_psy = power_supply_get_by_name(usb_psy_name);<br /> <br /> so there is some additional clean up required on these error paths.