Vulnerabilidades

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> usb: typec: ps883x: Fix Oops at unbind<br /> <br /> When trying to unbind a device in order to bind to it vfio-platform as:<br /> <br /> echo bc0000.geniqup &gt; /sys/bus/platform/devices/bc0000.geniqup/driver/unbind<br /> <br /> I get the following Oops:<br /> <br /> [ 436.478639] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000020<br /> [ 436.487762] Mem abort info:<br /> [ 436.490716] ESR = 0x0000000096000004<br /> [ 436.494595] EC = 0x25: DABT (current EL), IL = 32 bits<br /> [ 436.500071] SET = 0, FnV = 0<br /> [ 436.503250] EA = 0, S1PTW = 0<br /> [ 436.506505] FSC = 0x04: level 0 translation fault<br /> [ 436.511533] Data abort info:<br /> [ 436.514558] ISV = 0, ISS = 0x00000004, ISS2 = 0x00000000<br /> [ 436.520215] CM = 0, WnR = 0, TnD = 0, TagAccess = 0<br /> [ 436.525436] GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0<br /> [ 436.530918] user pgtable: 4k pages, 48-bit VAs, pgdp=00000008861a9000<br /> [ 436.537554] [0000000000000020] pgd=0000000000000000, p4d=0000000000000000<br /> [ 436.544548] Internal error: Oops: 0000000096000004 [#1] SMP<br /> [ 436.550374] Modules linked in:<br /> [ 436.553542] CPU: 2 UID: 0 PID: 671 Comm: bash Tainted: G W 7.0.0-rc3-g56fcdd0911a5-dirty #2 PREEMPT<br /> [ 436.564440] Tainted: [W]=WARN<br /> [ 436.567515] Hardware name: LENOVO 91B6CTO1WW/3796, BIOS O6NKT3BA 05/02/2025<br /> [ 436.574675] pstate: 21400005 (nzCv daif +PAN -UAO -TCO +DIT -SSBS BTYPE=--)<br /> [ 436.581841] pc : ps883x_retimer_remove+0x14/0x94<br /> [ 436.586605] lr : i2c_device_remove+0x28/0x84<br /> [ 436.591017] sp : ffff8000847137c0<br /> <br /> That&amp;#39;s because the ps883x_retimer_remove() retrieves the driver data<br /> from i2c_get_clientdata() which was never set at probe. So, add<br /> i2c_set_clientdata() at the end of the probe.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> tty: hvc_iucv: fix off-by-one in number of supported devices<br /> <br /> MAX_HVC_IUCV_LINES == HVC_ALLOC_TTY_ADAPTERS == 8.<br /> This is the number of entries in:<br /> static struct hvc_iucv_private *hvc_iucv_table[MAX_HVC_IUCV_LINES];<br /> <br /> Sometimes hvc_iucv_table[] is limited by:<br /> (a) if (num &gt; hvc_iucv_devices) // for error detection<br /> or<br /> (b) for (i = 0; i MAX_HVC_IUCV_LINES)<br /> <br /> If hvc_iucv_devices == 8, (a) allows the code to access hvc_iucv_table[8].<br /> Oops.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: phonet: do not BUG_ON() in pn_socket_autobind() on failed bind<br /> <br /> syzbot reported a kernel BUG triggered from pn_socket_sendmsg() via<br /> pn_socket_autobind():<br /> <br /> kernel BUG at net/phonet/socket.c:213!<br /> RIP: 0010:pn_socket_autobind net/phonet/socket.c:213 [inline]<br /> RIP: 0010:pn_socket_sendmsg+0x240/0x250 net/phonet/socket.c:421<br /> Call Trace:<br /> sock_sendmsg_nosec+0x112/0x150 net/socket.c:797<br /> __sock_sendmsg net/socket.c:812 [inline]<br /> __sys_sendto+0x402/0x590 net/socket.c:2280<br /> ...<br /> <br /> pn_socket_autobind() calls pn_socket_bind() with port 0 and, on<br /> -EINVAL, assumes the socket was already bound and asserts that the<br /> port is non-zero:<br /> <br /> err = pn_socket_bind(sock, ..., sizeof(struct sockaddr_pn));<br /> if (err != -EINVAL)<br /> return err;<br /> BUG_ON(!pn_port(pn_sk(sock-&gt;sk)-&gt;sobject));<br /> return 0; /* socket was already bound */<br /> <br /> However pn_socket_bind() also returns -EINVAL when sk-&gt;sk_state is not<br /> TCP_CLOSE, even when the socket has never been bound and pn_port() is<br /> still 0. In that case the BUG_ON() fires and panics the kernel from a<br /> user-triggerable path.<br /> <br /> Treat the "bind returned -EINVAL but pn_port() is still 0" case as a<br /> regular error and propagate -EINVAL to the caller instead of crashing.<br /> Existing callers already translate a non-zero return from<br /> pn_socket_autobind() into -ENOBUFS/-EAGAIN, so returning -EINVAL here<br /> only changes behaviour from panic to a normal errno.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/amdgpu: fix AMDGPU_INFO_READ_MMR_REG<br /> <br /> There were multiple issues in that code.<br /> <br /> First of all the order between the reset semaphore and the mm_lock was<br /> wrong (e.g. copy_to_user) was called while holding the lock.<br /> <br /> Then we allocated memory while holding the reset semaphore which is also<br /> a pretty big bug and can deadlock.<br /> <br /> Then we used down_read_trylock() instead of waiting for the reset to<br /> finish.<br /> <br /> (cherry picked from commit 361b6e6b303d4b691f6c5974d3eaab67ca6dd90e)

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mailbox: mailbox-test: don&amp;#39;t free the reused channel<br /> <br /> The RX channel can be aliased to the TX channel if it has a different<br /> MMIO. This special case needs to be handled when freeing the channels<br /> otherwise a double-free occurs.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mailbox: add sanity check for channel array<br /> <br /> Fail gracefully if there is no channel array attached to the mailbox<br /> controller. Otherwise the later dereference will cause an OOPS which<br /> might not be seen because mailbox controllers might instantiate very<br /> early. Remove the comment explaining the obvious while here.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mailbox: mailbox-test: free channels on probe error<br /> <br /> On probe error, free the previously obtained channels. This not only<br /> prevents a leak, but also UAF scenarios because the client structure<br /> will be removed nonetheless because it was allocated with devm.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: mana: Guard mana_remove against double invocation<br /> <br /> If PM resume fails (e.g., mana_attach() returns an error), mana_probe()<br /> calls mana_remove(), which tears down the device and sets<br /> gd-&gt;gdma_context = NULL and gd-&gt;driver_data = NULL.<br /> <br /> However, a failed resume callback does not automatically unbind the<br /> driver. When the device is eventually unbound, mana_remove() is invoked<br /> a second time. Without a NULL check, it dereferences gc-&gt;dev with<br /> gc == NULL, causing a kernel panic.<br /> <br /> Add an early return if gdma_context or driver_data is NULL so the second<br /> invocation is harmless. Move the dev = gc-&gt;dev assignment after the<br /> guard so it cannot dereference NULL.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/amd/display: Wrap DCN32 phantom-plane allocation in DC_RUN_WITH_PREEMPTION_ENABLED<br /> <br /> [Why]<br /> dcn32_validate_bandwidth() wraps dcn32_internal_validate_bw() with<br /> DC_FP_START()/DC_FP_END(). In x86 non-RT, DC_FP_START takes fpregs_lock(),<br /> which disables local softirqs.<br /> <br /> The DML1 path through dcn32_enable_phantom_plane() calls kvzalloc() to<br /> allocate ~335 KiB for dc_plane_state. This triggers the vmalloc path,<br /> which calls BUG_ON(in_interrupt()) because it&amp;#39;s invoked within the<br /> FPU-enabled (softirq disabled) region, leading to a kernel crash.<br /> <br /> [How]<br /> Wrap the dc_state_create_phantom_plane() call with the<br /> DC_RUN_WITH_PREEMPTION_ENABLED() macro to allow preemption during<br /> this memory allocation.<br /> <br /> (cherry picked from commit 885ccbef7b94a8b38f69c4211c679021aa27ad11)

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> idpf: fix double free and use-after-free in aux device error paths<br /> <br /> When auxiliary_device_add() fails in idpf_plug_vport_aux_dev() or<br /> idpf_plug_core_aux_dev(), the err_aux_dev_add label calls<br /> auxiliary_device_uninit() and falls through to err_aux_dev_init. The<br /> uninit call will trigger put_device(), which invokes the release<br /> callback (idpf_vport_adev_release / idpf_core_adev_release) that frees<br /> iadev. The fall-through then reads adev-&gt;id from the freed iadev for<br /> ida_free() and double-frees iadev with kfree().<br /> <br /> Free the IDA slot and clear the back-pointer before uninit, while adev<br /> is still valid, then return immediately.<br /> <br /> Commit 65637c3a1811 ("idpf: fix UAF in RDMA core aux dev deinitialization")<br /> fixed the same use-after-free in the matching unplug path in this file but<br /> missed both probe error paths.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> audit: fix incorrect inheritable capability in CAPSET records<br /> <br /> __audit_log_capset() records the effective capability set into the<br /> inheritable field due to a copy-paste error. Every CAPSET audit<br /> record therefore reports cap_pi (process inheritable) with the value<br /> of cap_effective instead of cap_inheritable.<br /> <br /> This silently corrupts audit data used for compliance and forensic<br /> analysis: an attacker who modifies inheritable capabilities to<br /> prepare for a privilege-escalating exec would have the change masked<br /> in the audit trail.<br /> <br /> The bug has been present since the original introduction of CAPSET<br /> audit records in 2008.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> arm64: Reserve an extra page for early kernel mapping<br /> <br /> The final part of [data, end) segment may overflow into the next page of<br /> init_pg_end[1] which is the gap page before early_init_stack[2]:<br /> <br /> [1]<br /> crash_arm64_v9.0.1&gt; vtop ffffffed00601000<br /> VIRTUAL PHYSICAL<br /> ffffffed00601000 83401000<br /> <br /> PAGE DIRECTORY: ffffffecffd62000<br /> PGD: ffffffecffd62da0 =&gt; 10000000833fb003<br /> PMD: ffffff80033fb018 =&gt; 10000000833fe003<br /> PTE: ffffff80033fe008 =&gt; 68000083401f03<br /> PAGE: 83401000<br /> <br /> PTE PHYSICAL FLAGS<br /> 68000083401f03 83401000 (VALID|SHARED|AF|NG|PXN|UXN)<br /> <br /> PAGE PHYSICAL MAPPING INDEX CNT FLAGS<br /> fffffffec00d0040 83401000 0 0 1 4000 reserved<br /> <br /> [2]<br /> ffffffed002c8000 (r) __pi__data<br /> ffffffed0054e000 (d) __pi___bss_start<br /> ffffffed005f5000 (b) __pi_init_pg_dir<br /> ffffffed005fe000 (b) __pi_init_pg_end<br /> ffffffed005ff000 (B) early_init_stack<br /> ffffffed00608000 (b) __pi__end<br /> <br /> For 4K pages, the early kernel mapping may use 2MB block entries but the<br /> kernel segments are only 64KB aligned. Segment boundaries that fall<br /> within a 2MB block therefore require a PTE table so that different<br /> attributes can be applied on either side of the boundary.<br /> <br /> KERNEL_SEGMENT_COUNT still correctly counts the five permanent kernel<br /> VMAs registered by declare_kernel_vmas(). However, since commit<br /> 5973a62efa34 ("arm64: map [_text, _stext) virtual address range<br /> non-executable+read-only"), the early mapper also maps [_text, _stext)<br /> separately from [_stext, _etext). This adds one more early-only split<br /> and can require one more page-table page than the existing<br /> EARLY_SEGMENT_EXTRA_PAGES allowance reserves.<br /> <br /> Increase the 4K-page early mapping allowance by one page to cover that<br /> additional split.<br /> <br /> [catalin.marinas@arm.com: rewrote part of the commit log]<br /> [catalin.marinas@arm.com: expanded the code comment]