Vulnerabilidades

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> perf/x86/intel/uncore: Fix die ID init and look up bugs<br /> <br /> In snbep_pci2phy_map_init(), in the nr_node_ids &gt; 8 path,<br /> uncore_device_to_die() may return -1 when all CPUs associated<br /> with the UBOX device are offline.<br /> <br /> Remove the WARN_ON_ONCE(die_id == -1) check for two reasons:<br /> <br /> - The current code breaks out of the loop. This is incorrect because<br /> pci_get_device() does not guarantee iteration in domain or bus order,<br /> so additional UBOX devices may be skipped during the scan.<br /> <br /> - Returning -EINVAL is incorrect, since marking offline buses with<br /> die_id == -1 is expected and should not be treated as an error.<br /> <br /> Separately, when NUMA is disabled on a NUMA-capable platform,<br /> pcibus_to_node() returns NUMA_NO_NODE, causing uncore_device_to_die()<br /> to return -1 for all PCI devices. As a result,<br /> spr_update_device_location(), used on Intel SPR and EMR, ignores the<br /> corresponding PMON units and does not add them to the RB tree.<br /> <br /> Fix this by using uncore_pcibus_to_dieid(), which retrieves topology<br /> from the UBOX GIDNIDMAP register and works regardless of whether NUMA<br /> is enabled in Linux. This requires snbep_pci2phy_map_init() to be<br /> added in spr_uncore_pci_init().<br /> <br /> Keep uncore_device_to_die() only for the nr_node_ids &gt; 8 case, where<br /> NUMA is expected to be enabled.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> usb: gadget: f_subset: Fix unbalanced refcnt in geth_free<br /> <br /> geth_alloc() increments the reference count, but geth_free() fails to<br /> decrement it. This prevents the configuration of attributes via configfs<br /> after unlinking the function.<br /> <br /> Decrement the reference count in geth_free() to ensure proper cleanup.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> usb: gadget: f_rndis: Protect RNDIS options with mutex<br /> <br /> The class/subclass/protocol options are suspectible to race conditions<br /> as they can be accessed concurrently through configfs.<br /> <br /> Use existing mutex to protect these options. This issue was identified<br /> during code inspection.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> comedi: Reinit dev-&gt;spinlock between attachments to low-level drivers<br /> <br /> `struct comedi_device` is the main controlling structure for a COMEDI<br /> device created by the COMEDI subsystem. It contains a member `spinlock`<br /> containing a spin-lock that is initialized by the COMEDI subsystem, but<br /> is reserved for use by a low-level driver attached to the COMEDI device<br /> (at least since commit 25436dc9d84f ("Staging: comedi: remove RT<br /> code")).<br /> <br /> Some COMEDI devices (those created on initialization of the COMEDI<br /> subsystem when the "comedi.comedi_num_legacy_minors" parameter is<br /> non-zero) can be attached to different low-level drivers over their<br /> lifetime using the `COMEDI_DEVCONFIG` ioctl command. This can result in<br /> inconsistent lock states being reported when there is a mismatch in the<br /> spin-lock locking levels used by each low-level driver to which the<br /> COMEDI device has been attached. Fix it by reinitializing<br /> `dev-&gt;spinlock` before calling the low-level driver&amp;#39;s `attach` function<br /> pointer if `CONFIG_LOCKDEP` is enabled.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ipv6: prevent possible UaF in addrconf_permanent_addr()<br /> <br /> The mentioned helper try to warn the user about an exceptional<br /> condition, but the message is delivered too late, accessing the ipv6<br /> after its possible deletion.<br /> <br /> Reorder the statement to avoid the possible UaF; while at it, place the<br /> warning outside the idev-&gt;lock as it needs no protection.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> btrfs: reserve enough transaction items for qgroup ioctls<br /> <br /> Currently our qgroup ioctls don&amp;#39;t reserve any space, they just do a<br /> transaction join, which does not reserve any space, neither for the quota<br /> tree updates nor for the delayed refs generated when updating the quota<br /> tree. The quota root uses the global block reserve, which is fine most of<br /> the time since we don&amp;#39;t expect a lot of updates to the quota root, or to<br /> be too close to -ENOSPC such that other critical metadata updates need to<br /> resort to the global reserve.<br /> <br /> However this is not optimal, as not reserving proper space may result in a<br /> transaction abort due to not reserving space for delayed refs and then<br /> abusing the use of the global block reserve.<br /> <br /> For example, the following reproducer (which is unlikely to model any<br /> real world use case, but just to illustrate the problem), triggers such a<br /> transaction abort due to -ENOSPC when running delayed refs:<br /> <br /> $ cat test.sh<br /> #!/bin/bash<br /> <br /> DEV=/dev/nullb0<br /> MNT=/mnt/nullb0<br /> <br /> umount $DEV &amp;&gt; /dev/null<br /> # Limit device to 1G so that it&amp;#39;s much faster to reproduce the issue.<br /> mkfs.btrfs -f -b 1G $DEV<br /> mount -o commit=600 $DEV $MNT<br /> <br /> fallocate -l 800M $MNT/filler<br /> btrfs quota enable $MNT<br /> <br /> for ((i = 1; i

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/amd/display: Fix NULL pointer dereference in dcn401_init_hw()<br /> <br /> dcn401_init_hw() assumes that update_bw_bounding_box() is valid when<br /> entering the update path. However, the existing condition:<br /> <br /> ((!fams2_enable &amp;&amp; update_bw_bounding_box) || freq_changed)<br /> <br /> does not guarantee this, as the freq_changed branch can evaluate to true<br /> independently of the callback pointer.<br /> <br /> This can result in calling update_bw_bounding_box() when it is NULL.<br /> <br /> Fix this by separating the update condition from the pointer checks and<br /> ensuring the callback, dc-&gt;clk_mgr, and bw_params are validated before<br /> use.<br /> <br /> Fixes the below:<br /> ../dc/hwss/dcn401/dcn401_hwseq.c:367 dcn401_init_hw() error: we previously assumed &amp;#39;dc-&gt;res_pool-&gt;funcs-&gt;update_bw_bounding_box&amp;#39; could be null (see line 362)<br /> <br /> (cherry picked from commit 86117c5ab42f21562fedb0a64bffea3ee5fcd477)

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> lib/crypto: chacha: Zeroize permuted_state before it leaves scope<br /> <br /> Since the ChaCha permutation is invertible, the local variable<br /> &amp;#39;permuted_state&amp;#39; is sufficient to compute the original &amp;#39;state&amp;#39;, and thus<br /> the key, even after the permutation has been done.<br /> <br /> While the kernel is quite inconsistent about zeroizing secrets on the<br /> stack (and some prominent userspace crypto libraries don&amp;#39;t bother at all<br /> since it&amp;#39;s not guaranteed to work anyway), the kernel does try to do it<br /> as a best practice, especially in cases involving the RNG.<br /> <br /> Thus, explicitly zeroize &amp;#39;permuted_state&amp;#39; before it goes out of scope.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> interconnect: qcom: sm8450: Fix NULL pointer dereference in icc_link_nodes()<br /> <br /> The change to dynamic IDs for SM8450 platform interconnects left two links<br /> unconverted, fix it to avoid the NULL pointer dereference in runtime,<br /> when a pointer to a destination interconnect is not valid:<br /> <br /> Unable to handle kernel NULL pointer dereference at virtual address 0000000000000008<br /> <br /> Call trace:<br /> icc_link_nodes+0x3c/0x100 (P)<br /> qcom_icc_rpmh_probe+0x1b4/0x528<br /> platform_probe+0x64/0xc0<br /> really_probe+0xc4/0x2a8<br /> __driver_probe_device+0x80/0x140<br /> driver_probe_device+0x48/0x170<br /> __device_attach_driver+0xc0/0x148<br /> bus_for_each_drv+0x88/0xf0<br /> __device_attach+0xb0/0x1c0<br /> device_initial_probe+0x58/0x68<br /> bus_probe_device+0x40/0xb8<br /> deferred_probe_work_func+0x90/0xd0<br /> process_one_work+0x15c/0x3c0<br /> worker_thread+0x2e8/0x400<br /> kthread+0x150/0x208<br /> ret_from_fork+0x10/0x20<br /> Code: 900310f4 911d6294 91008280 94176078 (f94002a0)<br /> ---[ end trace 0000000000000000 ]---<br /> Kernel panic - not syncing: Oops: Fatal exception

*** 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.