Vulnerabilidades

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mm/damon/lru_sort: handle ctx allocation failure<br /> <br /> DAMON_LRU_SORT allocates the damon_ctx object for its kdamond in its init<br /> function. damon_lru_sort_enabled_store() wrongly assumes the allocation<br /> will always succeed once tried. If the damon_ctx allocation was failed,<br /> therefore, code execution reaches to damon_commit_ctx() while &amp;#39;ctx&amp;#39; is<br /> NULL. As a result, it dereferences the NULL &amp;#39;ctx&amp;#39; pointer. Avoid the<br /> NULL dereference by returning -ENOMEM if &amp;#39;ctx&amp;#39; is NULL.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> nvmem: layouts: onie-tlv: fix hang on unknown types<br /> <br /> The EEPROM on my board has a vendor specific entry of type 0x41. When<br /> stumbling upon that, this driver hangs in an endless loop.<br /> <br /> Fix it by keep incrementing the offset on unknown entries, so the loop<br /> will eventually stop.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: bonding: fix NULL pointer dereference in bond_do_ioctl()<br /> <br /> In bond_do_ioctl(), slave_dev is obtained via __dev_get_by_name() which<br /> can return NULL if the requested interface name does not exist. However,<br /> the subsequent slave_dbg() call is placed before the NULL check:<br /> <br /> slave_dev = __dev_get_by_name(net, ifr-&gt;ifr_slave);<br /> slave_dbg(bond_dev, slave_dev, "slave_dev=%p:\n", slave_dev); //here<br /> if (!slave_dev)<br /> return -ENODEV;<br /> <br /> The slave_dbg() macro expands to netdev_dbg(bond_dev, "(slave %s): " fmt,<br /> (slave_dev)-&gt;name, ...) which unconditionally dereferences slave_dev-&gt;name<br /> before the NULL check is performed. This results in a NULL pointer<br /> dereference kernel oops when a user calls bonding ioctl (e.g.<br /> SIOCBONDENSLAVE, SIOCBONDRELEASE, etc.) with a non-existent slave<br /> interface name.<br /> <br /> This is reachable from userspace via the bonding ioctl interface with<br /> CAP_NET_ADMIN capability, making it a potential local denial-of-service<br /> vector.<br /> <br /> Fix by moving the slave_dbg() call after the NULL check.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: airoha: Add NULL check for of_reserved_mem_lookup() in airoha_qdma_init_hfwd_queues()<br /> <br /> of_reserved_mem_lookup() may return NULL if the reserved memory region<br /> referenced by the "memory-region" phandle is not found in the reserved<br /> memory table (e.g. due to a misconfigured DTS or a removed<br /> memory-region node). The current code dereferences the returned<br /> pointer without checking for NULL, leading to a kernel NULL pointer<br /> dereference at the following lines:<br /> <br /> dma_addr = rmem-&gt;base; // line 1156<br /> num_desc = div_u64(rmem-&gt;size, buf_size); // line 1160<br /> <br /> Add a NULL check after of_reserved_mem_lookup() and return -ENODEV if<br /> the lookup fails, which is consistent with the existing error handling<br /> for of_parse_phandle() failure in the same code block.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> i2c: qcom-cci: Fix NULL pointer dereference in cci_remove()<br /> <br /> On all modern platforms Qualcomm CCI controller provides two I2C masters,<br /> and on particular boards only one I2C master may be initialized, and in<br /> such cases the device unbinding or driver removal causes a NULL pointer<br /> dereference, because cci_halt() is called for all two I2C masters, but<br /> a completion is initialized only for the single enabled master:<br /> <br /> % rmmod i2c-qcom-cci<br /> Unable to handle kernel NULL pointer dereference at virtual address 0000000000000000<br /> <br /> Call trace:<br /> __wait_for_common+0x194/0x1a8 (P)<br /> wait_for_completion_timeout+0x20/0x2c<br /> cci_remove+0xc4/0x138 [i2c_qcom_cci]<br /> platform_remove+0x20/0x30<br /> device_remove+0x4c/0x80<br /> device_release_driver_internal+0x1c8/0x224<br /> driver_detach+0x50/0x98<br /> bus_remove_driver+0x6c/0xbc<br /> driver_unregister+0x30/0x60<br /> platform_driver_unregister+0x14/0x20<br /> qcom_cci_driver_exit+0x18/0x1008 [i2c_qcom_cci]<br /> ....

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> slimbus: qcom-ngd-ctrl: Register callbacks after creating the ngd<br /> <br /> When the remoteproc starts in parallel with the NGD driver being probed,<br /> or the remoteproc is already up when the PDR lookup is being registered,<br /> or in the theoretical event that we get an interrupt from the hardware,<br /> these callbacks will operate on uninitialized data. This result in<br /> issues to boot the affected boards.<br /> <br /> One such example can be seen in the following fault, where<br /> qcom_slim_ngd_ssr_pdr_notify() schedules work on the NULL ngd_up_work.<br /> <br /> [ 21.858578] ------------[ cut here ]------------<br /> [ 21.858745] WARNING: kernel/workqueue.c:2338 at __queue_work+0x5e0/0x790, CPU#2: kworker/2:2/116<br /> ...<br /> [ 21.859251] Call trace:<br /> [ 21.859255] __queue_work+0x5e0/0x790 (P)<br /> [ 21.859265] queue_work_on+0x6c/0xf0<br /> [ 21.859273] qcom_slim_ngd_ssr_pdr_notify+0x110/0x150 [slim_qcom_ngd_ctrl]<br /> [ 21.859304] qcom_slim_ngd_ssr_notify+0x24/0x40 [slim_qcom_ngd_ctrl]<br /> [ 21.859318] notifier_call_chain+0xa4/0x230<br /> [ 21.859329] srcu_notifier_call_chain+0x64/0xb8<br /> [ 21.859338] ssr_notify_start+0x40/0x78 [qcom_common]<br /> [ 21.859355] rproc_start+0x130/0x230<br /> [ 21.859367] rproc_boot+0x3d4/0x518<br /> ...<br /> <br /> Move the enablement of interrupts, and the registration of SSR and PDR<br /> until after the NGD device has been registered.<br /> <br /> This could be further refined by moving initialization to the control<br /> driver probe and by removing the platform driver model from the picture.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> sched_ext: Don&amp;#39;t warn on NULL cgrp_moving_from in scx_cgroup_move_task()<br /> <br /> A WARN fires when systemd&amp;#39;s user manager writes "+cpu +memory +pids" to<br /> its own subtree_control while a sched_ext scheduler is loaded:<br /> <br /> WARNING: at kernel/sched/ext.c:3227 scx_cgroup_move_task+0xa8/0xb0<br /> scx_cgroup_move_task+0xa8/0xb0<br /> sched_move_task+0x134/0x290<br /> cpu_cgroup_attach+0x39/0x70<br /> cgroup_migrate_execute+0x37d/0x450<br /> cgroup_update_dfl_csses+0x1e3/0x270<br /> cgroup_subtree_control_write+0x3e7/0x440<br /> <br /> scx_cgroup_can_attach() arms cgrp_moving_from only when a task&amp;#39;s cpu<br /> cgroup changes. It can still be NULL when scx_cgroup_move_task() runs,<br /> through this sequence:<br /> <br /> Step Result<br /> --------------------------------- ----------------------------------<br /> 1. cpu enabled on cgroup G cpu css = A<br /> 2. cpu toggled off then on for G A killed, B created (same cgroup)<br /> 3. an exiting task keeps A alive migration skips it, A now stale<br /> 4. +memory migrates G stale A vs current B pulls cpu in<br /> 5. cpu attach runs for all tasks hits a live, cpu-unchanged task<br /> 6. scx_cgroup_move_task() on it cgrp_moving_from NULL -&gt; WARN<br /> <br /> The mismatch is that scx_cgroup_can_attach() keys on cgroup identity<br /> while migration drives the move on css identity, so a NULL cgrp_moving_from<br /> here is a legitimate css-only migration, not a missing prep.<br /> <br /> The call is already gated on cgrp_moving_from, so just drop the warning.<br /> ops.cgroup_prep_move() and ops.cgroup_move() stay paired.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> slimbus: qcom-ngd-ctrl: Avoid ABBA on tx_lock/ctrl-&gt;lock<br /> <br /> During the SSR/PDR down notification the tx_lock is taken with the<br /> intent to provide synchronization with active DMA transfers.<br /> <br /> But during this period qcom_slim_ngd_down() is invoked, which ends up in<br /> slim_report_absent(), which takes the slim_controller lock. In multiple<br /> other codepaths these two locks are taken in the opposite order (i.e.<br /> slim_controller then tx_lock).<br /> <br /> The result is a lockdep splat, and a possible deadlock:<br /> <br /> rprocctl/449 is trying to acquire lock:<br /> ffff00009793e620 (&amp;ctrl-&gt;lock){+.+.}-{4:4}, at: slim_report_absent (drivers/slimbus/core.c:322) slimbus<br /> <br /> but task is already holding lock:<br /> ffff00009793fb50 (&amp;ctrl-&gt;tx_lock){+.+.}-{4:4}, at: qcom_slim_ngd_ssr_pdr_notify (drivers/slimbus/qcom-ngd-ctrl.c:1475) slim_qcom_ngd_ctrl<br /> <br /> which lock already depends on the new lock.<br /> <br /> Possible unsafe locking scenario:<br /> <br /> CPU0 CPU1<br /> ---- ----<br /> lock(&amp;ctrl-&gt;tx_lock);<br /> lock(&amp;ctrl-&gt;lock);<br /> lock(&amp;ctrl-&gt;tx_lock);<br /> lock(&amp;ctrl-&gt;lock);<br /> <br /> The assumption is that the comment refers to the desire to not call<br /> qcom_slim_ngd_exit_dma() while we have an ongoing DMA TX transaction.<br /> But any such transaction is initiated and completed within a single<br /> qcom_slim_ngd_xfer_msg().<br /> <br /> Prior to calling qcom_slim_ngd_exit_dma() the slim_controller is torn<br /> down, all child devices are notified that the slimbus is gone and the<br /> child devices are removed.<br /> <br /> Stop taking the tx_lock in qcom_slim_ngd_ssr_pdr_notify() to avoid the<br /> deadlock.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> debugobjects: Don&amp;#39;t call fill_pool() in early boot hardirq context<br /> <br /> When booting a debug PREEMPT_RT kernel on an ARM64 system, a "inconsistent<br /> {HARDIRQ-ON-W} -&gt; {IN-HARDIRQ-W} usage" lockdep warning message was<br /> reported to the console.<br /> <br /> During early boot, interrupts are enabled before the scheduler is<br /> enabled. In this window (before SYSTEM_SCHEDULING is set) interrupts can<br /> fire and in the hard interrupt context handler attempt to fill the pool<br /> <br /> This can lead to a deadlock when the interrupt occurred when the interrupt<br /> hits a region which holds a lock that is required to be taken in the<br /> allocation path.<br /> <br /> Add a new can_fill_pool() helper and reorder the exception rule and forbid<br /> this scenario by excluding allocations from hard interrupt context.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> debugobjects: Do not fill_pool() if pi_blocked_on<br /> <br /> On RT enabled kernels, fill_pool() ends up calling rtlock_lock(), which<br /> asserts if current::pi_blocked_on is set, because a task can obviously only<br /> block on one lock as otherwise the priority inheritenace chain gets<br /> corrupted.<br /> <br /> Prevent this by expanding the conditional to take current::pi_blocked_on<br /> into account.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/amd/display: Use krealloc_array() in dal_vector_reserve()<br /> <br /> [Why &amp; How]<br /> dal_vector_reserve() computes the allocation size as<br /> "capacity * vector-&gt;struct_size" using uint32_t arithmetic, which can<br /> silently wrap to a small value on overflow. This would cause krealloc to<br /> return a smaller buffer than expected, leading to heap overflows on<br /> subsequent vector appends.<br /> <br /> Replace krealloc() with krealloc_array() which performs an internal<br /> overflow check and returns NULL on wrap, preventing the issue.<br /> <br /> (cherry picked from commit 37668568641ccc4cc1dbca4923d0a16609dd5707)

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/amd/display: Fix out-of-bounds read in dp_get_eq_aux_rd_interval()<br /> <br /> [Why &amp; How]<br /> The aux_rd_interval array in struct dc_lttpr_caps is declared with<br /> MAX_REPEATER_CNT - 1 (7) elements, indexed 0..6. However, the offset<br /> parameter passed to dp_get_eq_aux_rd_interval() can be as large as<br /> MAX_REPEATER_CNT (8) when a sink reports 8 LTTPR repeaters via DPCD.<br /> This leads to an out-of-bounds read of aux_rd_interval[7] when offset<br /> is 8.<br /> <br /> Fix this by growing aux_rd_interval to MAX_REPEATER_CNT elements to<br /> accommodate the full range of valid repeater counts defined by the DP<br /> spec.<br /> <br /> (cherry picked from commit a55a458a8df37a65ffda5cf721d554a8f74f6b04)