Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mm/damon/sysfs-schemes: delete tried region in regions_rmdirs()<br /> <br /> DAMON sysfs maintains the DAMOS tried region directory objects via a<br /> linked list. When the user requests refresh of the directories, DAMON<br /> sysfs removes all the region directories first, and then generate updated<br /> regions directory on the empty space. The removal function<br /> (damon_sysfs_scheme_regions_rm_dirs()) only puts the kobj objects. <br /> Deletion of the container region object from the linked list is done<br /> inside the kobj release callback function.<br /> <br /> If somehow the callback invocation is delayed, the list will contain<br /> regions list that gonna be freed. If the updated region directories<br /> creation is started in this situation, the list can be corrupted and<br /> use-after-free can happen.<br /> <br /> Because the kobj objects are managed by only DAMON sysfs, the issue cannot<br /> happen in normal situation. But, such delays can be made on kernels that<br /> built with CONFIG_DEBUG_KOBJECT_RELEASE. On the kernel, the issue can<br /> indeed be reproduced like below.<br /> <br /> # damo start --damos_action stat<br /> # cd /sys/kernel/mm/damon/admin/kdamonds/0/<br /> # for i in {1..10}; do echo update_schemes_tried_regions &gt; state; done<br /> # dmesg | grep underflow<br /> [ 89.296152] refcount_t: underflow; use-after-free.<br /> <br /> Fix the issue by removing the region object from the list when<br /> decrementing the reference count.<br /> <br /> Also update damos_sysfs_populate_region_dir() to add the region object to<br /> the list only after the kobject_init_and_add() is success, so that fail of<br /> kobject_init_and_add() is not leaving the deallocated object on the list.<br /> <br /> The issue was discovered [1] by Sashiko.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> media: rc: igorplugusb: fix control request setup packet<br /> <br /> Commit eac69475b01f ("media: rc: igorplugusb: heed coherency<br /> rules") changed the control request storage from an embedded struct to<br /> an allocated pointer so it can obey DMA coherency rules.<br /> <br /> However, the driver still passes &amp;ir-&gt;request to usb_fill_control_urb().<br /> That points the URB setup packet at the pointer field itself rather than<br /> at the allocated struct usb_ctrlrequest.<br /> <br /> USB core then interprets pointer bytes as the setup packet. This can<br /> produce an invalid bRequestType and trigger the control direction warning<br /> reported by syzbot:<br /> <br /> usb 2-1: BOGUS control dir, pipe 80003580 doesn&amp;#39;t match bRequestType 0<br /> <br /> Pass ir-&gt;request itself as the setup packet.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> gpio: rockchip: teardown bugs and resource leaks<br /> <br /> Address several teardown issues and resource leaks in the driver&amp;#39;s remove<br /> path and error handling:<br /> <br /> 1. Debounce clock reference leak: The debounce clock (bank-&gt;db_clk) is<br /> obtained using of_clk_get() which increments the clock&amp;#39;s reference<br /> count, but clk_put() is never called. Register a devm action to<br /> cleanly release it on unbind. Note that of_clk_get(..., 1) remains<br /> necessary over devm_clk_get() because the DT binding does not define<br /> clock-names, precluding name-based lookup.<br /> <br /> 2. Unregistered chained IRQ handler: The chained IRQ handler is not<br /> disconnected in remove(). If a stray interrupt fires after the driver<br /> is removed, the kernel attempts to execute a stale handler, leading<br /> to a panic. Fix this by clearing the handler in remove().<br /> <br /> 3. IRQ domain leak: The linear IRQ domain and its generic chips are<br /> allocated manually during probe but never removed. Remove the IRQ<br /> domain during driver teardown to free the associated generic chips<br /> and mappings.<br /> <br /> [Bartosz: don&amp;#39;t emit an error message on devres allocation failure]

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> usb: gadget: net2280: Fix double free in probe error path<br /> <br /> usb_initialize_gadget() installs gadget_release() as the release<br /> callback for the embedded gadget device. The struct net2280 instance is<br /> therefore released through gadget_release() when the gadget device&amp;#39;s last<br /> reference is dropped.<br /> <br /> The probe error path calls net2280_remove(), which tears down the<br /> partially initialized device and drops the gadget reference with<br /> usb_put_gadget(). Calling kfree(dev) afterwards can free the same object<br /> again.<br /> <br /> Drop the explicit kfree() and let the gadget device release callback<br /> handle the final free. This issue was found by a static analysis tool<br /> I am developing.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ASoC: codecs: simple-mux: Fix enum control bounds check<br /> <br /> simple_mux_control_put() rejects values greater than e-&gt;items, but<br /> enum control values are zero based. For the two-entry mux used by this<br /> driver, valid values are 0 and 1, so value 2 must be rejected as well.<br /> <br /> Accepting e-&gt;items can store an invalid mux state, pass it to the GPIO<br /> setter, and pass it on to the DAPM mux update path where it is used as<br /> an index into the enum text array.<br /> <br /> Use the same &gt;= e-&gt;items check used by the ASoC enum helpers.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drivers/base/memory: set mem-&gt;altmap after successful device registration<br /> <br /> If __add_memory_block() fails at xa_store() (under memory pressure for<br /> example), device_unregister() is called, which eventually triggers<br /> memory_block_release() with mem-&gt;altmap still set, causing a<br /> WARN_ON(mem-&gt;altmap). This was triggered by modifying virtio-mem driver.<br /> <br /> Fix this by delaying the assignment of mem-&gt;altmap until after<br /> __add_memory_block() has succeeded.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> fbdev: modedb: fix a possible UAF in fb_find_mode()<br /> <br /> If mode_option is NULL, it is assigned from mode_option_buf:<br /> <br /> if (!mode_option) {<br /> fb_get_options(NULL, &amp;mode_option_buf);<br /> mode_option = mode_option_buf;<br /> }<br /> <br /> Later, name is assigned from mode_option:<br /> <br /> const char *name = mode_option;<br /> <br /> However, mode_option_buf is freed before name is no longer used:<br /> <br /> kfree(mode_option_buf);<br /> <br /> while name is still accessed by:<br /> <br /> if ((name_matches(db[i], name, namelen) ||<br /> <br /> Since name aliases mode_option_buf, this may result in a<br /> use-after-free.<br /> <br /> Fix this by extending the lifetime of mode_option_buf until the end of the<br /> function by using scope-based resource management for cleanup.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> x86/mm: Disable broadcast TLB flush when PCID is disabled<br /> <br /> Booting with "nopcid" clears X86_FEATURE_PCID and keeps CR4.PCIDE from being<br /> set to one. On AMD CPUs that support INVLPGB, broadcast TLB flushing remains<br /> enabled.<br /> <br /> There are two checks that decide whether the global ASID code runs,<br /> mm_global_asid() and consider_global_asid(), that key off of the<br /> X86_FEATURE_INVLPGB feature. Once an mm becomes active on more than three<br /> CPUs, consider_global_asid() assigns it a global ASID, after which<br /> flush_tlb_mm_range() takes the broadcast_tlb_flush() path using a non-zero<br /> PCID. Issuing an INVLPGB with a non-zero PCID while CR4.PCIDE is not set<br /> results in a #GP:<br /> <br /> Oops: general protection fault, kernel NULL pointer dereference 0x1: 0000 [#1] SMP NOPTI<br /> CPU: 158 UID: 0 PID: 3119 Comm: snap Not tainted 7.1.0-rc3 #1 PREEMPT(full)<br /> Hardware name: ...<br /> RIP: 0010:broadcast_tlb_flush<br /> Code: ... 89 da 48 83 c8 07 01 fe eb 08 cc cc cc ...<br /> Call Trace:<br /> <br /> flush_tlb_mm_range<br /> ptep_clear_flush<br /> wp_page_copy<br /> ? _raw_spin_unlock<br /> __handle_mm_fault<br /> handle_mm_fault<br /> do_user_addr_fault<br /> exc_page_fault<br /> asm_exc_page_fault<br /> <br /> All processors that support broadcast TLB invalidation also have PCID support,<br /> so it is only the "nopcid" scenario that is of concern. In this situation just<br /> disable the broadcast TLB support using the CPUID dependency support by making<br /> X86_FEATURE_INVLPGB dependent on X86_FEATURE_PCID.<br /> <br /> [ bp: Massage commit message. ]

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> regulator: tps65219: fix irq_data.rdev not being assigned<br /> <br /> Commit 64a6b577490c ("regulator: tps65219: Remove debugging helper<br /> function") removed the tps65219_get_rdev_by_name() helper along with<br /> the irq_data.rdev assignment that depended on it. This left<br /> irq_data.rdev uninitialized for all IRQs, causing undefined behavior<br /> when regulator_notifier_call_chain() is called from the IRQ handler:<br /> <br /> Internal error: Oops: 0000000096000004<br /> pc : regulator_notifier_call_chain<br /> lr : tps65219_regulator_irq_handler<br /> Call trace:<br /> regulator_notifier_call_chain<br /> tps65219_regulator_irq_handler<br /> handle_nested_irq<br /> regmap_irq_thread<br /> irq_thread_fn<br /> irq_thread<br /> kthread<br /> ret_from_fork<br /> <br /> Instead of restoring a dedicated lookup array, restructure the probe<br /> function to combine regulator registration with IRQ registration in<br /> the same loop. This way the rdev returned by devm_regulator_register()<br /> is naturally available for assigning to irq_data.rdev without any<br /> auxiliary data structure.<br /> <br /> Non-regulator IRQs (SENSOR, TIMEOUT) that don&amp;#39;t correspond to any<br /> registered regulator are registered with rdev=NULL, and the IRQ handler<br /> is protected with a NULL check to avoid crashing.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/msm/dsi: don&amp;#39;t dump registers past the mapped region<br /> <br /> On DSI 6G platforms the IO address space is internally adjusted by<br /> io_offset. Later this adjusted address might be used for memory dumping.<br /> However the size that is used for memory dumping isn&amp;#39;t adjusted to<br /> account for the io_offset, leading to the potential access to the<br /> unmapped region. Lower ctrl_size by the io_offset value to prevent<br /> access past the mapped area.<br /> <br /> msm_disp_snapshot_add_block+0x1d4/0x3c8 [msm] (P)<br /> msm_dsi_host_snapshot+0x4c/0x78 [msm]<br /> msm_dsi_snapshot+0x28/0x50 [msm]<br /> msm_disp_snapshot_capture_state+0x74/0x140 [msm]<br /> msm_disp_snapshot_state_sync+0x60/0x90 [msm]<br /> _msm_disp_snapshot_work+0x30/0x90 [msm]<br /> kthread_worker_fn+0xdc/0x460<br /> kthread+0x120/0x140<br /> <br /> Patchwork: https://patchwork.freedesktop.org/patch/721747/

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> usb: gadget: uvc: hold opts-&gt;lock across XU walks in uvc_function_bind<br /> <br /> uvc_function_bind() walks &amp;opts-&gt;extension_units twice without holding<br /> opts-&gt;lock:<br /> <br /> - directly, for the iExtension string-descriptor fixup loop;<br /> - indirectly, four times via uvc_copy_descriptors() (once per speed),<br /> where the helper iterates uvc-&gt;desc.extension_units (which aliases<br /> &amp;opts-&gt;extension_units) to size and emit XU descriptors.<br /> <br /> The configfs side (uvcg_extension_make / uvcg_extension_drop, in<br /> drivers/usb/gadget/function/uvc_configfs.c) takes opts-&gt;lock around its<br /> list_add_tail / list_del operations. A privileged userspace process<br /> that holds the configfs subtree open and writes the gadget UDC name<br /> to bind the function while concurrently rmdir()&amp;#39;ing an extensions<br /> subdir can race uvcg_extension_drop() against the bind-time list walks<br /> and dereference a freed struct uvcg_extension.<br /> <br /> Hold opts-&gt;lock from the start of the XU string-descriptor fixup<br /> through the last uvc_copy_descriptors() call, releasing on the<br /> descriptor-error path via a new error_unlock label that drops the<br /> lock before falling through to the existing error label. This<br /> matches the locking discipline of the configfs callbacks and removes<br /> the only remaining unsynchronised reader of the XU list during bind.<br /> <br /> Reachability: only privileged processes that can mount configfs and<br /> write to gadget UDC files can trigger the race, so this is a<br /> correctness fix rather than a security boundary.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> tty: serial: pch_uart: add check for dma_alloc_coherent()<br /> <br /> Add a check for dma_alloc_coherent() failure to prevent a potential<br /> NULL pointer dereference in dma_handle_rx(). Properly release DMA<br /> channels and the PCI device reference using a goto ladder if the<br /> allocation fails.