Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ixgbe: fix pci device refcount leak<br /> <br /> As the comment of pci_get_domain_bus_and_slot() says, it<br /> returns a PCI device with refcount incremented, when finish<br /> using it, the caller must decrement the reference count by<br /> calling pci_dev_put().<br /> <br /> In ixgbe_get_first_secondary_devfn() and ixgbe_x550em_a_has_mii(),<br /> pci_dev_put() is called to avoid leak.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> arm64/mm: fix incorrect file_map_count for invalid pmd<br /> <br /> The page table check trigger BUG_ON() unexpectedly when split hugepage:<br /> <br /> ------------[ cut here ]------------<br /> kernel BUG at mm/page_table_check.c:119!<br /> Internal error: Oops - BUG: 00000000f2000800 [#1] SMP<br /> Dumping ftrace buffer:<br /> (ftrace buffer empty)<br /> Modules linked in:<br /> CPU: 7 PID: 210 Comm: transhuge-stres Not tainted 6.1.0-rc3+ #748<br /> Hardware name: linux,dummy-virt (DT)<br /> pstate: 20000005 (nzCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)<br /> pc : page_table_check_set.isra.0+0x398/0x468<br /> lr : page_table_check_set.isra.0+0x1c0/0x468<br /> [...]<br /> Call trace:<br /> page_table_check_set.isra.0+0x398/0x468<br /> __page_table_check_pte_set+0x160/0x1c0<br /> __split_huge_pmd_locked+0x900/0x1648<br /> __split_huge_pmd+0x28c/0x3b8<br /> unmap_page_range+0x428/0x858<br /> unmap_single_vma+0xf4/0x1c8<br /> zap_page_range+0x2b0/0x410<br /> madvise_vma_behavior+0xc44/0xe78<br /> do_madvise+0x280/0x698<br /> __arm64_sys_madvise+0x90/0xe8<br /> invoke_syscall.constprop.0+0xdc/0x1d8<br /> do_el0_svc+0xf4/0x3f8<br /> el0_svc+0x58/0x120<br /> el0t_64_sync_handler+0xb8/0xc0<br /> el0t_64_sync+0x19c/0x1a0<br /> [...]<br /> <br /> On arm64, pmd_leaf() will return true even if the pmd is invalid due to<br /> pmd_present_invalid() check. So in pmdp_invalidate() the file_map_count<br /> will not only decrease once but also increase once. Then in set_pte_at(),<br /> the file_map_count increase again, and so trigger BUG_ON() unexpectedly.<br /> <br /> Add !pmd_present_invalid() check in pmd_user_accessible_page() to fix the<br /> problem.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/msm/dp: do not complete dp_aux_cmd_fifo_tx() if irq is not for aux transfer<br /> <br /> There are 3 possible interrupt sources are handled by DP controller,<br /> HPDstatus, Controller state changes and Aux read/write transaction.<br /> At every irq, DP controller have to check isr status of every interrupt<br /> sources and service the interrupt if its isr status bits shows interrupts<br /> are pending. There is potential race condition may happen at current aux<br /> isr handler implementation since it is always complete dp_aux_cmd_fifo_tx()<br /> even irq is not for aux read or write transaction. This may cause aux read<br /> transaction return premature if host aux data read is in the middle of<br /> waiting for sink to complete transferring data to host while irq happen.<br /> This will cause host&amp;#39;s receiving buffer contains unexpected data. This<br /> patch fixes this problem by checking aux isr and return immediately at<br /> aux isr handler if there are no any isr status bits set.<br /> <br /> Current there is a bug report regrading eDP edid corruption happen during<br /> system booting up. After lengthy debugging to found that VIDEO_READY<br /> interrupt was continuously firing during system booting up which cause<br /> dp_aux_isr() to complete dp_aux_cmd_fifo_tx() prematurely to retrieve data<br /> from aux hardware buffer which is not yet contains complete data transfer<br /> from sink. This cause edid corruption.<br /> <br /> Follows are the signature at kernel logs when problem happen,<br /> EDID has corrupt header<br /> panel-simple-dp-aux aux-aea0000.edp: Couldn&amp;#39;t identify panel via EDID<br /> <br /> Changes in v2:<br /> -- do complete if (ret == IRQ_HANDLED) ay dp-aux_isr()<br /> -- add more commit text<br /> <br /> Changes in v3:<br /> -- add Stephen suggested<br /> -- dp_aux_isr() return IRQ_XXX back to caller<br /> -- dp_ctrl_isr() return IRQ_XXX back to caller<br /> <br /> Changes in v4:<br /> -- split into two patches<br /> <br /> Changes in v5:<br /> -- delete empty line between tags<br /> <br /> Changes in v6:<br /> -- remove extra "that" and fixed line more than 75 char at commit text<br /> <br /> Patchwork: https://patchwork.freedesktop.org/patch/516121/

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/virtio: Fix GEM handle creation UAF<br /> <br /> Userspace can guess the handle value and try to race GEM object creation<br /> with handle close, resulting in a use-after-free if we dereference the<br /> object after dropping the handle&amp;#39;s reference. For that reason, dropping<br /> the handle&amp;#39;s reference must be done *after* we are done dereferencing<br /> the object.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> gsmi: fix null-deref in gsmi_get_variable<br /> <br /> We can get EFI variables without fetching the attribute, so we must<br /> allow for that in gsmi.<br /> <br /> commit 859748255b43 ("efi: pstore: Omit efivars caching EFI varstore<br /> access layer") added a new get_variable call with attr=NULL, which<br /> triggers panic in gsmi.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> usb: gadget: f_ncm: fix potential NULL ptr deref in ncm_bitrate()<br /> <br /> In Google internal bug 265639009 we&amp;#39;ve received an (as yet) unreproducible<br /> crash report from an aarch64 GKI 5.10.149-android13 running device.<br /> <br /> AFAICT the source code is at:<br /> https://android.googlesource.com/kernel/common/+/refs/tags/ASB-2022-12-05_13-5.10<br /> <br /> The call stack is:<br /> ncm_close() -&gt; ncm_notify() -&gt; ncm_do_notify()<br /> with the crash at:<br /> ncm_do_notify+0x98/0x270<br /> Code: 79000d0b b9000a6c f940012a f9400269 (b9405d4b)<br /> <br /> Which I believe disassembles to (I don&amp;#39;t know ARM assembly, but it looks sane enough to me...):<br /> <br /> // halfword (16-bit) store presumably to event-&gt;wLength (at offset 6 of struct usb_cdc_notification)<br /> 0B 0D 00 79 strh w11, [x8, #6]<br /> <br /> // word (32-bit) store presumably to req-&gt;Length (at offset 8 of struct usb_request)<br /> 6C 0A 00 B9 str w12, [x19, #8]<br /> <br /> // x10 (NULL) was read here from offset 0 of valid pointer x9<br /> // IMHO we&amp;#39;re reading &amp;#39;cdev-&gt;gadget&amp;#39; and getting NULL<br /> // gadget is indeed at offset 0 of struct usb_composite_dev<br /> 2A 01 40 F9 ldr x10, [x9]<br /> <br /> // loading req-&gt;buf pointer, which is at offset 0 of struct usb_request<br /> 69 02 40 F9 ldr x9, [x19]<br /> <br /> // x10 is null, crash, appears to be attempt to read cdev-&gt;gadget-&gt;max_speed<br /> 4B 5D 40 B9 ldr w11, [x10, #0x5c]<br /> <br /> which seems to line up with ncm_do_notify() case NCM_NOTIFY_SPEED code fragment:<br /> <br /> event-&gt;wLength = cpu_to_le16(8);<br /> req-&gt;length = NCM_STATUS_BYTECOUNT;<br /> <br /> /* SPEED_CHANGE data is up/down speeds in bits/sec */<br /> data = req-&gt;buf + sizeof *event;<br /> data[0] = cpu_to_le32(ncm_bitrate(cdev-&gt;gadget));<br /> <br /> My analysis of registers and NULL ptr deref crash offset<br /> (Unable to handle kernel NULL pointer dereference at virtual address 000000000000005c)<br /> heavily suggests that the crash is due to &amp;#39;cdev-&gt;gadget&amp;#39; being NULL when executing:<br /> data[0] = cpu_to_le32(ncm_bitrate(cdev-&gt;gadget));<br /> which calls:<br /> ncm_bitrate(NULL)<br /> which then calls:<br /> gadget_is_superspeed(NULL)<br /> which reads<br /> ((struct usb_gadget *)NULL)-&gt;max_speed<br /> and hits a panic.<br /> <br /> AFAICT, if I&amp;#39;m counting right, the offset of max_speed is indeed 0x5C.<br /> (remember there&amp;#39;s a GKI KABI reservation of 16 bytes in struct work_struct)<br /> <br /> It&amp;#39;s not at all clear to me how this is all supposed to work...<br /> but returning 0 seems much better than panic-ing...

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/i915/gt: Cleanup partial engine discovery failures<br /> <br /> If we abort driver initialisation in the middle of gt/engine discovery,<br /> some engines will be fully setup and some not. Those incompletely setup<br /> engines only have &amp;#39;engine-&gt;release == NULL&amp;#39; and so will leak any of the<br /> common objects allocated.<br /> <br /> v2:<br /> - Drop the destroy_pinned_context() helper for now. It&amp;#39;s not really<br /> worth it with just a single callsite at the moment. (Janusz)

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> dmaengine: idxd: Let probe fail when workqueue cannot be enabled<br /> <br /> The workqueue is enabled when the appropriate driver is loaded and<br /> disabled when the driver is removed. When the driver is removed it<br /> assumes that the workqueue was enabled successfully and proceeds to<br /> free allocations made during workqueue enabling.<br /> <br /> Failure during workqueue enabling does not prevent the driver from<br /> being loaded. This is because the error path within drv_enable_wq()<br /> returns success unless a second failure is encountered<br /> during the error path. By returning success it is possible to load<br /> the driver even if the workqueue cannot be enabled and<br /> allocations that do not exist are attempted to be freed during<br /> driver remove.<br /> <br /> Some examples of problematic flows:<br /> (a)<br /> <br /> idxd_dmaengine_drv_probe() -&gt; drv_enable_wq() -&gt; idxd_wq_request_irq():<br /> In above flow, if idxd_wq_request_irq() fails then<br /> idxd_wq_unmap_portal() is called on error exit path, but<br /> drv_enable_wq() returns 0 because idxd_wq_disable() succeeds. The<br /> driver is thus loaded successfully.<br /> <br /> idxd_dmaengine_drv_remove()-&gt;drv_disable_wq()-&gt;idxd_wq_unmap_portal()<br /> Above flow on driver unload triggers the WARN in devm_iounmap() because<br /> the device resource has already been removed during error path of<br /> drv_enable_wq().<br /> <br /> (b)<br /> <br /> idxd_dmaengine_drv_probe() -&gt; drv_enable_wq() -&gt; idxd_wq_request_irq():<br /> In above flow, if idxd_wq_request_irq() fails then<br /> idxd_wq_init_percpu_ref() is never called to initialize the percpu<br /> counter, yet the driver loads successfully because drv_enable_wq()<br /> returns 0.<br /> <br /> idxd_dmaengine_drv_remove()-&gt;__idxd_wq_quiesce()-&gt;percpu_ref_kill():<br /> Above flow on driver unload triggers a BUG when attempting to drop the<br /> initial ref of the uninitialized percpu ref:<br /> BUG: kernel NULL pointer dereference, address: 0000000000000010<br /> <br /> Fix the drv_enable_wq() error path by returning the original error that<br /> indicates failure of workqueue enabling. This ensures that the probe<br /> fails when an error is encountered and the driver remove paths are only<br /> attempted when the workqueue was enabled successfully.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> USB: gadgetfs: Fix race between mounting and unmounting<br /> <br /> The syzbot fuzzer and Gerald Lee have identified a use-after-free bug<br /> in the gadgetfs driver, involving processes concurrently mounting and<br /> unmounting the gadgetfs filesystem. In particular, gadgetfs_fill_super()<br /> can race with gadgetfs_kill_sb(), causing the latter to deallocate<br /> the_device while the former is using it. The output from KASAN says,<br /> in part:<br /> <br /> BUG: KASAN: use-after-free in instrument_atomic_read_write include/linux/instrumented.h:102 [inline]<br /> BUG: KASAN: use-after-free in atomic_fetch_sub_release include/linux/atomic/atomic-instrumented.h:176 [inline]<br /> BUG: KASAN: use-after-free in __refcount_sub_and_test include/linux/refcount.h:272 [inline]<br /> BUG: KASAN: use-after-free in __refcount_dec_and_test include/linux/refcount.h:315 [inline]<br /> BUG: KASAN: use-after-free in refcount_dec_and_test include/linux/refcount.h:333 [inline]<br /> BUG: KASAN: use-after-free in put_dev drivers/usb/gadget/legacy/inode.c:159 [inline]<br /> BUG: KASAN: use-after-free in gadgetfs_kill_sb+0x33/0x100 drivers/usb/gadget/legacy/inode.c:2086<br /> Write of size 4 at addr ffff8880276d7840 by task syz-executor126/18689<br /> <br /> CPU: 0 PID: 18689 Comm: syz-executor126 Not tainted 6.1.0-syzkaller #0<br /> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 10/26/2022<br /> Call Trace:<br /> <br /> ...<br /> atomic_fetch_sub_release include/linux/atomic/atomic-instrumented.h:176 [inline]<br /> __refcount_sub_and_test include/linux/refcount.h:272 [inline]<br /> __refcount_dec_and_test include/linux/refcount.h:315 [inline]<br /> refcount_dec_and_test include/linux/refcount.h:333 [inline]<br /> put_dev drivers/usb/gadget/legacy/inode.c:159 [inline]<br /> gadgetfs_kill_sb+0x33/0x100 drivers/usb/gadget/legacy/inode.c:2086<br /> deactivate_locked_super+0xa7/0xf0 fs/super.c:332<br /> vfs_get_super fs/super.c:1190 [inline]<br /> get_tree_single+0xd0/0x160 fs/super.c:1207<br /> vfs_get_tree+0x88/0x270 fs/super.c:1531<br /> vfs_fsconfig_locked fs/fsopen.c:232 [inline]<br /> <br /> The simplest solution is to ensure that gadgetfs_fill_super() and<br /> gadgetfs_kill_sb() are serialized by making them both acquire a new<br /> mutex.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> tty: fix possible null-ptr-defer in spk_ttyio_release<br /> <br /> Run the following tests on the qemu platform:<br /> <br /> syzkaller:~# modprobe speakup_audptr<br /> input: Speakup as /devices/virtual/input/input4<br /> initialized device: /dev/synth, node (MAJOR 10, MINOR 125)<br /> speakup 3.1.6: initialized<br /> synth name on entry is: (null)<br /> synth probe<br /> <br /> spk_ttyio_initialise_ldisc failed because tty_kopen_exclusive returned<br /> failed (errno -16), then remove the module, we will get a null-ptr-defer<br /> problem, as follow:<br /> <br /> syzkaller:~# modprobe -r speakup_audptr<br /> releasing synth audptr<br /> BUG: kernel NULL pointer dereference, address: 0000000000000080<br /> #PF: supervisor write access in kernel mode<br /> #PF: error_code(0x0002) - not-present page<br /> PGD 0 P4D 0<br /> Oops: 0002 [#1] PREEMPT SMP PTI<br /> CPU: 2 PID: 204 Comm: modprobe Not tainted 6.1.0-rc6-dirty #1<br /> RIP: 0010:mutex_lock+0x14/0x30<br /> Call Trace:<br /> <br /> spk_ttyio_release+0x19/0x70 [speakup]<br /> synth_release.part.6+0xac/0xc0 [speakup]<br /> synth_remove+0x56/0x60 [speakup]<br /> __x64_sys_delete_module+0x156/0x250<br /> ? fpregs_assert_state_consistent+0x1d/0x50<br /> do_syscall_64+0x37/0x90<br /> entry_SYSCALL_64_after_hwframe+0x63/0xcd<br /> <br /> Modules linked in: speakup_audptr(-) speakup<br /> Dumping ftrace buffer:<br /> <br /> in_synth-&gt;dev was not initialized during modprobe, so we add check<br /> for in_synth-&gt;dev to fix this bug.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> tty: serial: qcom-geni-serial: fix slab-out-of-bounds on RX FIFO buffer<br /> <br /> Driver&amp;#39;s probe allocates memory for RX FIFO (port-&gt;rx_fifo) based on<br /> default RX FIFO depth, e.g. 16. Later during serial startup the<br /> qcom_geni_serial_port_setup() updates the RX FIFO depth<br /> (port-&gt;rx_fifo_depth) to match real device capabilities, e.g. to 32.<br /> <br /> The RX UART handle code will read "port-&gt;rx_fifo_depth" number of words<br /> into "port-&gt;rx_fifo" buffer, thus exceeding the bounds. This can be<br /> observed in certain configurations with Qualcomm Bluetooth HCI UART<br /> device and KASAN:<br /> <br /> Bluetooth: hci0: QCA Product ID :0x00000010<br /> Bluetooth: hci0: QCA SOC Version :0x400a0200<br /> Bluetooth: hci0: QCA ROM Version :0x00000200<br /> Bluetooth: hci0: QCA Patch Version:0x00000d2b<br /> Bluetooth: hci0: QCA controller version 0x02000200<br /> Bluetooth: hci0: QCA Downloading qca/htbtfw20.tlv<br /> bluetooth hci0: Direct firmware load for qca/htbtfw20.tlv failed with error -2<br /> Bluetooth: hci0: QCA Failed to request file: qca/htbtfw20.tlv (-2)<br /> Bluetooth: hci0: QCA Failed to download patch (-2)<br /> ==================================================================<br /> BUG: KASAN: slab-out-of-bounds in handle_rx_uart+0xa8/0x18c<br /> Write of size 4 at addr ffff279347d578c0 by task swapper/0/0<br /> <br /> CPU: 0 PID: 0 Comm: swapper/0 Not tainted 6.1.0-rt5-00350-gb2450b7e00be-dirty #26<br /> Hardware name: Qualcomm Technologies, Inc. Robotics RB5 (DT)<br /> Call trace:<br /> dump_backtrace.part.0+0xe0/0xf0<br /> show_stack+0x18/0x40<br /> dump_stack_lvl+0x8c/0xb8<br /> print_report+0x188/0x488<br /> kasan_report+0xb4/0x100<br /> __asan_store4+0x80/0xa4<br /> handle_rx_uart+0xa8/0x18c<br /> qcom_geni_serial_handle_rx+0x84/0x9c<br /> qcom_geni_serial_isr+0x24c/0x760<br /> __handle_irq_event_percpu+0x108/0x500<br /> handle_irq_event+0x6c/0x110<br /> handle_fasteoi_irq+0x138/0x2cc<br /> generic_handle_domain_irq+0x48/0x64<br /> <br /> If the RX FIFO depth changes after probe, be sure to resize the buffer.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> misc: fastrpc: Fix use-after-free race condition for maps<br /> <br /> It is possible that in between calling fastrpc_map_get() until<br /> map-&gt;fl-&gt;lock is taken in fastrpc_free_map(), another thread can call<br /> fastrpc_map_lookup() and get a reference to a map that is about to be<br /> deleted.<br /> <br /> Rewrite fastrpc_map_get() to only increase the reference count of a map<br /> if it&amp;#39;s non-zero. Propagate this to callers so they can know if a map is<br /> about to be deleted.<br /> <br /> Fixes this warning:<br /> refcount_t: addition on 0; use-after-free.<br /> WARNING: CPU: 5 PID: 10100 at lib/refcount.c:25 refcount_warn_saturate<br /> ...<br /> Call trace:<br /> refcount_warn_saturate<br /> [fastrpc_map_get inlined]<br /> [fastrpc_map_lookup inlined]<br /> fastrpc_map_create<br /> fastrpc_internal_invoke<br /> fastrpc_device_ioctl<br /> __arm64_sys_ioctl<br /> invoke_syscall