Vulnerabilidades

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> parisc: Avoid crash due to unaligned access in unwinder<br /> <br /> Guenter Roeck reported this kernel crash on his emulated B160L machine:<br /> <br /> Starting network: udhcpc: started, v1.36.1<br /> Backtrace:<br /> [] unwind_once+0x1c/0x5c<br /> [] walk_stackframe.isra.0+0x74/0xb8<br /> [] arch_stack_walk+0x28/0x38<br /> [] stack_trace_save+0x48/0x5c<br /> [] set_track_prepare+0x44/0x6c<br /> [] ___slab_alloc+0xfc4/0x1024<br /> [] __slab_alloc.isra.0+0x58/0x90<br /> [] kmem_cache_alloc_noprof+0x2ac/0x4a0<br /> [] __anon_vma_prepare+0x60/0x280<br /> [] __vmf_anon_prepare+0x68/0x94<br /> [] do_wp_page+0x8cc/0xf10<br /> [] handle_mm_fault+0x6c0/0xf08<br /> [] do_page_fault+0x110/0x440<br /> [] handle_interruption+0x184/0x748<br /> [] schedule+0x4c/0x190<br /> BUG: spinlock recursion on CPU#0, ifconfig/2420<br /> lock: terminate_lock.2+0x0/0x1c, .magic: dead4ead, .owner: ifconfig/2420, .owner_cpu: 0<br /> <br /> While creating the stack trace, the unwinder uses the stack pointer to guess<br /> the previous frame to read the previous stack pointer from memory. The crash<br /> happens, because the unwinder tries to read from unaligned memory and as such<br /> triggers the unalignment trap handler which then leads to the spinlock<br /> recursion and finally to a deadlock.<br /> <br /> Fix it by checking the alignment before accessing the memory.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> Bluetooth: hci_sock: Prevent race in socket write iter and sock bind<br /> <br /> There is a potential race condition between sock bind and socket write<br /> iter. bind may free the same cmd via mgmt_pending before write iter sends<br /> the cmd, just as syzbot reported in UAF[1].<br /> <br /> Here we use hci_dev_lock to synchronize the two, thereby avoiding the<br /> UAF mentioned in [1].<br /> <br /> [1]<br /> syzbot reported:<br /> BUG: KASAN: slab-use-after-free in mgmt_pending_remove+0x3b/0x210 net/bluetooth/mgmt_util.c:316<br /> Read of size 8 at addr ffff888077164818 by task syz.0.17/5989<br /> Call Trace:<br /> mgmt_pending_remove+0x3b/0x210 net/bluetooth/mgmt_util.c:316<br /> set_link_security+0x5c2/0x710 net/bluetooth/mgmt.c:1918<br /> hci_mgmt_cmd+0x9c9/0xef0 net/bluetooth/hci_sock.c:1719<br /> hci_sock_sendmsg+0x6ca/0xef0 net/bluetooth/hci_sock.c:1839<br /> sock_sendmsg_nosec net/socket.c:727 [inline]<br /> __sock_sendmsg+0x21c/0x270 net/socket.c:742<br /> sock_write_iter+0x279/0x360 net/socket.c:1195<br /> <br /> Allocated by task 5989:<br /> mgmt_pending_add+0x35/0x140 net/bluetooth/mgmt_util.c:296<br /> set_link_security+0x557/0x710 net/bluetooth/mgmt.c:1910<br /> hci_mgmt_cmd+0x9c9/0xef0 net/bluetooth/hci_sock.c:1719<br /> hci_sock_sendmsg+0x6ca/0xef0 net/bluetooth/hci_sock.c:1839<br /> sock_sendmsg_nosec net/socket.c:727 [inline]<br /> __sock_sendmsg+0x21c/0x270 net/socket.c:742<br /> sock_write_iter+0x279/0x360 net/socket.c:1195<br /> <br /> Freed by task 5991:<br /> mgmt_pending_free net/bluetooth/mgmt_util.c:311 [inline]<br /> mgmt_pending_foreach+0x30d/0x380 net/bluetooth/mgmt_util.c:257<br /> mgmt_index_removed+0x112/0x2f0 net/bluetooth/mgmt.c:9477<br /> hci_sock_bind+0xbe9/0x1000 net/bluetooth/hci_sock.c:1314

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> Bluetooth: btusb: mediatek: Fix kernel crash when releasing mtk iso interface<br /> <br /> When performing reset tests and encountering abnormal card drop issues<br /> that lead to a kernel crash, it is necessary to perform a null check<br /> before releasing resources to avoid attempting to release a null pointer.<br /> <br /> [ 29.158070] Hardware name: Google Quigon sku196612/196613 board (DT)<br /> [ 29.158076] Workqueue: hci0 hci_cmd_sync_work [bluetooth]<br /> [ 29.158154] pstate: 20400009 (nzCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)<br /> [ 29.158162] pc : klist_remove+0x90/0x158<br /> [ 29.158174] lr : klist_remove+0x88/0x158<br /> [ 29.158180] sp : ffffffc0846b3c00<br /> [ 29.158185] pmr_save: 000000e0<br /> [ 29.158188] x29: ffffffc0846b3c30 x28: ffffff80cd31f880 x27: ffffff80c1bdc058<br /> [ 29.158199] x26: dead000000000100 x25: ffffffdbdc624ea3 x24: ffffff80c1bdc4c0<br /> [ 29.158209] x23: ffffffdbdc62a3e6 x22: ffffff80c6c07000 x21: ffffffdbdc829290<br /> [ 29.158219] x20: 0000000000000000 x19: ffffff80cd3e0648 x18: 000000031ec97781<br /> [ 29.158229] x17: ffffff80c1bdc4a8 x16: ffffffdc10576548 x15: ffffff80c1180428<br /> [ 29.158238] x14: 0000000000000000 x13: 000000000000e380 x12: 0000000000000018<br /> [ 29.158248] x11: ffffff80c2a7fd10 x10: 0000000000000000 x9 : 0000000100000000<br /> [ 29.158257] x8 : 0000000000000000 x7 : 7f7f7f7f7f7f7f7f x6 : 2d7223ff6364626d<br /> [ 29.158266] x5 : 0000008000000000 x4 : 0000000000000020 x3 : 2e7325006465636e<br /> [ 29.158275] x2 : ffffffdc11afeff8 x1 : 0000000000000000 x0 : ffffffdc11be4d0c<br /> [ 29.158285] Call trace:<br /> [ 29.158290] klist_remove+0x90/0x158<br /> [ 29.158298] device_release_driver_internal+0x20c/0x268<br /> [ 29.158308] device_release_driver+0x1c/0x30<br /> [ 29.158316] usb_driver_release_interface+0x70/0x88<br /> [ 29.158325] btusb_mtk_release_iso_intf+0x68/0xd8 [btusb (HASH:e8b6 5)]<br /> [ 29.158347] btusb_mtk_reset+0x5c/0x480 [btusb (HASH:e8b6 5)]<br /> [ 29.158361] hci_cmd_sync_work+0x10c/0x188 [bluetooth (HASH:a4fa 6)]<br /> [ 29.158430] process_scheduled_works+0x258/0x4e8<br /> [ 29.158441] worker_thread+0x300/0x428<br /> [ 29.158448] kthread+0x108/0x1d0<br /> [ 29.158455] ret_from_fork+0x10/0x20<br /> [ 29.158467] Code: 91343000 940139d1 f9400268 927ff914 (f9401297)<br /> [ 29.158474] ---[ end trace 0000000000000000 ]---<br /> [ 29.167129] Kernel panic - not syncing: Oops: Fatal exception<br /> [ 29.167144] SMP: stopping secondary CPUs<br /> [ 29.167158] ------------[ cut here ]------------

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> can: gs_usb: gs_usb_xmit_callback(): fix handling of failed transmitted URBs<br /> <br /> The driver lacks the cleanup of failed transfers of URBs. This reduces the<br /> number of available URBs per error by 1. This leads to reduced performance<br /> and ultimately to a complete stop of the transmission.<br /> <br /> If the sending of a bulk URB fails do proper cleanup:<br /> - increase netdev stats<br /> - mark the echo_sbk as free<br /> - free the driver&amp;#39;s context and do accounting<br /> - wake the send queue

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> can: kvaser_usb: leaf: Fix potential infinite loop in command parsers<br /> <br /> The `kvaser_usb_leaf_wait_cmd()` and `kvaser_usb_leaf_read_bulk_callback`<br /> functions contain logic to zero-length commands. These commands are used<br /> to align data to the USB endpoint&amp;#39;s wMaxPacketSize boundary.<br /> <br /> The driver attempts to skip these placeholders by aligning the buffer<br /> position `pos` to the next packet boundary using `round_up()` function.<br /> <br /> However, if zero-length command is found exactly on a packet boundary<br /> (i.e., `pos` is a multiple of wMaxPacketSize, including 0), `round_up`<br /> function will return the unchanged value of `pos`. This prevents `pos`<br /> to be increased, causing an infinite loop in the parsing logic.<br /> <br /> This patch fixes this in the function by using `pos + 1` instead.<br /> This ensures that even if `pos` is on a boundary, the calculation is<br /> based on `pos + 1`, forcing `round_up()` to always return the next<br /> aligned boundary.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> PCI/AER: Fix NULL pointer access by aer_info<br /> <br /> The kzalloc(GFP_KERNEL) may return NULL, so all accesses to aer_info-&gt;xxx<br /> will result in kernel panic. Fix it.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> s390/pci: Avoid deadlock between PCI error recovery and mlx5 crdump<br /> <br /> Do not block PCI config accesses through pci_cfg_access_lock() when<br /> executing the s390 variant of PCI error recovery: Acquire just<br /> device_lock() instead of pci_dev_lock() as powerpc&amp;#39;s EEH and<br /> generig PCI AER processing do.<br /> <br /> During error recovery testing a pair of tasks was reported to be hung:<br /> <br /> mlx5_core 0000:00:00.1: mlx5_health_try_recover:338:(pid 5553): health recovery flow aborted, PCI reads still not working<br /> INFO: task kmcheck:72 blocked for more than 122 seconds.<br /> Not tainted 5.14.0-570.12.1.bringup7.el9.s390x #1<br /> "echo 0 &gt; /proc/sys/kernel/hung_task_timeout_secs" disables this message.<br /> task:kmcheck state:D stack:0 pid:72 tgid:72 ppid:2 flags:0x00000000<br /> Call Trace:<br /> [] __schedule+0x2a0/0x590<br /> [] schedule+0x36/0xe0<br /> [] schedule_preempt_disabled+0x22/0x30<br /> [] __mutex_lock.constprop.0+0x484/0x8a8<br /> [] mlx5_unload_one+0x34/0x58 [mlx5_core]<br /> [] mlx5_pci_err_detected+0x94/0x140 [mlx5_core]<br /> [] zpci_event_attempt_error_recovery+0xf2/0x398<br /> [] __zpci_event_error+0x23a/0x2c0<br /> INFO: task kworker/u1664:6:1514 blocked for more than 122 seconds.<br /> Not tainted 5.14.0-570.12.1.bringup7.el9.s390x #1<br /> "echo 0 &gt; /proc/sys/kernel/hung_task_timeout_secs" disables this message.<br /> task:kworker/u1664:6 state:D stack:0 pid:1514 tgid:1514 ppid:2 flags:0x00000000<br /> Workqueue: mlx5_health0000:00:00.0 mlx5_fw_fatal_reporter_err_work [mlx5_core]<br /> Call Trace:<br /> [] __schedule+0x2a0/0x590<br /> [] schedule+0x36/0xe0<br /> [] pci_wait_cfg+0x80/0xe8<br /> [] pci_cfg_access_lock+0x74/0x88<br /> [] mlx5_vsc_gw_lock+0x36/0x178 [mlx5_core]<br /> [] mlx5_crdump_collect+0x34/0x1c8 [mlx5_core]<br /> [] mlx5_fw_fatal_reporter_dump+0x6a/0xe8 [mlx5_core]<br /> [] devlink_health_do_dump.part.0+0x82/0x168<br /> [] devlink_health_report+0x19a/0x230<br /> [] mlx5_fw_fatal_reporter_err_work+0xba/0x1b0 [mlx5_core]<br /> <br /> No kernel log of the exact same error with an upstream kernel is<br /> available - but the very same deadlock situation can be constructed there,<br /> too:<br /> <br /> - task: kmcheck<br /> mlx5_unload_one() tries to acquire devlink lock while the PCI error<br /> recovery code has set pdev-&gt;block_cfg_access by way of<br /> pci_cfg_access_lock()<br /> - task: kworker<br /> mlx5_crdump_collect() tries to set block_cfg_access through<br /> pci_cfg_access_lock() while devlink_health_report() had acquired<br /> the devlink lock.<br /> <br /> A similar deadlock situation can be reproduced by requesting a<br /> crdump with<br /> &gt; devlink health dump show pci/ reporter fw_fatal<br /> <br /> while PCI error recovery is executed on the same physical function<br /> by mlx5_core&amp;#39;s pci_error_handlers. On s390 this can be injected with<br /> &gt; zpcictl --reset-fw <br /> <br /> Tests with this patch failed to reproduce that second deadlock situation,<br /> the devlink command is rejected with "kernel answers: Permission denied" -<br /> and we get a kernel log message of:<br /> <br /> mlx5_core 1ed0:00:00.1: mlx5_crdump_collect:50:(pid 254382): crdump: failed to lock vsc gw err -5<br /> <br /> because the config read of VSC_SEMAPHORE is rejected by the underlying<br /> hardware.<br /> <br /> Two prior attempts to address this issue have been discussed and<br /> ultimately rejected [see link], with the primary argument that s390&amp;#39;s<br /> implementation of PCI error recovery is imposing restrictions that<br /> neither powerpc&amp;#39;s EEH nor PCI AER handling need. Tests show that PCI<br /> error recovery on s390 is running to completion even without blocking<br /> access to PCI config space.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> tty: serial: ip22zilog: Use platform device for probing<br /> <br /> After commit 84a9582fd203 ("serial: core: Start managing serial controllers<br /> to enable runtime PM") serial drivers need to provide a device in<br /> struct uart_port.dev otherwise an oops happens. To fix this issue<br /> for ip22zilog driver switch driver to a platform driver and setup<br /> the serial device in sgi-ip22 code.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> usbnet: Prevents free active kevent<br /> <br /> The root cause of this issue are:<br /> 1. When probing the usbnet device, executing usbnet_link_change(dev, 0, 0);<br /> put the kevent work in global workqueue. However, the kevent has not yet<br /> been scheduled when the usbnet device is unregistered. Therefore, executing<br /> free_netdev() results in the "free active object (kevent)" error reported<br /> here.<br /> <br /> 2. Another factor is that when calling usbnet_disconnect()-&gt;unregister_netdev(),<br /> if the usbnet device is up, ndo_stop() is executed to cancel the kevent.<br /> However, because the device is not up, ndo_stop() is not executed.<br /> <br /> The solution to this problem is to cancel the kevent before executing<br /> free_netdev().

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> x86/CPU/AMD: Add RDSEED fix for Zen5<br /> <br /> There&amp;#39;s an issue with RDSEED&amp;#39;s 16-bit and 32-bit register output<br /> variants on Zen5 which return a random value of 0 "at a rate inconsistent<br /> with randomness while incorrectly signaling success (CF=1)". Search the<br /> web for AMD-SB-7055 for more detail.<br /> <br /> Add a fix glue which checks microcode revisions.<br /> <br /> [ bp: Add microcode revisions checking, rewrite. ]

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/msm: make sure last_fence is always updated<br /> <br /> Update last_fence in the vm-bind path instead of kernel managed path.<br /> <br /> last_fence is used to wait for work to finish in vm_bind contexts but not<br /> used for kernel managed contexts.<br /> <br /> This fixes a bug where last_fence is not waited on context close leading<br /> to faults as resources are freed while in use.<br /> <br /> Patchwork: https://patchwork.freedesktop.org/patch/680080/

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> afs: Fix delayed allocation of a cell&amp;#39;s anonymous key<br /> <br /> The allocation of a cell&amp;#39;s anonymous key is done in a background thread<br /> along with other cell setup such as doing a DNS upcall. In the reported<br /> bug, this is triggered by afs_parse_source() parsing the device name given<br /> to mount() and calling afs_lookup_cell() with the name of the cell.<br /> <br /> The normal key lookup then tries to use the key description on the<br /> anonymous authentication key as the reference for request_key() - but it<br /> may not yet be set and so an oops can happen.<br /> <br /> This has been made more likely to happen by the fix for dynamic lookup<br /> failure.<br /> <br /> Fix this by firstly allocating a reference name and attaching it to the<br /> afs_cell record when the record is created. It can share the memory<br /> allocation with the cell name (unfortunately it can&amp;#39;t just overlap the cell<br /> name by prepending it with "afs@" as the cell name already has a &amp;#39;.&amp;#39;<br /> prepended for other purposes). This reference name is then passed to<br /> request_key().<br /> <br /> Secondly, the anon key is now allocated on demand at the point a key is<br /> requested in afs_request_key() if it is not already allocated. A mutex is<br /> used to prevent multiple allocation for a cell.<br /> <br /> Thirdly, make afs_request_key_rcu() return NULL if the anonymous key isn&amp;#39;t<br /> yet allocated (if we need it) and then the caller can return -ECHILD to<br /> drop out of RCU-mode and afs_request_key() can be called.<br /> <br /> Note that the anonymous key is kind of necessary to make the key lookup<br /> cache work as that doesn&amp;#39;t currently cache a negative lookup, but it&amp;#39;s<br /> probably worth some investigation to see if NULL can be used instead.