Vulnerabilities

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.

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.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> dmaengine: hisilicon: Add multi-thread support for a DMA channel<br /> <br /> When we get a DMA channel and try to use it in multiple threads it<br /> will cause oops and hanging the system.<br /> <br /> % echo 100 &gt; /sys/module/dmatest/parameters/threads_per_chan<br /> % echo 100 &gt; /sys/module/dmatest/parameters/iterations<br /> % echo 1 &gt; /sys/module/dmatest/parameters/run<br /> [383493.327077] Unable to handle kernel paging request at virtual<br /> address dead000000000108<br /> [383493.335103] Mem abort info:<br /> [383493.335103] ESR = 0x96000044<br /> [383493.335105] EC = 0x25: DABT (current EL), IL = 32 bits<br /> [383493.335107] SET = 0, FnV = 0<br /> [383493.335108] EA = 0, S1PTW = 0<br /> [383493.335109] FSC = 0x04: level 0 translation fault<br /> [383493.335110] Data abort info:<br /> [383493.335111] ISV = 0, ISS = 0x00000044<br /> [383493.364739] CM = 0, WnR = 1<br /> [383493.367793] [dead000000000108] address between user and kernel<br /> address ranges<br /> [383493.375021] Internal error: Oops: 96000044 [#1] PREEMPT SMP<br /> [383493.437574] CPU: 63 PID: 27895 Comm: dma0chan0-copy2 Kdump:<br /> loaded Tainted: GO 5.17.0-rc4+ #2<br /> [383493.457851] pstate: 204000c9 (nzCv daIF +PAN -UAO -TCO -DIT<br /> -SSBS BTYPE=--)<br /> [383493.465331] pc : vchan_tx_submit+0x64/0xa0<br /> [383493.469957] lr : vchan_tx_submit+0x34/0xa0<br /> <br /> This occurs because the transmission timed out, and that&amp;#39;s due<br /> to data race. Each thread rewrite channels&amp;#39;s descriptor as soon as<br /> device_issue_pending is called. It leads to the situation that<br /> the driver thinks that it uses the right descriptor in interrupt<br /> handler while channels&amp;#39;s descriptor has been changed by other<br /> thread. The descriptor which in fact reported interrupt will not<br /> be handled any more, as well as its tx-&gt;callback.<br /> That&amp;#39;s why timeout reports.<br /> <br /> With current fixes channels&amp;#39; descriptor changes it&amp;#39;s value only<br /> when it has been used. A new descriptor is acquired from<br /> vc-&gt;desc_issued queue that is already filled with descriptors<br /> that are ready to be sent. Threads have no direct access to DMA<br /> channel descriptor. In case of channel&amp;#39;s descriptor is busy, try<br /> to submit to HW again when a descriptor is completed. In this case,<br /> vc-&gt;desc_issued may be empty when hisi_dma_start_transfer is called,<br /> so delete error reporting on this. Now it is just possible to queue<br /> a descriptor for further processing.