Vulnerabilidades

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> wifi: ath9k: don&amp;#39;t allow to overwrite ENDPOINT0 attributes<br /> <br /> A bad USB device is able to construct a service connection response<br /> message with target endpoint being ENDPOINT0 which is reserved for<br /> HTC_CTRL_RSVD_SVC and should not be modified to be used for any other<br /> services.<br /> <br /> Reject such service connection responses.<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 /> skbuff: Fix a race between coalescing and releasing SKBs<br /> <br /> Commit 1effe8ca4e34 ("skbuff: fix coalescing for page_pool fragment<br /> recycling") allowed coalescing to proceed with non page pool page and page<br /> pool page when @from is cloned, i.e.<br /> <br /> to-&gt;pp_recycle --&gt; false<br /> from-&gt;pp_recycle --&gt; true<br /> skb_cloned(from) --&gt; true<br /> <br /> However, it actually requires skb_cloned(@from) to hold true until<br /> coalescing finishes in this situation. If the other cloned SKB is<br /> released while the merging is in process, from_shinfo-&gt;nr_frags will be<br /> set to 0 toward the end of the function, causing the increment of frag<br /> page _refcount to be unexpectedly skipped resulting in inconsistent<br /> reference counts. Later when SKB(@to) is released, it frees the page<br /> directly even though the page pool page is still in use, leading to<br /> use-after-free or double-free errors. So it should be prohibited.<br /> <br /> The double-free error message below prompted us to investigate:<br /> BUG: Bad page state in process swapper/1 pfn:0e0d1<br /> page:00000000c6548b28 refcount:-1 mapcount:0 mapping:0000000000000000<br /> index:0x2 pfn:0xe0d1<br /> flags: 0xfffffc0000000(node=0|zone=1|lastcpupid=0x1fffff)<br /> raw: 000fffffc0000000 0000000000000000 ffffffff00000101 0000000000000000<br /> raw: 0000000000000002 0000000000000000 ffffffffffffffff 0000000000000000<br /> page dumped because: nonzero _refcount<br /> <br /> CPU: 1 PID: 0 Comm: swapper/1 Tainted: G E 6.2.0+<br /> Call Trace:<br /> <br /> dump_stack_lvl+0x32/0x50<br /> bad_page+0x69/0xf0<br /> free_pcp_prepare+0x260/0x2f0<br /> free_unref_page+0x20/0x1c0<br /> skb_release_data+0x10b/0x1a0<br /> napi_consume_skb+0x56/0x150<br /> net_rx_action+0xf0/0x350<br /> ? __napi_schedule+0x79/0x90<br /> __do_softirq+0xc8/0x2b1<br /> __irq_exit_rcu+0xb9/0xf0<br /> common_interrupt+0x82/0xa0<br /> <br /> <br /> asm_common_interrupt+0x22/0x40<br /> RIP: 0010:default_idle+0xb/0x20

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> btrfs: fix use-after-free of new block group that became unused<br /> <br /> If a task creates a new block group and that block group becomes unused<br /> before we finish its creation, at btrfs_create_pending_block_groups(),<br /> then when btrfs_mark_bg_unused() is called against the block group, we<br /> assume that the block group is currently in the list of block groups to<br /> reclaim, and we move it out of the list of new block groups and into the<br /> list of unused block groups. This has two consequences:<br /> <br /> 1) We move it out of the list of new block groups associated to the<br /> current transaction. So the block group creation is not finished and<br /> if we attempt to delete the bg because it&amp;#39;s unused, we will not find<br /> the block group item in the extent tree (or the new block group tree),<br /> its device extent items in the device tree etc, resulting in the<br /> deletion to fail due to the missing items;<br /> <br /> 2) We don&amp;#39;t increment the reference count on the block group when we<br /> move it to the list of unused block groups, because we assumed the<br /> block group was on the list of block groups to reclaim, and in that<br /> case it already has the correct reference count. However the block<br /> group was on the list of new block groups, in which case no extra<br /> reference was taken because it&amp;#39;s local to the current task. This<br /> later results in doing an extra reference count decrement when<br /> removing the block group from the unused list, eventually leading the<br /> reference count to 0.<br /> <br /> This second case was caught when running generic/297 from fstests, which<br /> produced the following assertion failure and stack trace:<br /> <br /> [589.559] assertion failed: refcount_read(&amp;block_group-&gt;refs) == 1, in fs/btrfs/block-group.c:4299<br /> [589.559] ------------[ cut here ]------------<br /> [589.559] kernel BUG at fs/btrfs/block-group.c:4299!<br /> [589.560] invalid opcode: 0000 [#1] PREEMPT SMP PTI<br /> [589.560] CPU: 8 PID: 2819134 Comm: umount Tainted: G W 6.4.0-rc6-btrfs-next-134+ #1<br /> [589.560] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.2-0-gea1b7a073390-prebuilt.qemu.org 04/01/2014<br /> [589.560] RIP: 0010:btrfs_free_block_groups+0x449/0x4a0 [btrfs]<br /> [589.561] Code: 68 62 da c0 (...)<br /> [589.561] RSP: 0018:ffffa55a8c3b3d98 EFLAGS: 00010246<br /> [589.561] RAX: 0000000000000058 RBX: ffff8f030d7f2000 RCX: 0000000000000000<br /> [589.562] RDX: 0000000000000000 RSI: ffffffff953f0878 RDI: 00000000ffffffff<br /> [589.562] RBP: ffff8f030d7f2088 R08: 0000000000000000 R09: ffffa55a8c3b3c50<br /> [589.562] R10: 0000000000000001 R11: 0000000000000001 R12: ffff8f05850b4c00<br /> [589.562] R13: ffff8f030d7f2090 R14: ffff8f05850b4cd8 R15: dead000000000100<br /> [589.563] FS: 00007f497fd2e840(0000) GS:ffff8f09dfc00000(0000) knlGS:0000000000000000<br /> [589.563] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> [589.563] CR2: 00007f497ff8ec10 CR3: 0000000271472006 CR4: 0000000000370ee0<br /> [589.563] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000<br /> [589.564] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400<br /> [589.564] Call Trace:<br /> [589.564] <br /> [589.565] ? __die_body+0x1b/0x60<br /> [589.565] ? die+0x39/0x60<br /> [589.565] ? do_trap+0xeb/0x110<br /> [589.565] ? btrfs_free_block_groups+0x449/0x4a0 [btrfs]<br /> [589.566] ? do_error_trap+0x6a/0x90<br /> [589.566] ? btrfs_free_block_groups+0x449/0x4a0 [btrfs]<br /> [589.566] ? exc_invalid_op+0x4e/0x70<br /> [589.566] ? btrfs_free_block_groups+0x449/0x4a0 [btrfs]<br /> [589.567] ? asm_exc_invalid_op+0x16/0x20<br /> [589.567] ? btrfs_free_block_groups+0x449/0x4a0 [btrfs]<br /> [589.567] ? btrfs_free_block_groups+0x449/0x4a0 [btrfs]<br /> [589.567] close_ctree+0x35d/0x560 [btrfs]<br /> [589.568] ? fsnotify_sb_delete+0x13e/0x1d0<br /> [589.568] ? dispose_list+0x3a/0x50<br /> [589.568] ? evict_inodes+0x151/0x1a0<br /> [589.568] generic_shutdown_super+0x73/0x1a0<br /> [589.569] kill_anon_super+0x14/0x30<br /> [589.569] btrfs_kill_super+0x12/0x20 [btrfs]<br /> [589.569] deactivate_locked<br /> ---truncated---

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> fsverity: reject FS_IOC_ENABLE_VERITY on mode 3 fds<br /> <br /> Commit 56124d6c87fd ("fsverity: support enabling with tree block size f_mode &amp; FMODE_READ))&amp;#39; in __kernel_read() became<br /> reachable by fuzz tests. This happens if FS_IOC_ENABLE_VERITY is called<br /> on a fd opened with access mode 3, which means "ioctl access only".<br /> <br /> Arguably, FS_IOC_ENABLE_VERITY should work on ioctl-only fds. But<br /> ioctl-only fds are a weird Linux extension that is rarely used and that<br /> few people even know about. (The documentation for FS_IOC_ENABLE_VERITY<br /> even specifically says it requires O_RDONLY.) It&amp;#39;s probably not<br /> worthwhile to make the ioctl internally open a new fd just to handle<br /> this case. Thus, just reject the ioctl on such fds for now.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> tty: pcn_uart: fix memory leak with using debugfs_lookup()<br /> <br /> When calling debugfs_lookup() the result must have dput() called on it,<br /> otherwise the memory will leak over time. To make things simpler, just<br /> call debugfs_lookup_and_remove() instead which handles all of the logic<br /> at once.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> scsi: core: Fix possible memory leak if device_add() fails<br /> <br /> If device_add() returns error, the name allocated by dev_set_name() needs<br /> be freed. As the comment of device_add() says, put_device() should be used<br /> to decrease the reference count in the error path. So fix this by calling<br /> put_device(), then the name can be freed in kobject_cleanp().

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> PCI: hv: Fix a crash in hv_pci_restore_msi_msg() during hibernation<br /> <br /> When a Linux VM with an assigned PCI device runs on Hyper-V, if the PCI<br /> device driver is not loaded yet (i.e. MSI-X/MSI is not enabled on the<br /> device yet), doing a VM hibernation triggers a panic in<br /> hv_pci_restore_msi_msg() -&gt; msi_lock_descs(&amp;pdev-&gt;dev), because<br /> pdev-&gt;dev.msi.data is still NULL.<br /> <br /> Avoid the panic by checking if MSI-X/MSI is enabled.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> serial: 8250: Reinit port-&gt;pm on port specific driver unbind<br /> <br /> When we unbind a serial port hardware specific 8250 driver, the generic<br /> serial8250 driver takes over the port. After that we see an oops about 10<br /> seconds later. This can produce the following at least on some TI SoCs:<br /> <br /> Unhandled fault: imprecise external abort (0x1406)<br /> Internal error: : 1406 [#1] SMP ARM<br /> <br /> Turns out that we may still have the serial port hardware specific driver<br /> port-&gt;pm in use, and serial8250_pm() tries to call it after the port<br /> specific driver is gone:<br /> <br /> serial8250_pm [8250_base] from uart_change_pm+0x54/0x8c [serial_base]<br /> uart_change_pm [serial_base] from uart_hangup+0x154/0x198 [serial_base]<br /> uart_hangup [serial_base] from __tty_hangup.part.0+0x328/0x37c<br /> __tty_hangup.part.0 from disassociate_ctty+0x154/0x20c<br /> disassociate_ctty from do_exit+0x744/0xaac<br /> do_exit from do_group_exit+0x40/0x8c<br /> do_group_exit from __wake_up_parent+0x0/0x1c<br /> <br /> Let&amp;#39;s fix the issue by calling serial8250_set_defaults() in<br /> serial8250_unregister_port(). This will set the port back to using<br /> the serial8250 default functions, and sets the port-&gt;pm to point to<br /> serial8250_pm.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> media: hi846: fix usage of pm_runtime_get_if_in_use()<br /> <br /> pm_runtime_get_if_in_use() does not only return nonzero values when<br /> the device is in use, it can return a negative errno too.<br /> <br /> And especially during resuming from system suspend, when runtime pm<br /> is not yet up again, -EAGAIN is being returned, so the subsequent<br /> pm_runtime_put() call results in a refcount underflow.<br /> <br /> Fix system-resume by handling -EAGAIN of pm_runtime_get_if_in_use().

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mm: fix zswap writeback race condition<br /> <br /> The zswap writeback mechanism can cause a race condition resulting in<br /> memory corruption, where a swapped out page gets swapped in with data that<br /> was written to a different page.<br /> <br /> The race unfolds like this:<br /> 1. a page with data A and swap offset X is stored in zswap<br /> 2. page A is removed off the LRU by zpool driver for writeback in<br /> zswap-shrink work, data for A is mapped by zpool driver<br /> 3. user space program faults and invalidates page entry A, offset X is<br /> considered free<br /> 4. kswapd stores page B at offset X in zswap (zswap could also be<br /> full, if so, page B would then be IOed to X, then skip step 5.)<br /> 5. entry A is replaced by B in tree-&gt;rbroot, this doesn&amp;#39;t affect the<br /> local reference held by zswap-shrink work<br /> 6. zswap-shrink work writes back A at X, and frees zswap entry A<br /> 7. swapin of slot X brings A in memory instead of B<br /> <br /> The fix:<br /> Once the swap page cache has been allocated (case ZSWAP_SWAPCACHE_NEW),<br /> zswap-shrink work just checks that the local zswap_entry reference is<br /> still the same as the one in the tree. If it&amp;#39;s not the same it means that<br /> it&amp;#39;s either been invalidated or replaced, in both cases the writeback is<br /> aborted because the local entry contains stale data.<br /> <br /> Reproducer:<br /> I originally found this by running `stress` overnight to validate my work<br /> on the zswap writeback mechanism, it manifested after hours on my test<br /> machine. The key to make it happen is having zswap writebacks, so<br /> whatever setup pumps /sys/kernel/debug/zswap/written_back_pages should do<br /> the trick.<br /> <br /> In order to reproduce this faster on a vm, I setup a system with ~100M of<br /> available memory and a 500M swap file, then running `stress --vm 1<br /> --vm-bytes 300000000 --vm-stride 4000` makes it happen in matter of tens<br /> of minutes. One can speed things up even more by swinging<br /> /sys/module/zswap/parameters/max_pool_percent up and down between, say, 20<br /> and 1; this makes it reproduce in tens of seconds. It&amp;#39;s crucial to set<br /> `--vm-stride` to something other than 4096 otherwise `stress` won&amp;#39;t<br /> realize that memory has been corrupted because all pages would have the<br /> same data.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> netfilter: ipset: add the missing IP_SET_HASH_WITH_NET0 macro for ip_set_hash_netportnet.c<br /> <br /> The missing IP_SET_HASH_WITH_NET0 macro in ip_set_hash_netportnet can<br /> lead to the use of wrong `CIDR_POS(c)` for calculating array offsets,<br /> which can lead to integer underflow. As a result, it leads to slab<br /> out-of-bound access.<br /> This patch adds back the IP_SET_HASH_WITH_NET0 macro to<br /> ip_set_hash_netportnet to address the issue.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> irqchip/ti-sci: Fix refcount leak in ti_sci_intr_irq_domain_probe<br /> <br /> of_irq_find_parent() returns a node pointer with refcount incremented,<br /> We should use of_node_put() on it when not needed anymore.<br /> Add missing of_node_put() to avoid refcount leak.