Vulnerabilidades

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ASoC: qcom: audioreach: fix potential null pointer dereference<br /> <br /> It is possible that the topology parsing function<br /> audioreach_widget_load_module_common() could return NULL or an error<br /> pointer. Add missing NULL check so that we do not dereference it.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> media: stm32-csi: Fix dereference before NULL check<br /> <br /> In &amp;#39;stm32_csi_start&amp;#39;, &amp;#39;csidev-&gt;s_subdev&amp;#39; is dereferenced directly while<br /> assigning a value to the &amp;#39;src_pad&amp;#39;. However the same value is being<br /> checked against NULL at a later point of time indicating that there<br /> are chances that the value can be NULL.<br /> <br /> Move the dereference after the NULL check.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> media: uvcvideo: Mark invalid entities with id UVC_INVALID_ENTITY_ID<br /> <br /> Per UVC 1.1+ specification 3.7.2, units and terminals must have a non-zero<br /> unique ID.<br /> <br /> ```<br /> Each Unit and Terminal within the video function is assigned a unique<br /> identification number, the Unit ID (UID) or Terminal ID (TID), contained in<br /> the bUnitID or bTerminalID field of the descriptor. The value 0x00 is<br /> reserved for undefined ID,<br /> ```<br /> <br /> If we add a new entity with id 0 or a duplicated ID, it will be marked<br /> as UVC_INVALID_ENTITY_ID.<br /> <br /> In a previous attempt commit 3dd075fe8ebb ("media: uvcvideo: Require<br /> entities to have a non-zero unique ID"), we ignored all the invalid units,<br /> this broke a lot of non-compatible cameras. Hopefully we are more lucky<br /> this time.<br /> <br /> This also prevents some syzkaller reproducers from triggering warnings due<br /> to a chain of entities referring to themselves. In one particular case, an<br /> Output Unit is connected to an Input Unit, both with the same ID of 1. But<br /> when looking up for the source ID of the Output Unit, that same entity is<br /> found instead of the input entity, which leads to such warnings.<br /> <br /> In another case, a backward chain was considered finished as the source ID<br /> was 0. Later on, that entity was found, but its pads were not valid.<br /> <br /> Here is a sample stack trace for one of those cases.<br /> <br /> [ 20.650953] usb 1-1: new high-speed USB device number 2 using dummy_hcd<br /> [ 20.830206] usb 1-1: Using ep0 maxpacket: 8<br /> [ 20.833501] usb 1-1: config 0 descriptor??<br /> [ 21.038518] usb 1-1: string descriptor 0 read error: -71<br /> [ 21.038893] usb 1-1: Found UVC 0.00 device (2833:0201)<br /> [ 21.039299] uvcvideo 1-1:0.0: Entity type for entity Output 1 was not initialized!<br /> [ 21.041583] uvcvideo 1-1:0.0: Entity type for entity Input 1 was not initialized!<br /> [ 21.042218] ------------[ cut here ]------------<br /> [ 21.042536] WARNING: CPU: 0 PID: 9 at drivers/media/mc/mc-entity.c:1147 media_create_pad_link+0x2c4/0x2e0<br /> [ 21.043195] Modules linked in:<br /> [ 21.043535] CPU: 0 UID: 0 PID: 9 Comm: kworker/0:1 Not tainted 6.11.0-rc7-00030-g3480e43aeccf #444<br /> [ 21.044101] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.15.0-1 04/01/2014<br /> [ 21.044639] Workqueue: usb_hub_wq hub_event<br /> [ 21.045100] RIP: 0010:media_create_pad_link+0x2c4/0x2e0<br /> [ 21.045508] Code: fe e8 20 01 00 00 b8 f4 ff ff ff 48 83 c4 30 5b 41 5c 41 5d 41 5e 41 5f 5d c3 cc cc cc cc 0f 0b eb e9 0f 0b eb 0a 0f 0b eb 06 0b eb 02 0f 0b b8 ea ff ff ff eb d4 66 2e 0f 1f 84 00 00 00 00<br /> [ 21.046801] RSP: 0018:ffffc9000004b318 EFLAGS: 00010246<br /> [ 21.047227] RAX: ffff888004e5d458 RBX: 0000000000000000 RCX: ffffffff818fccf1<br /> [ 21.047719] RDX: 000000000000007b RSI: 0000000000000000 RDI: ffff888004313290<br /> [ 21.048241] RBP: ffff888004313290 R08: 0001ffffffffffff R09: 0000000000000000<br /> [ 21.048701] R10: 0000000000000013 R11: 0001888004313290 R12: 0000000000000003<br /> [ 21.049138] R13: ffff888004313080 R14: ffff888004313080 R15: 0000000000000000<br /> [ 21.049648] FS: 0000000000000000(0000) GS:ffff88803ec00000(0000) knlGS:0000000000000000<br /> [ 21.050271] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> [ 21.050688] CR2: 0000592cc27635b0 CR3: 000000000431c000 CR4: 0000000000750ef0<br /> [ 21.051136] PKRU: 55555554<br /> [ 21.051331] Call Trace:<br /> [ 21.051480] <br /> [ 21.051611] ? __warn+0xc4/0x210<br /> [ 21.051861] ? media_create_pad_link+0x2c4/0x2e0<br /> [ 21.052252] ? report_bug+0x11b/0x1a0<br /> [ 21.052540] ? trace_hardirqs_on+0x31/0x40<br /> [ 21.052901] ? handle_bug+0x3d/0x70<br /> [ 21.053197] ? exc_invalid_op+0x1a/0x50<br /> [ 21.053511] ? asm_exc_invalid_op+0x1a/0x20<br /> [ 21.053924] ? media_create_pad_link+0x91/0x2e0<br /> [ 21.054364] ? media_create_pad_link+0x2c4/0x2e0<br /> [ 21.054834] ? media_create_pad_link+0x91/0x2e0<br /> [ 21.055131] ? _raw_spin_unlock+0x1e/0x40<br /> [ 21.055441] ? __v4l2_device_register_subdev+0x202/0x210<br /> [ 21.055837] uvc_mc_register_entities+0x358/0x400<br /> [ 21.056144] uvc_register_chains+0x1<br /> ---truncated---

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> media: iris: Fix memory leak by freeing untracked persist buffer<br /> <br /> One internal buffer which is allocated only once per session was not<br /> being freed during session close because it was not being tracked as<br /> part of internal buffer list which resulted in a memory leak.<br /> <br /> Add the necessary logic to explicitly free the untracked internal buffer<br /> during session close to ensure all allocated memory is released<br /> properly.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> spi: cadence-quadspi: Implement refcount to handle unbind during busy<br /> <br /> driver support indirect read and indirect write operation with<br /> assumption no force device removal(unbind) operation. However<br /> force device removal(removal) is still available to root superuser.<br /> <br /> Unbinding driver during operation causes kernel crash. This changes<br /> ensure driver able to handle such operation for indirect read and<br /> indirect write by implementing refcount to track attached devices<br /> to the controller and gracefully wait and until attached devices<br /> remove operation completed before proceed with removal operation.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mm/hugetlb: fix folio is still mapped when deleted<br /> <br /> Migration may be raced with fallocating hole. remove_inode_single_folio<br /> will unmap the folio if the folio is still mapped. However, it&amp;#39;s called<br /> without folio lock. If the folio is migrated and the mapped pte has been<br /> converted to migration entry, folio_mapped() returns false, and won&amp;#39;t<br /> unmap it. Due to extra refcount held by remove_inode_single_folio,<br /> migration fails, restores migration entry to normal pte, and the folio is<br /> mapped again. As a result, we triggered BUG in filemap_unaccount_folio.<br /> <br /> The log is as follows:<br /> BUG: Bad page cache in process hugetlb pfn:156c00<br /> page: refcount:515 mapcount:0 mapping:0000000099fef6e1 index:0x0 pfn:0x156c00<br /> head: order:9 mapcount:1 entire_mapcount:1 nr_pages_mapped:0 pincount:0<br /> aops:hugetlbfs_aops ino:dcc dentry name(?):"my_hugepage_file"<br /> flags: 0x17ffffc00000c1(locked|waiters|head|node=0|zone=2|lastcpupid=0x1fffff)<br /> page_type: f4(hugetlb)<br /> page dumped because: still mapped when deleted<br /> CPU: 1 UID: 0 PID: 395 Comm: hugetlb Not tainted 6.17.0-rc5-00044-g7aac71907bde-dirty #484 NONE<br /> Hardware name: QEMU Ubuntu 24.04 PC (i440FX + PIIX, 1996), BIOS 0.0.0 02/06/2015<br /> Call Trace:<br /> <br /> dump_stack_lvl+0x4f/0x70<br /> filemap_unaccount_folio+0xc4/0x1c0<br /> __filemap_remove_folio+0x38/0x1c0<br /> filemap_remove_folio+0x41/0xd0<br /> remove_inode_hugepages+0x142/0x250<br /> hugetlbfs_fallocate+0x471/0x5a0<br /> vfs_fallocate+0x149/0x380<br /> <br /> Hold folio lock before checking if the folio is mapped to avold race with<br /> migration.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> netfs: fix reference leak<br /> <br /> Commit 20d72b00ca81 ("netfs: Fix the request&amp;#39;s work item to not<br /> require a ref") modified netfs_alloc_request() to initialize the<br /> reference counter to 2 instead of 1. The rationale was that the<br /> requet&amp;#39;s "work" would release the second reference after completion<br /> (via netfs_{read,write}_collection_worker()). That works most of the<br /> time if all goes well.<br /> <br /> However, it leaks this additional reference if the request is released<br /> before the I/O operation has been submitted: the error code path only<br /> decrements the reference counter once and the work item will never be<br /> queued because there will never be a completion.<br /> <br /> This has caused outages of our whole server cluster today because<br /> tasks were blocked in netfs_wait_for_outstanding_io(), leading to<br /> deadlocks in Ceph (another bug that I will address soon in another<br /> patch). This was caused by a netfs_pgpriv2_begin_copy_to_cache() call<br /> which failed in fscache_begin_write_operation(). The leaked<br /> netfs_io_request was never completed, leaving `netfs_inode.io_count`<br /> with a positive value forever.<br /> <br /> All of this is super-fragile code. Finding out which code paths will<br /> lead to an eventual completion and which do not is hard to see:<br /> <br /> - Some functions like netfs_create_write_req() allocate a request, but<br /> will never submit any I/O.<br /> <br /> - netfs_unbuffered_read_iter_locked() calls netfs_unbuffered_read()<br /> and then netfs_put_request(); however, netfs_unbuffered_read() can<br /> also fail early before submitting the I/O request, therefore another<br /> netfs_put_request() call must be added there.<br /> <br /> A rule of thumb is that functions that return a `netfs_io_request` do<br /> not submit I/O, and all of their callers must be checked.<br /> <br /> For my taste, the whole netfs code needs an overhaul to make reference<br /> counting easier to understand and less fragile &amp; obscure. But to fix<br /> this bug here and now and produce a patch that is adequate for a<br /> stable backport, I tried a minimal approach that quickly frees the<br /> request object upon early failure.<br /> <br /> I decided against adding a second netfs_put_request() each time<br /> because that would cause code duplication which obscures the code<br /> further. Instead, I added the function netfs_put_failed_request()<br /> which frees such a failed request synchronously under the assumption<br /> that the reference count is exactly 2 (as initially set by<br /> netfs_alloc_request() and never touched), verified by a<br /> WARN_ON_ONCE(). It then deinitializes the request object (without<br /> going through the "cleanup_work" indirection) and frees the allocation<br /> (with RCU protection to protect against concurrent access by<br /> netfs_requests_seq_start()).<br /> <br /> All code paths that fail early have been changed to call<br /> netfs_put_failed_request() instead of netfs_put_request().<br /> Additionally, I have added a netfs_put_request() call to<br /> netfs_unbuffered_read() as explained above because the<br /> netfs_put_failed_request() approach does not work there.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> kmsan: fix out-of-bounds access to shadow memory<br /> <br /> Running sha224_kunit on a KMSAN-enabled kernel results in a crash in<br /> kmsan_internal_set_shadow_origin():<br /> <br /> BUG: unable to handle page fault for address: ffffbc3840291000<br /> #PF: supervisor read access in kernel mode<br /> #PF: error_code(0x0000) - not-present page<br /> PGD 1810067 P4D 1810067 PUD 192d067 PMD 3c17067 PTE 0<br /> Oops: 0000 [#1] SMP NOPTI<br /> CPU: 0 UID: 0 PID: 81 Comm: kunit_try_catch Tainted: G N 6.17.0-rc3 #10 PREEMPT(voluntary)<br /> Tainted: [N]=TEST<br /> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.17.0-0-gb52ca86e094d-prebuilt.qemu.org 04/01/2014<br /> RIP: 0010:kmsan_internal_set_shadow_origin+0x91/0x100<br /> [...]<br /> Call Trace:<br /> <br /> __msan_memset+0xee/0x1a0<br /> sha224_final+0x9e/0x350<br /> test_hash_buffer_overruns+0x46f/0x5f0<br /> ? kmsan_get_shadow_origin_ptr+0x46/0xa0<br /> ? __pfx_test_hash_buffer_overruns+0x10/0x10<br /> kunit_try_run_case+0x198/0xa00<br /> <br /> This occurs when memset() is called on a buffer that is not 4-byte aligned<br /> and extends to the end of a guard page, i.e. the next page is unmapped.<br /> <br /> The bug is that the loop at the end of kmsan_internal_set_shadow_origin()<br /> accesses the wrong shadow memory bytes when the address is not 4-byte<br /> aligned. Since each 4 bytes are associated with an origin, it rounds the<br /> address and size so that it can access all the origins that contain the<br /> buffer. However, when it checks the corresponding shadow bytes for a<br /> particular origin, it incorrectly uses the original unrounded shadow<br /> address. This results in reads from shadow memory beyond the end of the<br /> buffer&amp;#39;s shadow memory, which crashes when that memory is not mapped.<br /> <br /> To fix this, correctly align the shadow address before accessing the 4<br /> shadow bytes corresponding to each origin.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> fs/proc/task_mmu: check p-&gt;vec_buf for NULL<br /> <br /> When the PAGEMAP_SCAN ioctl is invoked with vec_len = 0 reaches<br /> pagemap_scan_backout_range(), kernel panics with null-ptr-deref:<br /> <br /> [ 44.936808] Oops: general protection fault, probably for non-canonical address 0xdffffc0000000000: 0000 [#1] SMP DEBUG_PAGEALLOC KASAN NOPTI<br /> [ 44.937797] KASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007]<br /> [ 44.938391] CPU: 1 UID: 0 PID: 2480 Comm: reproducer Not tainted 6.17.0-rc6 #22 PREEMPT(none)<br /> [ 44.939062] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.3-0-ga6ed6b701f0a-prebuilt.qemu.org 04/01/2014<br /> [ 44.939935] RIP: 0010:pagemap_scan_thp_entry.isra.0+0x741/0xa80<br /> <br /> <br /> <br /> [ 44.946828] Call Trace:<br /> [ 44.947030] <br /> [ 44.949219] pagemap_scan_pmd_entry+0xec/0xfa0<br /> [ 44.952593] walk_pmd_range.isra.0+0x302/0x910<br /> [ 44.954069] walk_pud_range.isra.0+0x419/0x790<br /> [ 44.954427] walk_p4d_range+0x41e/0x620<br /> [ 44.954743] walk_pgd_range+0x31e/0x630<br /> [ 44.955057] __walk_page_range+0x160/0x670<br /> [ 44.956883] walk_page_range_mm+0x408/0x980<br /> [ 44.958677] walk_page_range+0x66/0x90<br /> [ 44.958984] do_pagemap_scan+0x28d/0x9c0<br /> [ 44.961833] do_pagemap_cmd+0x59/0x80<br /> [ 44.962484] __x64_sys_ioctl+0x18d/0x210<br /> [ 44.962804] do_syscall_64+0x5b/0x290<br /> [ 44.963111] entry_SYSCALL_64_after_hwframe+0x76/0x7e<br /> <br /> vec_len = 0 in pagemap_scan_init_bounce_buffer() means no buffers are<br /> allocated and p-&gt;vec_buf remains set to NULL.<br /> <br /> This breaks an assumption made later in pagemap_scan_backout_range(), that<br /> page_region is always allocated for p-&gt;vec_buf_index.<br /> <br /> Fix it by explicitly checking p-&gt;vec_buf for NULL before dereferencing.<br /> <br /> Other sites that might run into same deref-issue are already (directly or<br /> transitively) protected by checking p-&gt;vec_buf.<br /> <br /> Note:<br /> From PAGEMAP_SCAN man page, it seems vec_len = 0 is valid when no output<br /> is requested and it&amp;#39;s only the side effects caller is interested in,<br /> hence it passes check in pagemap_scan_get_args().<br /> <br /> This issue was found by syzkaller.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> afs: Fix potential null pointer dereference in afs_put_server<br /> <br /> afs_put_server() accessed server-&gt;debug_id before the NULL check, which<br /> could lead to a null pointer dereference. Move the debug_id assignment,<br /> ensuring we never dereference a NULL server pointer.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/gma500: Fix null dereference in hdmi teardown<br /> <br /> pci_set_drvdata sets the value of pdev-&gt;driver_data to NULL,<br /> after which the driver_data obtained from the same dev is<br /> dereferenced in oaktrail_hdmi_i2c_exit, and the i2c_dev is<br /> extracted from it. To prevent this, swap these calls.<br /> <br /> Found by Linux Verification Center (linuxtesting.org) with Svacer.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net/smc: fix warning in smc_rx_splice() when calling get_page()<br /> <br /> smc_lo_register_dmb() allocates DMB buffers with kzalloc(), which are<br /> later passed to get_page() in smc_rx_splice(). Since kmalloc memory is<br /> not page-backed, this triggers WARN_ON_ONCE() in get_page() and prevents<br /> holding a refcount on the buffer. This can lead to use-after-free if<br /> the memory is released before splice_to_pipe() completes.<br /> <br /> Use folio_alloc() instead, ensuring DMBs are page-backed and safe for<br /> get_page().<br /> <br /> WARNING: CPU: 18 PID: 12152 at ./include/linux/mm.h:1330 smc_rx_splice+0xaf8/0xe20 [smc]<br /> CPU: 18 UID: 0 PID: 12152 Comm: smcapp Kdump: loaded Not tainted 6.17.0-rc3-11705-g9cf4672ecfee #10 NONE<br /> Hardware name: IBM 3931 A01 704 (z/VM 7.4.0)<br /> Krnl PSW : 0704e00180000000 000793161032696c (smc_rx_splice+0xafc/0xe20 [smc])<br /> R:0 T:1 IO:1 EX:1 Key:0 M:1 W:0 P:0 AS:3 CC:2 PM:0 RI:0 EA:3<br /> Krnl GPRS: 0000000000000000 001cee80007d3001 00077400000000f8 0000000000000005<br /> 0000000000000001 001cee80007d3006 0007740000001000 001c000000000000<br /> 000000009b0c99e0 0000000000001000 001c0000000000f8 001c000000000000<br /> 000003ffcc6f7c88 0007740003e98000 0007931600000005 000792969b2ff7b8<br /> Krnl Code: 0007931610326960: af000000 mc 0,0<br /> 0007931610326964: a7f4ff43 brc 15,00079316103267ea<br /> #0007931610326968: af000000 mc 0,0<br /> &gt;000793161032696c: a7f4ff3f brc 15,00079316103267ea<br /> 0007931610326970: e320f1000004 lg %r2,256(%r15)<br /> 0007931610326976: c0e53fd1b5f5 brasl %r14,000793168fd5d560<br /> 000793161032697c: a7f4fbb5 brc 15,00079316103260e6<br /> 0007931610326980: b904002b lgr %r2,%r11<br /> Call Trace:<br /> smc_rx_splice+0xafc/0xe20 [smc]<br /> smc_rx_splice+0x756/0xe20 [smc])<br /> smc_rx_recvmsg+0xa74/0xe00 [smc]<br /> smc_splice_read+0x1ce/0x3b0 [smc]<br /> sock_splice_read+0xa2/0xf0<br /> do_splice_read+0x198/0x240<br /> splice_file_to_pipe+0x7e/0x110<br /> do_splice+0x59e/0xde0<br /> __do_splice+0x11a/0x2d0<br /> __s390x_sys_splice+0x140/0x1f0<br /> __do_syscall+0x122/0x280<br /> system_call+0x6e/0x90<br /> Last Breaking-Event-Address:<br /> smc_rx_splice+0x960/0xe20 [smc]<br /> ---[ end trace 0000000000000000 ]---