Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/bridge: anx7625: Fix overflow issue on reading EDID<br /> <br /> The length of EDID block can be longer than 256 bytes, so we should use<br /> `int` instead of `u8` for the `edid_pos` variable.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> cxl/port: Hold port reference until decoder release<br /> <br /> KASAN + DEBUG_KOBJECT_RELEASE reports a potential use-after-free in<br /> cxl_decoder_release() where it goes to reference its parent, a cxl_port,<br /> to free its id back to port-&gt;decoder_ida.<br /> <br /> BUG: KASAN: use-after-free in to_cxl_port+0x18/0x90 [cxl_core]<br /> Read of size 8 at addr ffff888119270908 by task kworker/35:2/379<br /> <br /> CPU: 35 PID: 379 Comm: kworker/35:2 Tainted: G OE 5.17.0-rc2+ #198<br /> Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 0.0.0 02/06/2015<br /> Workqueue: events kobject_delayed_cleanup<br /> Call Trace:<br /> <br /> dump_stack_lvl+0x59/0x73<br /> print_address_description.constprop.0+0x1f/0x150<br /> ? to_cxl_port+0x18/0x90 [cxl_core]<br /> kasan_report.cold+0x83/0xdf<br /> ? to_cxl_port+0x18/0x90 [cxl_core]<br /> to_cxl_port+0x18/0x90 [cxl_core]<br /> cxl_decoder_release+0x2a/0x60 [cxl_core]<br /> device_release+0x5f/0x100<br /> kobject_cleanup+0x80/0x1c0<br /> <br /> The device core only guarantees parent lifetime until all children are<br /> unregistered. If a child needs a parent to complete its -&gt;release()<br /> callback that child needs to hold a reference to extend the lifetime of<br /> the parent.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> bpf, sockmap: Fix memleak in tcp_bpf_sendmsg while sk msg is full<br /> <br /> If tcp_bpf_sendmsg() is running while sk msg is full. When sk_msg_alloc()<br /> returns -ENOMEM error, tcp_bpf_sendmsg() goes to wait_for_memory. If partial<br /> memory has been alloced by sk_msg_alloc(), that is, msg_tx-&gt;sg.size is<br /> greater than osize after sk_msg_alloc(), memleak occurs. To fix we use<br /> sk_msg_trim() to release the allocated memory, then goto wait for memory.<br /> <br /> Other call paths of sk_msg_alloc() have the similar issue, such as<br /> tls_sw_sendmsg(), so handle sk_msg_trim logic inside sk_msg_alloc(),<br /> as Cong Wang suggested.<br /> <br /> This issue can cause the following info:<br /> WARNING: CPU: 3 PID: 7950 at net/core/stream.c:208 sk_stream_kill_queues+0xd4/0x1a0<br /> Call Trace:<br /> <br /> inet_csk_destroy_sock+0x55/0x110<br /> __tcp_close+0x279/0x470<br /> tcp_close+0x1f/0x60<br /> inet_release+0x3f/0x80<br /> __sock_release+0x3d/0xb0<br /> sock_close+0x11/0x20<br /> __fput+0x92/0x250<br /> task_work_run+0x6a/0xa0<br /> do_exit+0x33b/0xb60<br /> do_group_exit+0x2f/0xa0<br /> get_signal+0xb6/0x950<br /> arch_do_signal_or_restart+0xac/0x2a0<br /> exit_to_user_mode_prepare+0xa9/0x200<br /> syscall_exit_to_user_mode+0x12/0x30<br /> do_syscall_64+0x46/0x80<br /> entry_SYSCALL_64_after_hwframe+0x44/0xae<br /> <br /> <br /> WARNING: CPU: 3 PID: 2094 at net/ipv4/af_inet.c:155 inet_sock_destruct+0x13c/0x260<br /> Call Trace:<br /> <br /> __sk_destruct+0x24/0x1f0<br /> sk_psock_destroy+0x19b/0x1c0<br /> process_one_work+0x1b3/0x3c0<br /> kthread+0xe6/0x110<br /> ret_from_fork+0x22/0x30<br />

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> MIPS: pgalloc: fix memory leak caused by pgd_free()<br /> <br /> pgd page is freed by generic implementation pgd_free() since commit<br /> f9cb654cb550 ("asm-generic: pgalloc: provide generic pgd_free()"),<br /> however, there are scenarios that the system uses more than one page as<br /> the pgd table, in such cases the generic implementation pgd_free() won&amp;#39;t<br /> be applicable anymore. For example, when PAGE_SIZE_4KB is enabled and<br /> MIPS_VA_BITS_48 is not enabled in a 64bit system, the macro "PGD_ORDER"<br /> will be set as "1", which will cause allocating two pages as the pgd<br /> table. Well, at the same time, the generic implementation pgd_free()<br /> just free one pgd page, which will result in the memory leak.<br /> <br /> The memory leak can be easily detected by executing shell command:<br /> "while true; do ls &gt; /dev/null; grep MemFree /proc/meminfo; done"

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mips: cdmm: Fix refcount leak in mips_cdmm_phys_base<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 /> mtd: rawnand: atmel: fix refcount issue in atmel_nand_controller_init<br /> <br /> The reference counting issue happens in several error handling paths<br /> on a refcounted object "nc-&gt;dmac". In these paths, the function simply<br /> returns the error code, forgetting to balance the reference count of<br /> "nc-&gt;dmac", increased earlier by dma_request_channel(), which may<br /> cause refcount leaks.<br /> <br /> Fix it by decrementing the refcount of specific object in those error<br /> paths.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ath10k: Fix error handling in ath10k_setup_msa_resources<br /> <br /> The device_node pointer is returned by of_parse_phandle() with refcount<br /> incremented. We should use of_node_put() on it when done.<br /> <br /> This function only calls of_node_put() in the regular path.<br /> And it will cause refcount leak in error path.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> powerpc/64s: Don&amp;#39;t use DSISR for SLB faults<br /> <br /> Since commit 46ddcb3950a2 ("powerpc/mm: Show if a bad page fault on data<br /> is read or write.") we use page_fault_is_write(regs-&gt;dsisr) in<br /> __bad_page_fault() to determine if the fault is for a read or write, and<br /> change the message printed accordingly.<br /> <br /> But SLB faults, aka Data Segment Interrupts, don&amp;#39;t set DSISR (Data<br /> Storage Interrupt Status Register) to a useful value. All ISA versions<br /> from v2.03 through v3.1 specify that the Data Segment Interrupt sets<br /> DSISR "to an undefined value". As far as I can see there&amp;#39;s no mention of<br /> SLB faults setting DSISR in any BookIV content either.<br /> <br /> This manifests as accesses that should be a read being incorrectly<br /> reported as writes, for example, using the xmon "dump" command:<br /> <br /> 0:mon&gt; d 0x5deadbeef0000000<br /> 5deadbeef0000000<br /> [359526.415354][ C6] BUG: Unable to handle kernel data access on write at 0x5deadbeef0000000<br /> [359526.415611][ C6] Faulting instruction address: 0xc00000000010a300<br /> cpu 0x6: Vector: 380 (Data SLB Access) at [c00000000ffbf400]<br /> pc: c00000000010a300: mread+0x90/0x190<br /> <br /> If we disassemble the PC, we see a load instruction:<br /> <br /> 0:mon&gt; di c00000000010a300<br /> c00000000010a300 89490000 lbz r10,0(r9)<br /> <br /> We can also see in exceptions-64s.S that the data_access_slb block<br /> doesn&amp;#39;t set IDSISR=1, which means it doesn&amp;#39;t load DSISR into pt_regs. So<br /> the value we&amp;#39;re using to determine if the fault is a read/write is some<br /> stale value in pt_regs from a previous page fault.<br /> <br /> Rework the printing logic to separate the SLB fault case out, and only<br /> print read/write in the cases where we can determine it.<br /> <br /> The result looks like eg:<br /> <br /> 0:mon&gt; d 0x5deadbeef0000000<br /> 5deadbeef0000000<br /> [ 721.779525][ C6] BUG: Unable to handle kernel data access at 0x5deadbeef0000000<br /> [ 721.779697][ C6] Faulting instruction address: 0xc00000000014cbe0<br /> cpu 0x6: Vector: 380 (Data SLB Access) at [c00000000ffbf390]<br /> <br /> 0:mon&gt; d 0<br /> 0000000000000000<br /> [ 742.793242][ C6] BUG: Kernel NULL pointer dereference at 0x00000000<br /> [ 742.793316][ C6] Faulting instruction address: 0xc00000000014cbe0<br /> cpu 0x6: Vector: 380 (Data SLB Access) at [c00000000ffbf390]

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/tegra: Fix reference leak in tegra_dsi_ganged_probe<br /> <br /> The reference taken by &amp;#39;of_find_device_by_node()&amp;#39; must be released when<br /> not needed anymore. Add put_device() call to fix this.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> scsi: pm8001: Fix abort all task initialization<br /> <br /> In pm80xx_send_abort_all(), the n_elem field of the ccb used is not<br /> initialized to 0. This missing initialization sometimes lead to the task<br /> completion path seeing the ccb with a non-zero n_elem resulting in the<br /> execution of invalid dma_unmap_sg() calls in pm8001_ccb_task_free(),<br /> causing a crash such as:<br /> <br /> [ 197.676341] RIP: 0010:iommu_dma_unmap_sg+0x6d/0x280<br /> [ 197.700204] RSP: 0018:ffff889bbcf89c88 EFLAGS: 00010012<br /> [ 197.705485] RAX: dffffc0000000000 RBX: 0000000000000000 RCX: ffffffff83d0bda0<br /> [ 197.712687] RDX: 0000000000000002 RSI: 0000000000000000 RDI: ffff88810dffc0d0<br /> [ 197.719887] RBP: 0000000000000000 R08: 0000000000000000 R09: ffff8881c790098b<br /> [ 197.727089] R10: ffffed1038f20131 R11: 0000000000000001 R12: 0000000000000000<br /> [ 197.734296] R13: ffff88810dffc0d0 R14: 0000000000000010 R15: 0000000000000000<br /> [ 197.741493] FS: 0000000000000000(0000) GS:ffff889bbcf80000(0000) knlGS:0000000000000000<br /> [ 197.749659] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> [ 197.755459] CR2: 00007f16c1b42734 CR3: 0000000004814000 CR4: 0000000000350ee0<br /> [ 197.762656] Call Trace:<br /> [ 197.765127] <br /> [ 197.767162] pm8001_ccb_task_free+0x5f1/0x820 [pm80xx]<br /> [ 197.772364] ? do_raw_spin_unlock+0x54/0x220<br /> [ 197.776680] pm8001_mpi_task_abort_resp+0x2ce/0x4f0 [pm80xx]<br /> [ 197.782406] process_oq+0xe85/0x7890 [pm80xx]<br /> [ 197.786817] ? lock_acquire+0x194/0x490<br /> [ 197.790697] ? handle_irq_event+0x10e/0x1b0<br /> [ 197.794920] ? mpi_sata_completion+0x2d70/0x2d70 [pm80xx]<br /> [ 197.800378] ? __wake_up_bit+0x100/0x100<br /> [ 197.804340] ? lock_is_held_type+0x98/0x110<br /> [ 197.808565] pm80xx_chip_isr+0x94/0x130 [pm80xx]<br /> [ 197.813243] tasklet_action_common.constprop.0+0x24b/0x2f0<br /> [ 197.818785] __do_softirq+0x1b5/0x82d<br /> [ 197.822485] ? do_raw_spin_unlock+0x54/0x220<br /> [ 197.826799] __irq_exit_rcu+0x17e/0x1e0<br /> [ 197.830678] irq_exit_rcu+0xa/0x20<br /> [ 197.834114] common_interrupt+0x78/0x90<br /> [ 197.840051] <br /> [ 197.844236] <br /> [ 197.848397] asm_common_interrupt+0x1e/0x40<br /> <br /> Avoid this issue by always initializing the ccb n_elem field to 0 in<br /> pm8001_send_abort_all(), pm8001_send_read_log() and<br /> pm80xx_send_abort_all().

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/dp: Fix OOB read when handling Post Cursor2 register<br /> <br /> The link_status array was not large enough to read the Adjust Request<br /> Post Cursor2 register, so remove the common helper function to avoid<br /> an OOB read, found with a -Warray-bounds build:<br /> <br /> drivers/gpu/drm/drm_dp_helper.c: In function &amp;#39;drm_dp_get_adjust_request_post_cursor&amp;#39;:<br /> drivers/gpu/drm/drm_dp_helper.c:59:27: error: array subscript 10 is outside array bounds of &amp;#39;const u8[6]&amp;#39; {aka &amp;#39;const unsigned char[6]&amp;#39;} [-Werror=array-bounds]<br /> 59 | return link_status[r - DP_LANE0_1_STATUS];<br /> | ~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~<br /> drivers/gpu/drm/drm_dp_helper.c:147:51: note: while referencing &amp;#39;link_status&amp;#39;<br /> 147 | u8 drm_dp_get_adjust_request_post_cursor(const u8 link_status[DP_LINK_STATUS_SIZE],<br /> | ~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~<br /> <br /> Replace the only user of the helper with an open-coded fetch and decode,<br /> similar to drivers/gpu/drm/amd/display/dc/core/dc_link_dp.c.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> vfio/pci: fix memory leak during D3hot to D0 transition<br /> <br /> If &amp;#39;vfio_pci_core_device::needs_pm_restore&amp;#39; is set (PCI device does<br /> not have No_Soft_Reset bit set in its PMCSR config register), then<br /> the current PCI state will be saved locally in<br /> &amp;#39;vfio_pci_core_device::pm_save&amp;#39; during D0-&gt;D3hot transition and same<br /> will be restored back during D3hot-&gt;D0 transition.<br /> For saving the PCI state locally, pci_store_saved_state() is being<br /> used and the pci_load_and_free_saved_state() will free the allocated<br /> memory.<br /> <br /> But for reset related IOCTLs, vfio driver calls PCI reset-related<br /> API&amp;#39;s which will internally change the PCI power state back to D0. So,<br /> when the guest resumes, then it will get the current state as D0 and it<br /> will skip the call to vfio_pci_set_power_state() for changing the<br /> power state to D0 explicitly. In this case, the memory pointed by<br /> &amp;#39;pm_save&amp;#39; will never be freed. In a malicious sequence, the state changing<br /> to D3hot followed by VFIO_DEVICE_RESET/VFIO_DEVICE_PCI_HOT_RESET can be<br /> run in a loop and it can cause an OOM situation.<br /> <br /> This patch frees the earlier allocated memory first before overwriting<br /> &amp;#39;pm_save&amp;#39; to prevent the mentioned memory leak.