Vulnerabilidades

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> Bluetooth: SMP: force responder MITM requirements before building the pairing response<br /> <br /> smp_cmd_pairing_req() currently builds the pairing response from the<br /> initiator auth_req before enforcing the local BT_SECURITY_HIGH<br /> requirement. If the initiator omits SMP_AUTH_MITM, the response can<br /> also omit it even though the local side still requires MITM.<br /> <br /> tk_request() then sees an auth value without SMP_AUTH_MITM and may<br /> select JUST_CFM, making method selection inconsistent with the pairing<br /> policy the responder already enforces.<br /> <br /> When the local side requires HIGH security, first verify that MITM can<br /> be achieved from the IO capabilities and then force SMP_AUTH_MITM in the<br /> response in both rsp.auth_req and auth. This keeps the responder auth bits<br /> and later method selection aligned.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> bpf: reject direct access to nullable PTR_TO_BUF pointers<br /> <br /> check_mem_access() matches PTR_TO_BUF via base_type() which strips<br /> PTR_MAYBE_NULL, allowing direct dereference without a null check.<br /> <br /> Map iterator ctx-&gt;key and ctx-&gt;value are PTR_TO_BUF | PTR_MAYBE_NULL.<br /> On stop callbacks these are NULL, causing a kernel NULL dereference.<br /> <br /> Add a type_may_be_null() guard to the PTR_TO_BUF branch, matching the<br /> existing PTR_TO_BTF_ID pattern.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> USB: dummy-hcd: Fix locking/synchronization error<br /> <br /> Syzbot testing was able to provoke an addressing exception and crash<br /> in the usb_gadget_udc_reset() routine in<br /> drivers/usb/gadgets/udc/core.c, resulting from the fact that the<br /> routine was called with a second ("driver") argument of NULL. The bad<br /> caller was set_link_state() in dummy_hcd.c, and the problem arose<br /> because of a race between a USB reset and driver unbind.<br /> <br /> These sorts of races were not supposed to be possible; commit<br /> 7dbd8f4cabd9 ("USB: dummy-hcd: Fix erroneous synchronization change"),<br /> along with a few followup commits, was written specifically to prevent<br /> them. As it turns out, there are (at least) two errors remaining in<br /> the code. Another patch will address the second error; this one is<br /> concerned with the first.<br /> <br /> The error responsible for the syzbot crash occurred because the<br /> stop_activity() routine will sometimes drop and then re-acquire the<br /> dum-&gt;lock spinlock. A call to stop_activity() occurs in<br /> set_link_state() when handling an emulated USB reset, after the test<br /> of dum-&gt;ints_enabled and before the increment of dum-&gt;callback_usage.<br /> This allowed another thread (doing a driver unbind) to sneak in and<br /> grab the spinlock, and then clear dum-&gt;ints_enabled and dum-&gt;driver.<br /> Normally this other thread would have to wait for dum-&gt;callback_usage<br /> to go down to 0 before it would clear dum-&gt;driver, but in this case it<br /> didn&amp;#39;t have to wait since dum-&gt;callback_usage had not yet been<br /> incremented.<br /> <br /> The fix is to increment dum-&gt;callback_usage _before_ calling<br /> stop_activity() instead of after. Then the thread doing the unbind<br /> will not clear dum-&gt;driver until after the call to<br /> usb_gadget_udc_reset() safely returns and dum-&gt;callback_usage has been<br /> decremented again.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> sched_ext: Fix SCX_KICK_WAIT deadlock by deferring wait to balance callback<br /> <br /> SCX_KICK_WAIT busy-waits in kick_cpus_irq_workfn() using<br /> smp_cond_load_acquire() until the target CPU&amp;#39;s kick_sync advances. Because<br /> the irq_work runs in hardirq context, the waiting CPU cannot reschedule and<br /> its own kick_sync never advances. If multiple CPUs form a wait cycle, all<br /> CPUs deadlock.<br /> <br /> Replace the busy-wait in kick_cpus_irq_workfn() with resched_curr() to<br /> force the CPU through do_pick_task_scx(), which queues a balance callback<br /> to perform the wait. The balance callback drops the rq lock and enables<br /> IRQs following the sched_core_balance() pattern, so the CPU can process<br /> IPIs while waiting. The local CPU&amp;#39;s kick_sync is advanced on entry to<br /> do_pick_task_scx() and continuously during the wait, ensuring any CPU that<br /> starts waiting for us sees the advancement and cannot form cyclic<br /> dependencies.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> thermal: core: Fix thermal zone device registration error path<br /> <br /> If thermal_zone_device_register_with_trips() fails after registering<br /> a thermal zone device, it needs to wait for the tz-&gt;removal completion<br /> like thermal_zone_device_unregister(), in case user space has managed<br /> to take a reference to the thermal zone device&amp;#39;s kobject, in which case<br /> thermal_release() may not be called by the error path itself and tz may<br /> be freed prematurely.<br /> <br /> Add the missing wait_for_completion() call to the thermal zone device<br /> registration error path.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> x86/kexec: Disable KCOV instrumentation after load_segments()<br /> <br /> The load_segments() function changes segment registers, invalidating GS base<br /> (which KCOV relies on for per-cpu data). When CONFIG_KCOV is enabled, any<br /> subsequent instrumented C code call (e.g. native_gdt_invalidate()) begins<br /> crashing the kernel in an endless loop.<br /> <br /> To reproduce the problem, it&amp;#39;s sufficient to do kexec on a KCOV-instrumented<br /> kernel:<br /> <br /> $ kexec -l /boot/otherKernel<br /> $ kexec -e<br /> <br /> The real-world context for this problem is enabling crash dump collection in<br /> syzkaller. For this, the tool loads a panic kernel before fuzzing and then<br /> calls makedumpfile after the panic. This workflow requires both CONFIG_KEXEC<br /> and CONFIG_KCOV to be enabled simultaneously.<br /> <br /> Adding safeguards directly to the KCOV fast-path (__sanitizer_cov_trace_pc())<br /> is also undesirable as it would introduce an extra performance overhead.<br /> <br /> Disabling instrumentation for the individual functions would be too fragile,<br /> so disable KCOV instrumentation for the entire machine_kexec_64.c and<br /> physaddr.c. If coverage-guided fuzzing ever needs these components in the<br /> future, other approaches should be considered.<br /> <br /> The problem is not relevant for 32 bit kernels as CONFIG_KCOV is not supported<br /> there.<br /> <br /> [ bp: Space out comment for better readability. ]

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> crypto: caam - fix overflow on long hmac keys<br /> <br /> When a key longer than block size is supplied, it is copied and then<br /> hashed into the real key. The memory allocated for the copy needs to<br /> be rounded to DMA cache alignment, as otherwise the hashed key may<br /> corrupt neighbouring memory.<br /> <br /> The copying is performed using kmemdup, however this leads to an overflow:<br /> reading more bytes (aligned_len - keylen) from the keylen source buffer.<br /> Fix this by replacing kmemdup with kmalloc, followed by memcpy.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> netfilter: flowtable: strictly check for maximum number of actions<br /> <br /> The maximum number of flowtable hardware offload actions in IPv6 is:<br /> <br /> * ethernet mangling (4 payload actions, 2 for each ethernet address)<br /> * SNAT (4 payload actions)<br /> * DNAT (4 payload actions)<br /> * Double VLAN (4 vlan actions, 2 for popping vlan, and 2 for pushing)<br /> for QinQ.<br /> * Redirect (1 action)<br /> <br /> Which makes 17, while the maximum is 16. But act_ct supports for tunnels<br /> actions too. Note that payload action operates at 32-bit word level, so<br /> mangling an IPv6 address takes 4 payload actions.<br /> <br /> Update flow_action_entry_next() calls to check for the maximum number of<br /> supported actions.<br /> <br /> While at it, rise the maximum number of actions per flow from 16 to 24<br /> so this works fine with IPv6 setups.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> cpufreq: governor: fix double free in cpufreq_dbs_governor_init() error path<br /> <br /> When kobject_init_and_add() fails, cpufreq_dbs_governor_init() calls<br /> kobject_put(&amp;dbs_data-&gt;attr_set.kobj).<br /> <br /> The kobject release callback cpufreq_dbs_data_release() calls<br /> gov-&gt;exit(dbs_data) and kfree(dbs_data), but the current error path<br /> then calls gov-&gt;exit(dbs_data) and kfree(dbs_data) again, causing a<br /> double free.<br /> <br /> Keep the direct kfree(dbs_data) for the gov-&gt;init() failure path, but<br /> after kobject_init_and_add() has been called, let kobject_put() handle<br /> the cleanup through cpufreq_dbs_data_release().

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> wifi: iwlwifi: mvm: don&amp;#39;t send a 6E related command when not supported<br /> <br /> MCC_ALLOWED_AP_TYPE_CMD is related to 6E support. Do not send it if the<br /> device doesn&amp;#39;t support 6E.<br /> Apparently, the firmware is mistakenly advertising support for this<br /> command even on AX201 which does not support 6E and then the firmware<br /> crashes.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> USB: dummy-hcd: Fix interrupt synchronization error<br /> <br /> This fixes an error in synchronization in the dummy-hcd driver. The<br /> error has a somewhat involved history. The synchronization mechanism<br /> was introduced by commit 7dbd8f4cabd9 ("USB: dummy-hcd: Fix erroneous<br /> synchronization change"), which added an emulated "interrupts enabled"<br /> flag together with code emulating synchronize_irq() (it waits until<br /> all current handler callbacks have returned).<br /> <br /> But the emulated interrupt-disable occurred too late, after the driver<br /> containing the handler callback routines had been told that it was<br /> unbound and no more callbacks would occur. Commit 4a5d797a9f9c ("usb:<br /> gadget: dummy_hcd: fix gpf in gadget_setup") tried to fix this by<br /> moving the synchronize_irq() emulation code from dummy_stop() to<br /> dummy_pullup(), which runs before the unbind callback.<br /> <br /> There still were races, though, because the emulated interrupt-disable<br /> still occurred too late. It couldn&amp;#39;t be moved to dummy_pullup(),<br /> because that routine can be called for reasons other than an impending<br /> unbind. Therefore commits 7dc0c55e9f30 ("USB: UDC core: Add<br /> udc_async_callbacks gadget op") and 04145a03db9d ("USB: UDC: Implement<br /> udc_async_callbacks in dummy-hcd") added an API allowing the UDC core<br /> to tell dummy-hcd exactly when emulated interrupts and their callbacks<br /> should be disabled.<br /> <br /> That brings us to the current state of things, which is still wrong<br /> because the emulated synchronize_irq() occurs before the emulated<br /> interrupt-disable! That&amp;#39;s no good, beause it means that more emulated<br /> interrupts can occur after the synchronize_irq() emulation has run,<br /> leading to the possibility that a callback handler may be running when<br /> the gadget driver is unbound.<br /> <br /> To fix this, we have to move the synchronize_irq() emulation code yet<br /> again, to the dummy_udc_async_callbacks() routine, which takes care of<br /> enabling and disabling emulated interrupt requests. The<br /> synchronization will now run immediately after emulated interrupts are<br /> disabled, which is where it belongs.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> sched/fair: Fix zero_vruntime tracking fix<br /> <br /> John reported that stress-ng-yield could make his machine unhappy and<br /> managed to bisect it to commit b3d99f43c72b ("sched/fair: Fix<br /> zero_vruntime tracking").<br /> <br /> The combination of yield and that commit was specific enough to<br /> hypothesize the following scenario:<br /> <br /> Suppose we have 2 runnable tasks, both doing yield. Then one will be<br /> eligible and one will not be, because the average position must be in<br /> between these two entities.<br /> <br /> Therefore, the runnable task will be eligible, and be promoted a full<br /> slice (all the tasks do is yield after all). This causes it to jump over<br /> the other task and now the other task is eligible and current is no<br /> longer. So we schedule.<br /> <br /> Since we are runnable, there is no {de,en}queue. All we have is the<br /> __{en,de}queue_entity() from {put_prev,set_next}_task(). But per the<br /> fingered commit, those two no longer move zero_vruntime.<br /> <br /> All that moves zero_vruntime are tick and full {de,en}queue.<br /> <br /> This means, that if the two tasks playing leapfrog can reach the<br /> critical speed to reach the overflow point inside one tick&amp;#39;s worth of<br /> time, we&amp;#39;re up a creek.<br /> <br /> Additionally, when multiple cgroups are involved, there is no guarantee<br /> the tick will in fact hit every cgroup in a timely manner. Statistically<br /> speaking it will, but that same statistics does not rule out the<br /> possibility of one cgroup not getting a tick for a significant amount of<br /> time -- however unlikely.<br /> <br /> Therefore, just like with the yield() case, force an update at the end<br /> of every slice. This ensures the update is never more than a single<br /> slice behind and the whole thing is within 2 lag bounds as per the<br /> comment on entity_key().