Vulnerabilidades

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> sched_ext: Fix is_bpf_migration_disabled() false negative on non-PREEMPT_RCU<br /> <br /> Since commit 8e4f0b1ebcf2 ("bpf: use rcu_read_lock_dont_migrate() for<br /> trampoline.c"), the BPF prolog (__bpf_prog_enter) calls migrate_disable()<br /> only when CONFIG_PREEMPT_RCU is enabled, via rcu_read_lock_dont_migrate().<br /> Without CONFIG_PREEMPT_RCU, the prolog never touches migration_disabled,<br /> so migration_disabled == 1 always means the task is truly<br /> migration-disabled regardless of whether it is the current task.<br /> <br /> The old unconditional p == current check was a false negative in this<br /> case, potentially allowing a migration-disabled task to be dispatched to<br /> a remote CPU and triggering scx_error in task_can_run_on_remote_rq().<br /> <br /> Only apply the p == current disambiguation when CONFIG_PREEMPT_RCU is<br /> enabled, where the ambiguity with the BPF prolog still exists.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> iommupt: Fix short gather if the unmap goes into a large mapping<br /> <br /> unmap has the odd behavior that it can unmap more than requested if the<br /> ending point lands within the middle of a large or contiguous IOPTE.<br /> <br /> In this case the gather should flush everything unmapped which can be<br /> larger than what was requested to be unmapped. The gather was only<br /> flushing the range requested to be unmapped, not extending to the extra<br /> range, resulting in a short invalidation if the caller hits this special<br /> condition.<br /> <br /> This was found by the new invalidation/gather test I am adding in<br /> preparation for ARMv8. Claude deduced the root cause.<br /> <br /> As far as I remember nothing relies on unmapping a large entry, so this is<br /> likely not a triggerable bug.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: ethernet: mtk_ppe: avoid NULL deref when gmac0 is disabled<br /> <br /> If the gmac0 is disabled, the precheck for a valid ingress device will<br /> cause a NULL pointer deref and crash the system. This happens because<br /> eth-&gt;netdev[0] will be NULL but the code will directly try to access<br /> netdev_ops.<br /> <br /> Instead of just checking for the first net_device, it must be checked if<br /> any of the mtk_eth net_devices is matching the netdev_ops of the ingress<br /> device.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> vt: discard stale unicode buffer on alt screen exit after resize<br /> <br /> When enter_alt_screen() saves vc_uni_lines into vc_saved_uni_lines and<br /> sets vc_uni_lines to NULL, a subsequent console resize via vc_do_resize()<br /> skips reallocating the unicode buffer because vc_uni_lines is NULL.<br /> However, vc_saved_uni_lines still points to the old buffer allocated for<br /> the original dimensions.<br /> <br /> When leave_alt_screen() later restores vc_saved_uni_lines, the buffer<br /> dimensions no longer match vc_rows/vc_cols. Any operation that iterates<br /> over the unicode buffer using the current dimensions (e.g. csi_J clearing<br /> the screen) will access memory out of bounds, causing a kernel oops:<br /> <br /> BUG: unable to handle page fault for address: 0x0000002000000020<br /> RIP: 0010:csi_J+0x133/0x2d0<br /> <br /> The faulting address 0x0000002000000020 is two adjacent u32 space<br /> characters (0x20) interpreted as a pointer, read from the row data area<br /> past the end of the 25-entry pointer array in a buffer allocated for<br /> 80x25 but accessed with 240x67 dimensions.<br /> <br /> Fix this by checking whether the console dimensions changed while in the<br /> alternate screen. If they did, free the stale saved buffer instead of<br /> restoring it. The unicode screen will be lazily rebuilt via<br /> vc_uniscr_check() when next needed.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: ftgmac100: fix ring allocation unwind on open failure<br /> <br /> ftgmac100_alloc_rings() allocates rx_skbs, tx_skbs, rxdes, txdes, and<br /> rx_scratch in stages. On intermediate failures it returned -ENOMEM<br /> directly, leaking resources allocated earlier in the function.<br /> <br /> Rework the failure path to use staged local unwind labels and free<br /> allocated resources in reverse order before returning -ENOMEM. This<br /> matches common netdev allocation cleanup style.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> vxlan: validate ND option lengths in vxlan_na_create<br /> <br /> vxlan_na_create() walks ND options according to option-provided<br /> lengths. A malformed option can make the parser advance beyond the<br /> computed option span or use a too-short source LLADDR option payload.<br /> <br /> Validate option lengths against the remaining NS option area before<br /> advancing, and only read source LLADDR when the option is large enough<br /> for an Ethernet address.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> crypto: tegra - Add missing CRYPTO_ALG_ASYNC<br /> <br /> The tegra crypto driver failed to set the CRYPTO_ALG_ASYNC on its<br /> asynchronous algorithms, causing the crypto API to select them for users<br /> that request only synchronous algorithms. This causes crashes (at<br /> least). Fix this by adding the flag like what the other drivers do.<br /> Also remove the unnecessary CRYPTO_ALG_TYPE_* flags, since those just<br /> get ignored and overridden by the registration function anyway.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> counter: rz-mtu3-cnt: prevent counter from being toggled multiple times<br /> <br /> Runtime PM counter is incremented / decremented each time the sysfs<br /> enable file is written to.<br /> <br /> If user writes 0 to the sysfs enable file multiple times, runtime PM<br /> usage count underflows, generating the following message.<br /> <br /> rz-mtu3-counter rz-mtu3-counter.0: Runtime PM usage count underflow!<br /> <br /> At the same time, hardware registers end up being accessed with clocks<br /> off in rz_mtu3_terminate_counter() to disable an already disabled<br /> channel.<br /> <br /> If user writes 1 to the sysfs enable file multiple times, runtime PM<br /> usage count will be incremented each time, requiring the same number of<br /> 0 writes to get it back to 0.<br /> <br /> If user writes 0 to the sysfs enable file while PWM is in progress, PWM<br /> is stopped without counter being the owner of the underlying MTU3<br /> channel.<br /> <br /> Check against the cached count_is_enabled value and exit if the user<br /> is trying to set the same enable value.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> counter: rz-mtu3-cnt: do not use struct rz_mtu3_channel&amp;#39;s dev member<br /> <br /> The counter driver can use HW channels 1 and 2, while the PWM driver can<br /> use HW channels 0, 1, 2, 3, 4, 6, 7.<br /> <br /> The dev member is assigned both by the counter driver and the PWM driver<br /> for channels 1 and 2, to their own struct device instance, overwriting<br /> the previous value.<br /> <br /> The sub-drivers race to assign their own struct device pointer to the<br /> same struct rz_mtu3_channel&amp;#39;s dev member.<br /> <br /> The dev member of struct rz_mtu3_channel is used by the counter<br /> sub-driver for runtime PM.<br /> <br /> Depending on the probe order of the counter and PWM sub-drivers, the<br /> dev member may point to the wrong struct device instance, causing the<br /> counter sub-driver to do runtime PM actions on the wrong device.<br /> <br /> To fix this, use the parent pointer of the counter, which is assigned<br /> during probe to the correct struct device, not the struct device pointer<br /> inside the shared struct rz_mtu3_channel.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> gpio: Fix resource leaks on errors in gpiochip_add_data_with_key()<br /> <br /> Since commit aab5c6f20023 ("gpio: set device type for GPIO chips"),<br /> `gdev-&gt;dev.release` is unset. As a result, the reference count to<br /> `gdev-&gt;dev` isn&amp;#39;t dropped on the error handling paths.<br /> <br /> Drop the reference on errors.<br /> <br /> Also reorder the instructions to make the error handling simpler.<br /> Now gpiochip_add_data_with_key() roughly looks like:<br /> <br /> &gt;&gt;&gt; Some memory allocation. Go to ERR ZONE 1 on errors.<br /> &gt;&gt;&gt; device_initialize().<br /> <br /> gpiodev_release() takes over the responsibility for freeing the<br /> resources of `gdev-&gt;dev`. The subsequent error handling paths<br /> shouldn&amp;#39;t go through ERR ZONE 1 again which leads to double free.<br /> <br /> &gt;&gt;&gt; Some initialization mainly on `gdev`.<br /> &gt;&gt;&gt; The rest of initialization. Go to ERR ZONE 2 on errors.<br /> &gt;&gt;&gt; Chip registration success and exit.<br /> <br /> &gt;&gt;&gt; ERR ZONE 2. gpio_device_put() and exit.<br /> &gt;&gt;&gt; ERR ZONE 1.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> usb: typec: ucsi: validate connector number in ucsi_notify_common()<br /> <br /> The connector number extracted from CCI via UCSI_CCI_CONNECTOR() is a<br /> 7-bit field (0-127) that is used to index into the connector array in<br /> ucsi_connector_change(). However, the array is only allocated for the<br /> number of connectors reported by the device (typically 2-4 entries).<br /> <br /> A malicious or malfunctioning device could report an out-of-range<br /> connector number in the CCI, causing an out-of-bounds array access in<br /> ucsi_connector_change().<br /> <br /> Add a bounds check in ucsi_notify_common(), the central point where CCI<br /> is parsed after arriving from hardware, so that bogus connector numbers<br /> are rejected before they propagate further.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> usb: gadget: u_ether: Fix race between gether_disconnect and eth_stop<br /> <br /> A race condition between gether_disconnect() and eth_stop() leads to a<br /> NULL pointer dereference. Specifically, if eth_stop() is triggered<br /> concurrently while gether_disconnect() is tearing down the endpoints,<br /> eth_stop() attempts to access the cleared endpoint descriptor, causing<br /> the following NPE:<br /> <br /> Unable to handle kernel NULL pointer dereference<br /> Call trace:<br /> __dwc3_gadget_ep_enable+0x60/0x788<br /> dwc3_gadget_ep_enable+0x70/0xe4<br /> usb_ep_enable+0x60/0x15c<br /> eth_stop+0xb8/0x108<br /> <br /> Because eth_stop() crashes while holding the dev-&gt;lock, the thread<br /> running gether_disconnect() fails to acquire the same lock and spins<br /> forever, resulting in a hardlockup:<br /> <br /> Core - Debugging Information for Hardlockup core(7)<br /> Call trace:<br /> queued_spin_lock_slowpath+0x94/0x488<br /> _raw_spin_lock+0x64/0x6c<br /> gether_disconnect+0x19c/0x1e8<br /> ncm_set_alt+0x68/0x1a0<br /> composite_setup+0x6a0/0xc50<br /> <br /> The root cause is that the clearing of dev-&gt;port_usb in<br /> gether_disconnect() is delayed until the end of the function.<br /> <br /> Move the clearing of dev-&gt;port_usb to the very beginning of<br /> gether_disconnect() while holding dev-&gt;lock. This cuts off the link<br /> immediately, ensuring eth_stop() will see dev-&gt;port_usb as NULL and<br /> safely bail out.