Vulnerabilidades

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> smb: client: fix OOB reads parsing symlink error response<br /> <br /> When a CREATE returns STATUS_STOPPED_ON_SYMLINK, smb2_check_message()<br /> returns success without any length validation, leaving the symlink<br /> parsers as the only defense against an untrusted server.<br /> <br /> symlink_data() walks SMB 3.1.1 error contexts with the loop test "p ErrorId at offset 4 and p-&gt;ErrorDataLength at offset<br /> 0. When the server-controlled ErrorDataLength advances p to within 1-7<br /> bytes of end, the next iteration will read past it. When the matching<br /> context is found, sym-&gt;SymLinkErrorTag is read at offset 4 from<br /> p-&gt;ErrorContextData with no check that the symlink header itself fits.<br /> <br /> smb2_parse_symlink_response() then bounds-checks the substitute name<br /> using SMB2_SYMLINK_STRUCT_SIZE as the offset of PathBuffer from<br /> iov_base. That value is computed as sizeof(smb2_err_rsp) +<br /> sizeof(smb2_symlink_err_rsp), which is correct only when<br /> ErrorContextCount == 0.<br /> <br /> With at least one error context the symlink data sits 8 bytes deeper,<br /> and each skipped non-matching context shifts it further by 8 +<br /> ALIGN(ErrorDataLength, 8). The check is too short, allowing the<br /> substitute name read to run past iov_len. The out-of-bound heap bytes<br /> are UTF-16-decoded into the symlink target and returned to userspace via<br /> readlink(2).<br /> <br /> Fix this all up by making the loops test require the full context header<br /> to fit, rejecting sym if its header runs past end, and bound the<br /> substitute name against the actual position of sym-&gt;PathBuffer rather<br /> than a fixed offset.<br /> <br /> Because sub_offs and sub_len are 16bits, the pointer math will not<br /> overflow here with the new greater-than.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> vfio/xe: Reorganize the init to decouple migration from reset<br /> <br /> Attempting to issue reset on VF devices that don&amp;#39;t support migration<br /> leads to the following:<br /> <br /> BUG: unable to handle page fault for address: 00000000000011f8<br /> #PF: supervisor read access in kernel mode<br /> #PF: error_code(0x0000) - not-present page<br /> PGD 0 P4D 0<br /> Oops: Oops: 0000 [#1] SMP NOPTI<br /> CPU: 2 UID: 0 PID: 7443 Comm: xe_sriov_flr Tainted: G S U 7.0.0-rc1-lgci-xe-xe-4588-cec43d5c2696af219-nodebug+ #1 PREEMPT(lazy)<br /> Tainted: [S]=CPU_OUT_OF_SPEC, [U]=USER<br /> Hardware name: Intel Corporation Alder Lake Client Platform/AlderLake-P DDR4 RVP, BIOS RPLPFWI1.R00.4035.A00.2301200723 01/20/2023<br /> RIP: 0010:xe_sriov_vfio_wait_flr_done+0xc/0x80 [xe]<br /> Code: ff c3 cc cc cc cc 0f 1f 84 00 00 00 00 00 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 0f 1f 44 00 00 55 48 89 e5 41 54 53 bf f8 11 00 00 02 75 61 41 89 f4 85 f6 74 52 48 8b 47 08 48 89<br /> RSP: 0018:ffffc9000f7c39b8 EFLAGS: 00010202<br /> RAX: ffffffffa04d8660 RBX: ffff88813e3e4000 RCX: 0000000000000000<br /> RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000<br /> RBP: ffffc9000f7c39c8 R08: 0000000000000000 R09: 0000000000000000<br /> R10: 0000000000000000 R11: 0000000000000000 R12: ffff888101a48800<br /> R13: ffff88813e3e4150 R14: ffff888130d0d008 R15: ffff88813e3e40d0<br /> FS: 00007877d3d0d940(0000) GS:ffff88890b6d3000(0000) knlGS:0000000000000000<br /> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> CR2: 00000000000011f8 CR3: 000000015a762000 CR4: 0000000000f52ef0<br /> PKRU: 55555554<br /> Call Trace:<br /> <br /> xe_vfio_pci_reset_done+0x49/0x120 [xe_vfio_pci]<br /> pci_dev_restore+0x3b/0x80<br /> pci_reset_function+0x109/0x140<br /> reset_store+0x5c/0xb0<br /> dev_attr_store+0x17/0x40<br /> sysfs_kf_write+0x72/0x90<br /> kernfs_fop_write_iter+0x161/0x1f0<br /> vfs_write+0x261/0x440<br /> ksys_write+0x69/0xf0<br /> __x64_sys_write+0x19/0x30<br /> x64_sys_call+0x259/0x26e0<br /> do_syscall_64+0xcb/0x1500<br /> ? __fput+0x1a2/0x2d0<br /> ? fput_close_sync+0x3d/0xa0<br /> ? __x64_sys_close+0x3e/0x90<br /> ? x64_sys_call+0x1b7c/0x26e0<br /> ? do_syscall_64+0x109/0x1500<br /> ? __task_pid_nr_ns+0x68/0x100<br /> ? __do_sys_getpid+0x1d/0x30<br /> ? x64_sys_call+0x10b5/0x26e0<br /> ? do_syscall_64+0x109/0x1500<br /> ? putname+0x41/0x90<br /> ? do_faccessat+0x1e8/0x300<br /> ? __x64_sys_access+0x1c/0x30<br /> ? x64_sys_call+0x1822/0x26e0<br /> ? do_syscall_64+0x109/0x1500<br /> ? tick_program_event+0x43/0xa0<br /> ? hrtimer_interrupt+0x126/0x260<br /> ? irqentry_exit+0xb2/0x710<br /> entry_SYSCALL_64_after_hwframe+0x76/0x7e<br /> RIP: 0033:0x7877d5f1c5a4<br /> Code: c7 00 16 00 00 00 b8 ff ff ff ff c3 66 2e 0f 1f 84 00 00 00 00 00 f3 0f 1e fa 80 3d a5 ea 0e 00 00 74 13 b8 01 00 00 00 0f 05 3d 00 f0 ff ff 77 54 c3 0f 1f 00 55 48 89 e5 48 83 ec 20 48 89<br /> RSP: 002b:00007fff48e5f908 EFLAGS: 00000202 ORIG_RAX: 0000000000000001<br /> RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007877d5f1c5a4<br /> RDX: 0000000000000001 RSI: 00007877d621b0c9 RDI: 0000000000000009<br /> RBP: 0000000000000001 R08: 00005fb49113b010 R09: 0000000000000007<br /> R10: 0000000000000000 R11: 0000000000000202 R12: 00007877d621b0c9<br /> R13: 0000000000000009 R14: 00007fff48e5fac0 R15: 00007fff48e5fac0<br /> <br /> <br /> This is caused by the fact that some of the xe_vfio_pci_core_device<br /> members needed for handling reset are only initialized as part of<br /> migration init.<br /> <br /> Fix the problem by reorganizing the code to decouple VF init from<br /> migration init.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ALSA: ctxfi: Limit PTP to a single page<br /> <br /> Commit 391e69143d0a increased CT_PTP_NUM from 1 to 4 to support 256<br /> playback streams, but the additional pages are not used by the card<br /> correctly. The CT20K2 hardware already has multiple VMEM_PTPAL<br /> registers, but using them separately would require refactoring the<br /> entire virtual memory allocation logic.<br /> <br /> ct_vm_map() always uses PTEs in vm-&gt;ptp[0].area regardless of<br /> CT_PTP_NUM. On AMD64 systems, a single PTP covers 512 PTEs (2M). When<br /> aggregate memory allocations exceed this limit, ct_vm_map() tries to<br /> access beyond the allocated space and causes a page fault:<br /> <br /> BUG: unable to handle page fault for address: ffffd4ae8a10a000<br /> Oops: Oops: 0002 [#1] SMP PTI<br /> RIP: 0010:ct_vm_map+0x17c/0x280 [snd_ctxfi]<br /> Call Trace:<br /> atc_pcm_playback_prepare+0x225/0x3b0<br /> ct_pcm_playback_prepare+0x38/0x60<br /> snd_pcm_do_prepare+0x2f/0x50<br /> snd_pcm_action_single+0x36/0x90<br /> snd_pcm_action_nonatomic+0xbf/0xd0<br /> snd_pcm_ioctl+0x28/0x40<br /> __x64_sys_ioctl+0x97/0xe0<br /> do_syscall_64+0x81/0x610<br /> entry_SYSCALL_64_after_hwframe+0x76/0x7e<br /> <br /> Revert CT_PTP_NUM to 1. The 256 SRC_RESOURCE_NUM and playback_count<br /> remain unchanged.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> staging: sm750fb: fix division by zero in ps_to_hz()<br /> <br /> ps_to_hz() is called from hw_sm750_crtc_set_mode() without validating<br /> that pixclock is non-zero. A zero pixclock passed via FBIOPUT_VSCREENINFO<br /> causes a division by zero.<br /> <br /> Fix by rejecting zero pixclock in lynxfb_ops_check_var(), consistent<br /> with other framebuffer drivers.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> wifi: rtw88: fix device leak on probe failure<br /> <br /> Driver core holds a reference to the USB interface and its parent USB<br /> device while the interface is bound to a driver and there is no need to<br /> take additional references unless the structures are needed after<br /> disconnect.<br /> <br /> This driver takes a reference to the USB device during probe but does<br /> not to release it on all probe errors (e.g. when descriptor parsing<br /> fails).<br /> <br /> Drop the redundant device reference to fix the leak, reduce cargo<br /> culting, make it easier to spot drivers where an extra reference is<br /> needed, and reduce the risk of further memory leaks.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> fbdev: udlfb: avoid divide-by-zero on FBIOPUT_VSCREENINFO<br /> <br /> Much like commit 19f953e74356 ("fbdev: fb_pm2fb: Avoid potential divide<br /> by zero error"), we also need to prevent that same crash from happening<br /> in the udlfb driver as it uses pixclock directly when dividing, which<br /> will crash.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> usb: gadget: f_hid: don&amp;#39;t call cdev_init while cdev in use<br /> <br /> When calling unbind, then bind again, cdev_init reinitialized the cdev,<br /> even though there may still be references to it. That&amp;#39;s the case when<br /> the /dev/hidg* device is still opened. This obviously unsafe behavior<br /> like oopes.<br /> <br /> This fixes this by using cdev_alloc to put the cdev on the heap. That<br /> way, we can simply allocate a new one in hidg_bind.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> usbip: validate number_of_packets in usbip_pack_ret_submit()<br /> <br /> When a USB/IP client receives a RET_SUBMIT response,<br /> usbip_pack_ret_submit() unconditionally overwrites<br /> urb-&gt;number_of_packets from the network PDU. This value is<br /> subsequently used as the loop bound in usbip_recv_iso() and<br /> usbip_pad_iso() to iterate over urb-&gt;iso_frame_desc[], a flexible<br /> array whose size was fixed at URB allocation time based on the<br /> *original* number_of_packets from the CMD_SUBMIT.<br /> <br /> A malicious USB/IP server can set number_of_packets in the response<br /> to a value larger than what was originally submitted, causing a heap<br /> out-of-bounds write when usbip_recv_iso() writes to<br /> urb-&gt;iso_frame_desc[i] beyond the allocated region.<br /> <br /> KASAN confirmed this with kernel 7.0.0-rc5:<br /> <br /> BUG: KASAN: slab-out-of-bounds in usbip_recv_iso+0x46a/0x640<br /> Write of size 4 at addr ffff888106351d40 by task vhci_rx/69<br /> <br /> The buggy address is located 0 bytes to the right of<br /> allocated 320-byte region [ffff888106351c00, ffff888106351d40)<br /> <br /> The server side (stub_rx.c) and gadget side (vudc_rx.c) already<br /> validate number_of_packets in the CMD_SUBMIT path since commits<br /> c6688ef9f297 ("usbip: fix stub_rx: harden CMD_SUBMIT path to handle<br /> malicious input") and b78d830f0049 ("usbip: fix vudc_rx: harden<br /> CMD_SUBMIT path to handle malicious input"). The server side validates<br /> against USBIP_MAX_ISO_PACKETS because no URB exists yet at that point.<br /> On the client side we have the original URB, so we can use the tighter<br /> bound: the response must not exceed the original number_of_packets.<br /> <br /> This mirrors the existing validation of actual_length against<br /> transfer_buffer_length in usbip_recv_xbuff(), which checks the<br /> response value against the original allocation size.<br /> <br /> Kelvin Mbogo&amp;#39;s series ("usb: usbip: fix integer overflow in<br /> usbip_recv_iso()", v2) hardens the receive-side functions themselves;<br /> this patch complements that work by catching the bad value at its<br /> source -- in usbip_pack_ret_submit() before the overwrite -- and<br /> using the tighter per-URB allocation bound rather than the global<br /> USBIP_MAX_ISO_PACKETS limit.<br /> <br /> Fix this by checking rpdu-&gt;number_of_packets against<br /> urb-&gt;number_of_packets in usbip_pack_ret_submit() before the<br /> overwrite. On violation, clamp to zero so that usbip_recv_iso() and<br /> usbip_pad_iso() safely return early.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> media: vidtv: fix NULL pointer dereference in vidtv_channel_pmt_match_sections<br /> <br /> syzbot reported a general protection fault in vidtv_psi_desc_assign [1].<br /> <br /> vidtv_psi_pmt_stream_init() can return NULL on memory allocation<br /> failure, but vidtv_channel_pmt_match_sections() does not check for<br /> this. When tail is NULL, the subsequent call to<br /> vidtv_psi_desc_assign(&amp;tail-&gt;descriptor, desc) dereferences a NULL<br /> pointer offset, causing a general protection fault.<br /> <br /> Add a NULL check after vidtv_psi_pmt_stream_init(). On failure, clean<br /> up the already-allocated stream chain and return.<br /> <br /> [1]<br /> Oops: general protection fault, probably for non-canonical address 0xdffffc0000000000: 0000 [#1] SMP KASAN PTI<br /> KASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007]<br /> RIP: 0010:vidtv_psi_desc_assign+0x24/0x90 drivers/media/test-drivers/vidtv/vidtv_psi.c:629<br /> Call Trace:<br /> <br /> vidtv_channel_pmt_match_sections drivers/media/test-drivers/vidtv/vidtv_channel.c:349 [inline]<br /> vidtv_channel_si_init+0x1445/0x1a50 drivers/media/test-drivers/vidtv/vidtv_channel.c:479<br /> vidtv_mux_init+0x526/0xbe0 drivers/media/test-drivers/vidtv/vidtv_mux.c:519<br /> vidtv_start_streaming drivers/media/test-drivers/vidtv/vidtv_bridge.c:194 [inline]<br /> vidtv_start_feed+0x33e/0x4d0 drivers/media/test-drivers/vidtv/vidtv_bridge.c:239

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> arm64: mm: Handle invalid large leaf mappings correctly<br /> <br /> It has been possible for a long time to mark ptes in the linear map as<br /> invalid. This is done for secretmem, kfence, realm dma memory un/share,<br /> and others, by simply clearing the PTE_VALID bit. But until commit<br /> a166563e7ec37 ("arm64: mm: support large block mapping when<br /> rodata=full") large leaf mappings were never made invalid in this way.<br /> <br /> It turns out various parts of the code base are not equipped to handle<br /> invalid large leaf mappings (in the way they are currently encoded) and<br /> I&amp;#39;ve observed a kernel panic while booting a realm guest on a<br /> BBML2_NOABORT system as a result:<br /> <br /> [ 15.432706] software IO TLB: Memory encryption is active and system is using DMA bounce buffers<br /> [ 15.476896] Unable to handle kernel paging request at virtual address ffff000019600000<br /> [ 15.513762] Mem abort info:<br /> [ 15.527245] ESR = 0x0000000096000046<br /> [ 15.548553] EC = 0x25: DABT (current EL), IL = 32 bits<br /> [ 15.572146] SET = 0, FnV = 0<br /> [ 15.592141] EA = 0, S1PTW = 0<br /> [ 15.612694] FSC = 0x06: level 2 translation fault<br /> [ 15.640644] Data abort info:<br /> [ 15.661983] ISV = 0, ISS = 0x00000046, ISS2 = 0x00000000<br /> [ 15.694875] CM = 0, WnR = 1, TnD = 0, TagAccess = 0<br /> [ 15.723740] GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0<br /> [ 15.755776] swapper pgtable: 4k pages, 48-bit VAs, pgdp=0000000081f3f000<br /> [ 15.800410] [ffff000019600000] pgd=0000000000000000, p4d=180000009ffff403, pud=180000009fffe403, pmd=00e8000199600704<br /> [ 15.855046] Internal error: Oops: 0000000096000046 [#1] SMP<br /> [ 15.886394] Modules linked in:<br /> [ 15.900029] CPU: 0 UID: 0 PID: 1 Comm: swapper/0 Not tainted 7.0.0-rc4-dirty #4 PREEMPT<br /> [ 15.935258] Hardware name: linux,dummy-virt (DT)<br /> [ 15.955612] pstate: 21400005 (nzCv daif +PAN -UAO -TCO +DIT -SSBS BTYPE=--)<br /> [ 15.986009] pc : __pi_memcpy_generic+0x128/0x22c<br /> [ 16.006163] lr : swiotlb_bounce+0xf4/0x158<br /> [ 16.024145] sp : ffff80008000b8f0<br /> [ 16.038896] x29: ffff80008000b8f0 x28: 0000000000000000 x27: 0000000000000000<br /> [ 16.069953] x26: ffffb3976d261ba8 x25: 0000000000000000 x24: ffff000019600000<br /> [ 16.100876] x23: 0000000000000001 x22: ffff0000043430d0 x21: 0000000000007ff0<br /> [ 16.131946] x20: 0000000084570010 x19: 0000000000000000 x18: ffff00001ffe3fcc<br /> [ 16.163073] x17: 0000000000000000 x16: 00000000003fffff x15: 646e612065766974<br /> [ 16.194131] x14: 0000000000000000 x13: 0000000000000000 x12: 0000000000000000<br /> [ 16.225059] x11: 0000000000000000 x10: 0000000000000010 x9 : 0000000000000018<br /> [ 16.256113] x8 : 0000000000000018 x7 : 0000000000000000 x6 : 0000000000000000<br /> [ 16.287203] x5 : ffff000019607ff0 x4 : ffff000004578000 x3 : ffff000019600000<br /> [ 16.318145] x2 : 0000000000007ff0 x1 : ffff000004570010 x0 : ffff000019600000<br /> [ 16.349071] Call trace:<br /> [ 16.360143] __pi_memcpy_generic+0x128/0x22c (P)<br /> [ 16.380310] swiotlb_tbl_map_single+0x154/0x2b4<br /> [ 16.400282] swiotlb_map+0x5c/0x228<br /> [ 16.415984] dma_map_phys+0x244/0x2b8<br /> [ 16.432199] dma_map_page_attrs+0x44/0x58<br /> [ 16.449782] virtqueue_map_page_attrs+0x38/0x44<br /> [ 16.469596] virtqueue_map_single_attrs+0xc0/0x130<br /> [ 16.490509] virtnet_rq_alloc.isra.0+0xa4/0x1fc<br /> [ 16.510355] try_fill_recv+0x2a4/0x584<br /> [ 16.526989] virtnet_open+0xd4/0x238<br /> [ 16.542775] __dev_open+0x110/0x24c<br /> [ 16.558280] __dev_change_flags+0x194/0x20c<br /> [ 16.576879] netif_change_flags+0x24/0x6c<br /> [ 16.594489] dev_change_flags+0x48/0x7c<br /> [ 16.611462] ip_auto_config+0x258/0x1114<br /> [ 16.628727] do_one_initcall+0x80/0x1c8<br /> [ 16.645590] kernel_init_freeable+0x208/0x2f0<br /> [ 16.664917] kernel_init+0x24/0x1e0<br /> [ 16.680295] ret_from_fork+0x10/0x20<br /> [ 16.696369] Code: 927cec03 cb0e0021 8b0e0042 a9411c26 (a900340c)<br /> [ 16.723106] ---[ end trace 0000000000000000 ]---<br /> [ 16.752866] Kernel panic - not syncing: Attempted to kill init! exitcode=0x0000000b<br /> [ 16.792556] Kernel Offset: 0x3396ea200000 from 0xffff8000800000<br /> ---truncated---

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> PCI: endpoint: pci-epf-vntb: Remove duplicate resource teardown<br /> <br /> epf_ntb_epc_destroy() duplicates the teardown that the caller is<br /> supposed to perform later. This leads to an oops when .allow_link fails<br /> or when .drop_link is performed. The following is an example oops of the<br /> former case:<br /> <br /> Unable to handle kernel paging request at virtual address dead000000000108<br /> [...]<br /> [dead000000000108] address between user and kernel address ranges<br /> Internal error: Oops: 0000000096000044 [#1] SMP<br /> [...]<br /> Call trace:<br /> pci_epc_remove_epf+0x78/0xe0 (P)<br /> pci_primary_epc_epf_link+0x88/0xa8<br /> configfs_symlink+0x1f4/0x5a0<br /> vfs_symlink+0x134/0x1d8<br /> do_symlinkat+0x88/0x138<br /> __arm64_sys_symlinkat+0x74/0xe0<br /> [...]<br /> <br /> Remove the helper, and drop pci_epc_put(). EPC device refcounting is<br /> tied to the configfs EPC group lifetime, and pci_epc_put() in the<br /> .drop_link path is sufficient.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> PCI: endpoint: pci-epf-vntb: Stop cmd_handler work in epf_ntb_epc_cleanup<br /> <br /> Disable the delayed work before clearing BAR mappings and doorbells to<br /> avoid running the handler after resources have been torn down.<br /> <br /> Unable to handle kernel paging request at virtual address ffff800083f46004<br /> [...]<br /> Internal error: Oops: 0000000096000007 [#1] SMP<br /> [...]<br /> Call trace:<br /> epf_ntb_cmd_handler+0x54/0x200 [pci_epf_vntb] (P)<br /> process_one_work+0x154/0x3b0<br /> worker_thread+0x2c8/0x400<br /> kthread+0x148/0x210<br /> ret_from_fork+0x10/0x20