Vulnerabilidades

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> MIPS: DEC: Prevent initial console buffer from landing in XKPHYS<br /> <br /> In 64-bit configurations calling the initial console output handler from<br /> a kernel thread other than the initial one will result in a situation<br /> where the stack has been placed in the XKPHYS 64-bit memory segment and<br /> consequently so has been the buffer allocated there that is used as the<br /> argument corresponding to the `%s&amp;#39; output conversion specifier for the<br /> firmware&amp;#39;s printf() entry point.<br /> <br /> This 64-bit address will then be truncated by 32-bit firmware, resulting<br /> in an attempt to access the wrong memory location, which in turn will<br /> cause all kinds of unpredictable behaviour, such as a kernel crash:<br /> <br /> Console: colour dummy device 160x64<br /> Calibrating delay loop... 49.36 BogoMIPS (lpj=192512)<br /> pid_max: default: 32768 minimum: 301<br /> CPU 0 Unable to handle kernel paging request at virtual address 000000000203bd00, epc == ffffffffbfc08364, ra == ffffffffbfc08800<br /> Oops[#1]:<br /> CPU: 0 PID: 0 Comm: swapper Not tainted 5.18.0-rc2-00254-gfb649bda6f56-dirty #121<br /> $ 0 : 0000000000000000 0000000000000001 0000000000000023 ffffffff80684ba0<br /> $ 4 : 000000000203bd00 ffffffffbfc0f3b4 ffffffffffffffff 0000000000000073<br /> $ 8 : 0a303d7469000000 0000000000000000 0000000000000073 ffffffffbfc0f473<br /> $12 : 0000000000000002 0000000000000000 ffffffff80684c1c 0000000000000000<br /> $16 : 0000000000000000 ffffffff80596dc9 0000000000000000 ffffffffbfc09240<br /> $20 : ffffffff80684c40 ffffffffbfc0f400 000000000000002d 000000000000002b<br /> $24 : ffffffffffffffbf 000000000203bd00<br /> $28 : ffffffff805f0000 ffffffff80684b58 0000000000000030 ffffffffbfc08800<br /> Hi : 0000000000000000<br /> Lo : 0000000000000aa8<br /> epc : ffffffffbfc08364 0xffffffffbfc08364<br /> ra : ffffffffbfc08800 0xffffffffbfc08800<br /> Status: 140120e2 KX SX UX KERNEL EXL<br /> Cause : 00000008 (ExcCode 02)<br /> BadVA : 000000000203bd00<br /> PrId : 00000430 (R4000SC)<br /> Modules linked in:<br /> Process swapper (pid: 0, threadinfo=(____ptrval____), task=(____ptrval____), tls=0000000000000000)<br /> Stack : 0000000000000000 0000000000000000 0000000000000000 0000004d0000004d<br /> 80684cc0806a2a40 80596dc80000004d 8061000000000000 bfc0850c80684c38<br /> 0000000000000000 000000000203bd00 0000000000000000 0000000000000000<br /> 0000000000000000 00000000bfc0f3b4 0000000000000000 0000000000000000<br /> 0000000000000000 0000000000000000 0000000000000000 0000000000000000<br /> 0000000000000000 0000000000000000 0000000000000000 0000000000000000<br /> 0000002500000000 0000000000000000 0000000000000000 802c1a7400000000<br /> 0203bd0080596dc8 0203bd4d69000000 6c61632000000018 5f746567646e6172<br /> 6c616320625f6d6f 5f736e5f6d6f7266 206361323778302b 303d74696e726320<br /> 806a0a38806b0000 806a0a38806b0000 00000000806b0000 80683c58806b0000<br /> ...<br /> Call Trace:<br /> <br /> Code: a082ffff 03e00008 00601021 00001821 10400005 24840001 80820000 24630001<br /> <br /> ---[ end trace 0000000000000000 ]---<br /> Kernel panic - not syncing: Fatal exception in interrupt<br /> <br /> KN04 V2.1k (PC: 0xa0026768, SP: 0x806848e8)<br /> &gt;&gt;<br /> <br /> In this case the pointer in $4 was truncated from 0x980000000203bd00 to<br /> 0x000000000203bd00.<br /> <br /> This may happen when no final console driver has been enabled in the<br /> configuration and consequently the initial console continues being used<br /> late into bootstrap or with an upcoming change that will switch the zs<br /> driver to use a platform device, which in turn will make the console<br /> handover happen only after other kernel threads have already been<br /> started.<br /> <br /> Fix the issue by making the buffer static and initdata, and therefore<br /> placed in the CKSEG0 32-bit compatibility segment, observing that the<br /> console output handler is called with the console lock held, implying<br /> no need for this code to be reentrant. Add an assertion to verify the<br /> buffer actually has been placed in a compatibility segment.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> gpio: shared: fix deadlock on shared proxy&amp;#39;s parent removal<br /> <br /> Commit 710abda58055 ("gpio: shared: call gpio_chip::of_xlate() if set")<br /> used the mutex embedded in struct gpio_shared_entry to protect the<br /> offset field which now can be modified after assignment. The critical<br /> section however is too wide and introduced a potential deadlock on the<br /> removal of the shared GPIO proxy&amp;#39;s parent.<br /> <br /> Make the critical section shorter - only protect the offset when it&amp;#39;s<br /> being read.<br /> <br /> While at it: mention the fact that the entry lock is now also used to<br /> protect against concurrent access to the offset field in the structure&amp;#39;s<br /> documentation.

*** Pendiente de traducción *** 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.

*** Pendiente de traducción *** 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.

*** Pendiente de traducción *** 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]

*** Pendiente de traducción *** 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.

*** Pendiente de traducción *** 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.

*** Pendiente de traducción *** 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.

*** Pendiente de traducción *** 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.

*** Pendiente de traducción *** 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. ]

*** Pendiente de traducción *** 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.

*** Pendiente de traducción *** 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/