Vulnerabilidades

*** 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 /> 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 /> mm/damon/reclaim: handle ctx allocation failure<br /> <br /> Patch series "mm/damon/{reclaim,lru_sort}: handle ctx allocation failures".<br /> <br /> DAMON_RECLAIM and DAMON_LRU_SORT could dereference NULL pointers if their<br /> damon_ctx object allocations fail. The bugs are expected to happen<br /> infrequently because the allocations are arguably too small to fail on<br /> common setups. But theoretically they are possible and the consequences<br /> are bad. Fix those.<br /> <br /> The issues were discovered [1] by Sashiko.<br /> <br /> <br /> This patch (of 2):<br /> <br /> DAMON_RECLAIM allocates the damon_ctx object for its kdamond in its init<br /> function. damon_reclaim_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 /> mm/mincore: handle non-swap entries before !CONFIG_SWAP guard<br /> <br /> mincore_swap() also fields migration/hwpoison entries (and shmem<br /> swapin-error entries), which can exist on !CONFIG_SWAP builds when<br /> CONFIG_MIGRATION or CONFIG_MEMORY_FAILURE is enabled. The<br /> !IS_ENABLED(CONFIG_SWAP) guard ran before the non-swap-entry early return,<br /> so mincore_pte_range() can spuriously WARN and report these pages<br /> nonresident on !CONFIG_SWAP kernels.<br /> <br /> Move the guard below the non-swap-entry check so only true swap entries<br /> trip the WARN, and migration/hwpoison entries take the existing "uptodate<br /> / non-shmem" path.

*** 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 /> 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 /> 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 /> 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 /> 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)

*** 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 *** The payment integration pretix-oppwa provides support <br /> for the payment providers VR Payment, Hobex, and potentially others <br /> based on Oppwa&amp;#39;s technology. The integration of Oppwa, following their <br /> official documentation, includes a step where the user is redirected <br /> from the payment provider back to our system with a query parameter like<br /> ?resourcePath=/v1/checkouts/{checkoutId}/payment in the URL. Our system is then supposed to fetch the status of the transaction from the URL given by baseUrl + resourcePath.<br /> <br /> <br /> <br /> Our plugin pretix-oppwa did so insecurely by <br /> concatenating the parameter form the URL to the base domain of the API <br /> without further validation and, critically, without a / at the end of the baseUrl. Therefore, an attacker could inject a resourcePath argument in a way that causes pretix to call a different<br /> server instead. Since the request includes the access token (API key) <br /> of the Oppwa account, this would leak the access token, giving access to<br /> data contained in the payment provider&amp;#39;s system. This is fixed with the<br /> release today by strictly validating the given API URL.<br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> After installing the update, we recommend asking your payment provider for a new access token and updating it in pretix.