Vulnerabilidades

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> wifi: p54: prevent buffer-overflow in p54_rx_eeprom_readback()<br /> <br /> Robert Morris reported:<br /> <br /> |If a malicious USB device pretends to be an Intersil p54 wifi<br /> |interface and generates an eeprom_readback message with a large<br /> |eeprom-&gt;v1.len, p54_rx_eeprom_readback() will copy data from the<br /> |message beyond the end of priv-&gt;eeprom.<br /> |<br /> |static void p54_rx_eeprom_readback(struct p54_common *priv,<br /> | struct sk_buff *skb)<br /> |{<br /> | struct p54_hdr *hdr = (struct p54_hdr *) skb-&gt;data;<br /> | struct p54_eeprom_lm86 *eeprom = (struct p54_eeprom_lm86 *) hdr-&gt;data;<br /> |<br /> | if (priv-&gt;fw_var &gt;= 0x509) {<br /> | memcpy(priv-&gt;eeprom, eeprom-&gt;v2.data,<br /> | le16_to_cpu(eeprom-&gt;v2.len));<br /> | } else {<br /> | memcpy(priv-&gt;eeprom, eeprom-&gt;v1.data,<br /> | le16_to_cpu(eeprom-&gt;v1.len));<br /> | }<br /> | [...]<br /> <br /> The eeprom-&gt;v{1,2}.len is set by the driver in p54_download_eeprom().<br /> The device is supposed to provide the same length back to the driver.<br /> But yes, it&amp;#39;s possible (like shown in the report) to alter the value<br /> to something that causes a crash/panic due to overrun.<br /> <br /> This patch addresses the issue by adding the size to the common device<br /> context, so p54_rx_eeprom_readback no longer relies on possibly tampered<br /> values... That said, it also checks if the "firmware" altered the value<br /> and no longer copies them.<br /> <br /> The one, small saving grace is: Before the driver tries to read the eeprom,<br /> it needs to upload &gt;a

*** Pendiente de traducción *** An issue has been discovered in GitLab EE affecting all versions from 13.3 before 17.11.6, 18.0 before 18.0.4, and 18.1 before 18.1.2 that could have allowed authenticated project owners to bypass group-level forking restrictions by manipulating API requests.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> Input: gpio-keys - fix a sleep while atomic with PREEMPT_RT<br /> <br /> When enabling PREEMPT_RT, the gpio_keys_irq_timer() callback runs in<br /> hard irq context, but the input_event() takes a spin_lock, which isn&amp;#39;t<br /> allowed there as it is converted to a rt_spin_lock().<br /> <br /> [ 4054.289999] BUG: sleeping function called from invalid context at kernel/locking/spinlock_rt.c:48<br /> [ 4054.290028] in_atomic(): 1, irqs_disabled(): 1, non_block: 0, pid: 0, name: swapper/0<br /> ...<br /> [ 4054.290195] __might_resched+0x13c/0x1f4<br /> [ 4054.290209] rt_spin_lock+0x54/0x11c<br /> [ 4054.290219] input_event+0x48/0x80<br /> [ 4054.290230] gpio_keys_irq_timer+0x4c/0x78<br /> [ 4054.290243] __hrtimer_run_queues+0x1a4/0x438<br /> [ 4054.290257] hrtimer_interrupt+0xe4/0x240<br /> [ 4054.290269] arch_timer_handler_phys+0x2c/0x44<br /> [ 4054.290283] handle_percpu_devid_irq+0x8c/0x14c<br /> [ 4054.290297] handle_irq_desc+0x40/0x58<br /> [ 4054.290307] generic_handle_domain_irq+0x1c/0x28<br /> [ 4054.290316] gic_handle_irq+0x44/0xcc<br /> <br /> Considering the gpio_keys_irq_isr() can run in any context, e.g. it can<br /> be threaded, it seems there&amp;#39;s no point in requesting the timer isr to<br /> run in hard irq context.<br /> <br /> Relax the hrtimer not to use the hard context.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ata: pata_via: Force PIO for ATAPI devices on VT6415/VT6330<br /> <br /> The controller has a hardware bug that can hard hang the system when<br /> doing ATAPI DMAs without any trace of what happened. Depending on the<br /> device attached, it can also prevent the system from booting.<br /> <br /> In this case, the system hangs when reading the ATIP from optical media<br /> with cdrecord -vvv -atip on an _NEC DVD_RW ND-4571A 1-01 and an<br /> Optiarc DVD RW AD-7200A 1.06 attached to an ASRock 990FX Extreme 4,<br /> running at UDMA/33.<br /> <br /> The issue can be reproduced by running the same command with a cygwin<br /> build of cdrecord on WinXP, although it requires more attempts to cause<br /> it. The hang in that case is also resolved by forcing PIO. It doesn&amp;#39;t<br /> appear that VIA has produced any drivers for that OS, thus no known<br /> workaround exists.<br /> <br /> HDDs attached to the controller do not suffer from any DMA issues.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> jbd2: fix data-race and null-ptr-deref in jbd2_journal_dirty_metadata()<br /> <br /> Since handle-&gt;h_transaction may be a NULL pointer, so we should change it<br /> to call is_handle_aborted(handle) first before dereferencing it.<br /> <br /> And the following data-race was reported in my fuzzer:<br /> <br /> ==================================================================<br /> BUG: KCSAN: data-race in jbd2_journal_dirty_metadata / jbd2_journal_dirty_metadata<br /> <br /> write to 0xffff888011024104 of 4 bytes by task 10881 on cpu 1:<br /> jbd2_journal_dirty_metadata+0x2a5/0x770 fs/jbd2/transaction.c:1556<br /> __ext4_handle_dirty_metadata+0xe7/0x4b0 fs/ext4/ext4_jbd2.c:358<br /> ext4_do_update_inode fs/ext4/inode.c:5220 [inline]<br /> ext4_mark_iloc_dirty+0x32c/0xd50 fs/ext4/inode.c:5869<br /> __ext4_mark_inode_dirty+0xe1/0x450 fs/ext4/inode.c:6074<br /> ext4_dirty_inode+0x98/0xc0 fs/ext4/inode.c:6103<br /> ....<br /> <br /> read to 0xffff888011024104 of 4 bytes by task 10880 on cpu 0:<br /> jbd2_journal_dirty_metadata+0xf2/0x770 fs/jbd2/transaction.c:1512<br /> __ext4_handle_dirty_metadata+0xe7/0x4b0 fs/ext4/ext4_jbd2.c:358<br /> ext4_do_update_inode fs/ext4/inode.c:5220 [inline]<br /> ext4_mark_iloc_dirty+0x32c/0xd50 fs/ext4/inode.c:5869<br /> __ext4_mark_inode_dirty+0xe1/0x450 fs/ext4/inode.c:6074<br /> ext4_dirty_inode+0x98/0xc0 fs/ext4/inode.c:6103<br /> ....<br /> <br /> value changed: 0x00000000 -&gt; 0x00000001<br /> ==================================================================<br /> <br /> This issue is caused by missing data-race annotation for jh-&gt;b_modified.<br /> Therefore, the missing annotation needs to be added.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> fs/nfs/read: fix double-unlock bug in nfs_return_empty_folio()<br /> <br /> Sometimes, when a file was read while it was being truncated by<br /> another NFS client, the kernel could deadlock because folio_unlock()<br /> was called twice, and the second call would XOR back the `PG_locked`<br /> flag.<br /> <br /> Most of the time (depending on the timing of the truncation), nobody<br /> notices the problem because folio_unlock() gets called three times,<br /> which flips `PG_locked` back off:<br /> <br /> 1. vfs_read, nfs_read_folio, ... nfs_read_add_folio,<br /> nfs_return_empty_folio<br /> 2. vfs_read, nfs_read_folio, ... netfs_read_collection,<br /> netfs_unlock_abandoned_read_pages<br /> 3. vfs_read, ... nfs_do_read_folio, nfs_read_add_folio,<br /> nfs_return_empty_folio<br /> <br /> The problem is that nfs_read_add_folio() is not supposed to unlock the<br /> folio if fscache is enabled, and a nfs_netfs_folio_unlock() check is<br /> missing in nfs_return_empty_folio().<br /> <br /> Rarely this leads to a warning in netfs_read_collection():<br /> <br /> ------------[ cut here ]------------<br /> R=0000031c: folio 10 is not locked<br /> WARNING: CPU: 0 PID: 29 at fs/netfs/read_collect.c:133 netfs_read_collection+0x7c0/0xf00<br /> [...]<br /> Workqueue: events_unbound netfs_read_collection_worker<br /> RIP: 0010:netfs_read_collection+0x7c0/0xf00<br /> [...]<br /> Call Trace:<br /> <br /> netfs_read_collection_worker+0x67/0x80<br /> process_one_work+0x12e/0x2c0<br /> worker_thread+0x295/0x3a0<br /> <br /> Most of the time, however, processes just get stuck forever in<br /> folio_wait_bit_common(), waiting for `PG_locked` to disappear, which<br /> never happens because nobody is really holding the folio lock.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> powerpc/bpf: fix JIT code size calculation of bpf trampoline<br /> <br /> arch_bpf_trampoline_size() provides JIT size of the BPF trampoline<br /> before the buffer for JIT&amp;#39;ing it is allocated. The total number of<br /> instructions emitted for BPF trampoline JIT code depends on where<br /> the final image is located. So, the size arrived at with the dummy<br /> pass in arch_bpf_trampoline_size() can vary from the actual size<br /> needed in arch_prepare_bpf_trampoline(). When the instructions<br /> accounted in arch_bpf_trampoline_size() is less than the number of<br /> instructions emitted during the actual JIT compile of the trampoline,<br /> the below warning is produced:<br /> <br /> WARNING: CPU: 8 PID: 204190 at arch/powerpc/net/bpf_jit_comp.c:981 __arch_prepare_bpf_trampoline.isra.0+0xd2c/0xdcc<br /> <br /> which is:<br /> <br /> /* Make sure the trampoline generation logic doesn&amp;#39;t overflow */<br /> if (image &amp;&amp; WARN_ON_ONCE(&amp;image[ctx-&gt;idx] &gt;<br /> (u32 *)rw_image_end - BPF_INSN_SAFETY)) {<br /> <br /> So, during the dummy pass, instead of providing some arbitrary image<br /> location, account for maximum possible instructions if and when there<br /> is a dependency with image location for JIT&amp;#39;ing.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> firmware: cs_dsp: Fix OOB memory read access in KUnit test<br /> <br /> KASAN reported out of bounds access - cs_dsp_mock_bin_add_name_or_info(),<br /> because the source string length was rounded up to the allocation size.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> eth: fbnic: avoid double free when failing to DMA-map FW msg<br /> <br /> The semantics are that caller of fbnic_mbx_map_msg() retains<br /> the ownership of the message on error. All existing callers<br /> dutifully free the page.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> jffs2: check jffs2_prealloc_raw_node_refs() result in few other places<br /> <br /> Fuzzing hit another invalid pointer dereference due to the lack of<br /> checking whether jffs2_prealloc_raw_node_refs() completed successfully.<br /> Subsequent logic implies that the node refs have been allocated.<br /> <br /> Handle that. The code is ready for propagating the error upwards.<br /> <br /> KASAN: null-ptr-deref in range [0x0000000000000008-0x000000000000000f]<br /> CPU: 1 PID: 5835 Comm: syz-executor145 Not tainted 5.10.234-syzkaller #0<br /> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.12.0-1 04/01/2014<br /> RIP: 0010:jffs2_link_node_ref+0xac/0x690 fs/jffs2/nodelist.c:600<br /> Call Trace:<br /> jffs2_mark_erased_block fs/jffs2/erase.c:460 [inline]<br /> jffs2_erase_pending_blocks+0x688/0x1860 fs/jffs2/erase.c:118<br /> jffs2_garbage_collect_pass+0x638/0x1a00 fs/jffs2/gc.c:253<br /> jffs2_reserve_space+0x3f4/0xad0 fs/jffs2/nodemgmt.c:167<br /> jffs2_write_inode_range+0x246/0xb50 fs/jffs2/write.c:362<br /> jffs2_write_end+0x712/0x1110 fs/jffs2/file.c:302<br /> generic_perform_write+0x2c2/0x500 mm/filemap.c:3347<br /> __generic_file_write_iter+0x252/0x610 mm/filemap.c:3465<br /> generic_file_write_iter+0xdb/0x230 mm/filemap.c:3497<br /> call_write_iter include/linux/fs.h:2039 [inline]<br /> do_iter_readv_writev+0x46d/0x750 fs/read_write.c:740<br /> do_iter_write+0x18c/0x710 fs/read_write.c:866<br /> vfs_writev+0x1db/0x6a0 fs/read_write.c:939<br /> do_pwritev fs/read_write.c:1036 [inline]<br /> __do_sys_pwritev fs/read_write.c:1083 [inline]<br /> __se_sys_pwritev fs/read_write.c:1078 [inline]<br /> __x64_sys_pwritev+0x235/0x310 fs/read_write.c:1078<br /> do_syscall_64+0x30/0x40 arch/x86/entry/common.c:46<br /> entry_SYSCALL_64_after_hwframe+0x67/0xd1<br /> <br /> Found by Linux Verification Center (linuxtesting.org) with Syzkaller.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> firmware: cs_dsp: Fix OOB memory read access in KUnit test (wmfw info)<br /> <br /> KASAN reported out of bounds access - cs_dsp_mock_wmfw_add_info(),<br /> because the source string length was rounded up to the allocation size.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> firmware: cs_dsp: Fix OOB memory read access in KUnit test (ctl cache)<br /> <br /> KASAN reported out of bounds access - cs_dsp_ctl_cache_init_multiple_offsets().<br /> The code uses mock_coeff_template.length_bytes (4 bytes) for register value<br /> allocations. But later, this length is set to 8 bytes which causes<br /> test code failures.<br /> <br /> As fix, just remove the lenght override, keeping the original value 4<br /> for all operations.