Vulnerabilities

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 /> 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 /> 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 /> 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.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> brcmfmac: return error when getting invalid max_flowrings from dongle<br /> <br /> When firmware hit trap at initialization, host will read abnormal<br /> max_flowrings number from dongle, and it will cause kernel panic when<br /> doing iowrite to initialize dongle ring.<br /> To detect this error at early stage, we directly return error when getting<br /> invalid max_flowrings(&gt;256).

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> media: cx88: Fix a null-ptr-deref bug in buffer_prepare()<br /> <br /> When the driver calls cx88_risc_buffer() to prepare the buffer, the<br /> function call may fail, resulting in a empty buffer and null-ptr-deref<br /> later in buffer_queue().<br /> <br /> The following log can reveal it:<br /> <br /> [ 41.822762] general protection fault, probably for non-canonical address 0xdffffc0000000000: 0000 [#1] PREEMPT SMP KASAN PTI<br /> [ 41.824488] KASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007]<br /> [ 41.828027] RIP: 0010:buffer_queue+0xc2/0x500<br /> [ 41.836311] Call Trace:<br /> [ 41.836945] __enqueue_in_driver+0x141/0x360<br /> [ 41.837262] vb2_start_streaming+0x62/0x4a0<br /> [ 41.838216] vb2_core_streamon+0x1da/0x2c0<br /> [ 41.838516] __vb2_init_fileio+0x981/0xbc0<br /> [ 41.839141] __vb2_perform_fileio+0xbf9/0x1120<br /> [ 41.840072] vb2_fop_read+0x20e/0x400<br /> [ 41.840346] v4l2_read+0x215/0x290<br /> [ 41.840603] vfs_read+0x162/0x4c0<br /> <br /> Fix this by checking the return value of cx88_risc_buffer()<br /> <br /> [hverkuil: fix coding style issues]

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/msm/dp: fix aux-bus EP lifetime<br /> <br /> Device-managed resources allocated post component bind must be tied to<br /> the lifetime of the aggregate DRM device or they will not necessarily be<br /> released when binding of the aggregate device is deferred.<br /> <br /> This can lead resource leaks or failure to bind the aggregate device<br /> when binding is later retried and a second attempt to allocate the<br /> resources is made.<br /> <br /> For the DP aux-bus, an attempt to populate the bus a second time will<br /> simply fail ("DP AUX EP device already populated").<br /> <br /> Fix this by tying the lifetime of the EP device to the DRM device rather<br /> than DP controller platform device.<br /> <br /> Patchwork: https://patchwork.freedesktop.org/patch/502672/

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> wifi: wilc1000: add missing unregister_netdev() in wilc_netdev_ifc_init()<br /> <br /> Fault injection test reports this issue:<br /> <br /> kernel BUG at net/core/dev.c:10731!<br /> invalid opcode: 0000 [#1] PREEMPT SMP KASAN PTI<br /> Call Trace:<br /> <br /> wilc_netdev_ifc_init+0x19f/0x220 [wilc1000 884bf126e9e98af6a708f266a8dffd53f99e4bf5]<br /> wilc_cfg80211_init+0x30c/0x380 [wilc1000 884bf126e9e98af6a708f266a8dffd53f99e4bf5]<br /> wilc_bus_probe+0xad/0x2b0 [wilc1000_spi 1520a7539b6589cc6cde2ae826a523a33f8bacff]<br /> spi_probe+0xe4/0x140<br /> really_probe+0x17e/0x3f0<br /> __driver_probe_device+0xe3/0x170<br /> driver_probe_device+0x49/0x120<br /> <br /> The root case here is alloc_ordered_workqueue() fails, but<br /> cfg80211_unregister_netdevice() or unregister_netdev() not be called in<br /> error handling path. To fix add unregister_netdev goto lable to add the<br /> unregister operation in error handling path.