Vulnerabilidades

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mlx5: fix skb leak while fifo resync and push<br /> <br /> During ptp resync operation SKBs were poped from the fifo but were never<br /> freed neither by napi_consume nor by dev_kfree_skb_any. Add call to<br /> napi_consume_skb to properly free SKBs.<br /> <br /> Another leak was happening because mlx5e_skb_fifo_has_room() had an error<br /> in the check. Comparing free running counters works well unless C promotes<br /> the types to something wider than the counter. In this case counters are<br /> u16 but the result of the substraction is promouted to int and it causes<br /> wrong result (negative value) of the check when producer have already<br /> overlapped but consumer haven&amp;#39;t yet. Explicit cast to u16 fixes the issue.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> iommufd: Check for uptr overflow<br /> <br /> syzkaller found that setting up a map with a user VA that wraps past zero<br /> can trigger WARN_ONs, particularly from pin_user_pages weirdly returning 0<br /> due to invalid arguments.<br /> <br /> Prevent creating a pages with a uptr and size that would math overflow.<br /> <br /> WARNING: CPU: 0 PID: 518 at drivers/iommu/iommufd/pages.c:793 pfn_reader_user_pin+0x2e6/0x390<br /> Modules linked in:<br /> CPU: 0 PID: 518 Comm: repro Not tainted 6.3.0-rc2-eeac8ede1755+ #1<br /> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.0-0-gd239552ce722-prebuilt.qemu.org 04/01/2014<br /> RIP: 0010:pfn_reader_user_pin+0x2e6/0x390<br /> Code: b1 11 e9 25 fe ff ff e8 28 e4 0f ff 31 ff 48 89 de e8 2e e6 0f ff 48 85 db 74 0a e8 14 e4 0f ff e9 4d ff ff ff e8 0a e4 0f ff 0b bb f2 ff ff ff e9 3c ff ff ff e8 f9 e3 0f ff ba 01 00 00 00<br /> RSP: 0018:ffffc90000f9fa30 EFLAGS: 00010246<br /> RAX: 0000000000000000 RBX: 0000000000000000 RCX: ffffffff821e2b72<br /> RDX: 0000000000000000 RSI: ffff888014184680 RDI: 0000000000000002<br /> RBP: ffffc90000f9fa78 R08: 00000000000000ff R09: 0000000079de6f4e<br /> R10: ffffc90000f9f790 R11: ffff888014185418 R12: ffffc90000f9fc60<br /> R13: 0000000000000002 R14: ffff888007879800 R15: 0000000000000000<br /> FS: 00007f4227555740(0000) GS:ffff88807dc00000(0000) knlGS:0000000000000000<br /> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> CR2: 0000000020000043 CR3: 000000000e748005 CR4: 0000000000770ef0<br /> PKRU: 55555554<br /> Call Trace:<br /> <br /> pfn_reader_next+0x14a/0x7b0<br /> ? interval_tree_double_span_iter_update+0x11a/0x140<br /> pfn_reader_first+0x140/0x1b0<br /> iopt_pages_rw_slow+0x71/0x280<br /> ? __this_cpu_preempt_check+0x20/0x30<br /> iopt_pages_rw_access+0x2b2/0x5b0<br /> iommufd_access_rw+0x19f/0x2f0<br /> iommufd_test+0xd11/0x16f0<br /> ? write_comp_data+0x2f/0x90<br /> iommufd_fops_ioctl+0x206/0x330<br /> __x64_sys_ioctl+0x10e/0x160<br /> ? __pfx_iommufd_fops_ioctl+0x10/0x10<br /> do_syscall_64+0x3b/0x90<br /> entry_SYSCALL_64_after_hwframe+0x72/0xdc

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: ethernet: mtk_eth_soc: fix possible NULL pointer dereference in mtk_hwlro_get_fdir_all()<br /> <br /> rule_locs is allocated in ethtool_get_rxnfc and the size is determined by<br /> rule_cnt from user space. So rule_cnt needs to be check before using<br /> rule_locs to avoid NULL pointer dereference.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> MIPS: KVM: Fix NULL pointer dereference<br /> <br /> After commit 45c7e8af4a5e3f0bea4ac209 ("MIPS: Remove KVM_TE support") we<br /> get a NULL pointer dereference when creating a KVM guest:<br /> <br /> [ 146.243409] Starting KVM with MIPS VZ extensions<br /> [ 149.849151] CPU 3 Unable to handle kernel paging request at virtual address 0000000000000300, epc == ffffffffc06356ec, ra == ffffffffc063568c<br /> [ 149.849177] Oops[#1]:<br /> [ 149.849182] CPU: 3 PID: 2265 Comm: qemu-system-mip Not tainted 6.4.0-rc3+ #1671<br /> [ 149.849188] Hardware name: THTF CX TL630 Series/THTF-LS3A4000-7A1000-ML4A, BIOS KL4.1F.TF.D.166.201225.R 12/25/2020<br /> [ 149.849192] $ 0 : 0000000000000000 000000007400cce0 0000000000400004 ffffffff8119c740<br /> [ 149.849209] $ 4 : 000000007400cce1 000000007400cce1 0000000000000000 0000000000000000<br /> [ 149.849221] $ 8 : 000000240058bb36 ffffffff81421ac0 0000000000000000 0000000000400dc0<br /> [ 149.849233] $12 : 9800000102a07cc8 ffffffff80e40e38 0000000000000001 0000000000400dc0<br /> [ 149.849245] $16 : 0000000000000000 9800000106cd0000 9800000106cd0000 9800000100cce000<br /> [ 149.849257] $20 : ffffffffc0632b28 ffffffffc05b31b0 9800000100ccca00 0000000000400000<br /> [ 149.849269] $24 : 9800000106cd09ce ffffffff802f69d0<br /> [ 149.849281] $28 : 9800000102a04000 9800000102a07cd0 98000001106a8000 ffffffffc063568c<br /> [ 149.849293] Hi : 00000335b2111e66<br /> [ 149.849295] Lo : 6668d90061ae0ae9<br /> [ 149.849298] epc : ffffffffc06356ec kvm_vz_vcpu_setup+0xc4/0x328 [kvm]<br /> [ 149.849324] ra : ffffffffc063568c kvm_vz_vcpu_setup+0x64/0x328 [kvm]<br /> [ 149.849336] Status: 7400cce3 KX SX UX KERNEL EXL IE<br /> [ 149.849351] Cause : 1000000c (ExcCode 03)<br /> [ 149.849354] BadVA : 0000000000000300<br /> [ 149.849357] PrId : 0014c004 (ICT Loongson-3)<br /> [ 149.849360] Modules linked in: kvm nfnetlink_queue nfnetlink_log nfnetlink fuse sha256_generic libsha256 cfg80211 rfkill binfmt_misc vfat fat snd_hda_codec_hdmi input_leds led_class snd_hda_intel snd_intel_dspcfg snd_hda_codec snd_hda_core snd_pcm snd_timer snd serio_raw xhci_pci radeon drm_suballoc_helper drm_display_helper xhci_hcd ip_tables x_tables<br /> [ 149.849432] Process qemu-system-mip (pid: 2265, threadinfo=00000000ae2982d2, task=0000000038e09ad4, tls=000000ffeba16030)<br /> [ 149.849439] Stack : 9800000000000003 9800000100ccca00 9800000100ccc000 ffffffffc062cef4<br /> [ 149.849453] 9800000102a07d18 c89b63a7ab338e00 0000000000000000 ffffffff811a0000<br /> [ 149.849465] 0000000000000000 9800000106cd0000 ffffffff80e59938 98000001106a8920<br /> [ 149.849476] ffffffff80e57f30 ffffffffc062854c ffffffff811a0000 9800000102bf4240<br /> [ 149.849488] ffffffffc05b0000 ffffffff80e3a798 000000ff78000000 000000ff78000010<br /> [ 149.849500] 0000000000000255 98000001021f7de0 98000001023f0078 ffffffff81434000<br /> [ 149.849511] 0000000000000000 0000000000000000 9800000102ae0000 980000025e92ae28<br /> [ 149.849523] 0000000000000000 c89b63a7ab338e00 0000000000000001 ffffffff8119dce0<br /> [ 149.849535] 000000ff78000010 ffffffff804f3d3c 9800000102a07eb0 0000000000000255<br /> [ 149.849546] 0000000000000000 ffffffff8049460c 000000ff78000010 0000000000000255<br /> [ 149.849558] ...<br /> [ 149.849565] Call Trace:<br /> [ 149.849567] [] kvm_vz_vcpu_setup+0xc4/0x328 [kvm]<br /> [ 149.849586] [] kvm_arch_vcpu_create+0x184/0x228 [kvm]<br /> [ 149.849605] [] kvm_vm_ioctl+0x64c/0xf28 [kvm]<br /> [ 149.849623] [] sys_ioctl+0xc8/0x118<br /> [ 149.849631] [] syscall_common+0x34/0x58<br /> <br /> The root cause is the deletion of kvm_mips_commpage_init() leaves vcpu<br /> -&gt;arch.cop0 NULL. So fix it by making cop0 from a pointer to an embedded<br /> object.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> block, bfq: Fix division by zero error on zero wsum<br /> <br /> When the weighted sum is zero the calculation of limit causes<br /> a division by zero error. Fix this by continuing to the next level.<br /> <br /> This was discovered by running as root:<br /> <br /> stress-ng --ioprio 0<br /> <br /> Fixes divison by error oops:<br /> <br /> [ 521.450556] divide error: 0000 [#1] SMP NOPTI<br /> [ 521.450766] CPU: 2 PID: 2684464 Comm: stress-ng-iopri Not tainted 6.2.1-1280.native #1<br /> [ 521.451117] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.1-0-g3208b098f51a-prebuilt.qemu.org 04/01/2014<br /> [ 521.451627] RIP: 0010:bfqq_request_over_limit+0x207/0x400<br /> [ 521.451875] Code: 01 48 8d 0c c8 74 0b 48 8b 82 98 00 00 00 48 8d 0c c8 8b 85 34 ff ff ff 48 89 ca 41 0f af 41 50 48 d1 ea 48 98 48 01 d0 31 d2 f7 f1 41 39 41 48 89 85 34 ff ff ff 0f 8c 7b 01 00 00 49 8b 44<br /> [ 521.452699] RSP: 0018:ffffb1af84eb3948 EFLAGS: 00010046<br /> [ 521.452938] RAX: 000000000000003c RBX: 0000000000000000 RCX: 0000000000000000<br /> [ 521.453262] RDX: 0000000000000000 RSI: 0000000000000000 RDI: ffffb1af84eb3978<br /> [ 521.453584] RBP: ffffb1af84eb3a30 R08: 0000000000000001 R09: ffff8f88ab8a4ba0<br /> [ 521.453905] R10: 0000000000000000 R11: 0000000000000001 R12: ffff8f88ab8a4b18<br /> [ 521.454224] R13: ffff8f8699093000 R14: 0000000000000001 R15: ffffb1af84eb3970<br /> [ 521.454549] FS: 00005640b6b0b580(0000) GS:ffff8f88b3880000(0000) knlGS:0000000000000000<br /> [ 521.454912] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> [ 521.455170] CR2: 00007ffcbcae4e38 CR3: 00000002e46de001 CR4: 0000000000770ee0<br /> [ 521.455491] PKRU: 55555554<br /> [ 521.455619] Call Trace:<br /> [ 521.455736] <br /> [ 521.455837] ? bfq_request_merge+0x3a/0xc0<br /> [ 521.456027] ? elv_merge+0x115/0x140<br /> [ 521.456191] bfq_limit_depth+0xc8/0x240<br /> [ 521.456366] __blk_mq_alloc_requests+0x21a/0x2c0<br /> [ 521.456577] blk_mq_submit_bio+0x23c/0x6c0<br /> [ 521.456766] __submit_bio+0xb8/0x140<br /> [ 521.457236] submit_bio_noacct_nocheck+0x212/0x300<br /> [ 521.457748] submit_bio_noacct+0x1a6/0x580<br /> [ 521.458220] submit_bio+0x43/0x80<br /> [ 521.458660] ext4_io_submit+0x23/0x80<br /> [ 521.459116] ext4_do_writepages+0x40a/0xd00<br /> [ 521.459596] ext4_writepages+0x65/0x100<br /> [ 521.460050] do_writepages+0xb7/0x1c0<br /> [ 521.460492] __filemap_fdatawrite_range+0xa6/0x100<br /> [ 521.460979] file_write_and_wait_range+0xbf/0x140<br /> [ 521.461452] ext4_sync_file+0x105/0x340<br /> [ 521.461882] __x64_sys_fsync+0x67/0x100<br /> [ 521.462305] ? syscall_exit_to_user_mode+0x2c/0x1c0<br /> [ 521.462768] do_syscall_64+0x3b/0xc0<br /> [ 521.463165] entry_SYSCALL_64_after_hwframe+0x5a/0xc4<br /> [ 521.463621] RIP: 0033:0x5640b6c56590<br /> [ 521.464006] Code: 00 f7 d8 64 89 01 48 83 c8 ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 80 3d 71 70 0e 00 00 74 17 b8 4a 00 00 00 0f 05 3d 00 f0 ff ff 77 48 c3 0f 1f 80 00 00 00 00 48 83 ec 18 89 7c

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> netfilter: ebtables: fix table blob use-after-free<br /> <br /> We are not allowed to return an error at this point.<br /> Looking at the code it looks like ret is always 0 at this<br /> point, but its not.<br /> <br /> t = find_table_lock(net, repl-&gt;name, &amp;ret, &amp;ebt_mutex);<br /> <br /> ... this can return a valid table, with ret != 0.<br /> <br /> This bug causes update of table-&gt;private with the new<br /> blob, but then frees the blob right away in the caller.<br /> <br /> Syzbot report:<br /> <br /> BUG: KASAN: vmalloc-out-of-bounds in __ebt_unregister_table+0xc00/0xcd0 net/bridge/netfilter/ebtables.c:1168<br /> Read of size 4 at addr ffffc90005425000 by task kworker/u4:4/74<br /> Workqueue: netns cleanup_net<br /> Call Trace:<br /> kasan_report+0xbf/0x1f0 mm/kasan/report.c:517<br /> __ebt_unregister_table+0xc00/0xcd0 net/bridge/netfilter/ebtables.c:1168<br /> ebt_unregister_table+0x35/0x40 net/bridge/netfilter/ebtables.c:1372<br /> ops_exit_list+0xb0/0x170 net/core/net_namespace.c:169<br /> cleanup_net+0x4ee/0xb10 net/core/net_namespace.c:613<br /> ...<br /> <br /> ip(6)tables appears to be ok (ret should be 0 at this point) but make<br /> this more obvious.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ACPI: EC: Fix oops when removing custom query handlers<br /> <br /> When removing custom query handlers, the handler might still<br /> be used inside the EC query workqueue, causing a kernel oops<br /> if the module holding the callback function was already unloaded.<br /> <br /> Fix this by flushing the EC query workqueue when removing<br /> custom query handlers.<br /> <br /> Tested on a Acer Travelmate 4002WLMi

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> blk-mq: fix tags leak when shrink nr_hw_queues<br /> <br /> Although we don&amp;#39;t need to realloc set-&gt;tags[] when shrink nr_hw_queues,<br /> we need to free them. Or these tags will be leaked.<br /> <br /> How to reproduce:<br /> 1. mount -t configfs configfs /mnt<br /> 2. modprobe null_blk nr_devices=0 submit_queues=8<br /> 3. mkdir /mnt/nullb/nullb0<br /> 4. echo 1 &gt; /mnt/nullb/nullb0/power<br /> 5. echo 4 &gt; /mnt/nullb/nullb0/submit_queues<br /> 6. rmdir /mnt/nullb/nullb0<br /> <br /> In step 4, will alloc 9 tags (8 submit queues and 1 poll queue), then<br /> in step 5, new_nr_hw_queues = 5 (4 submit queues and 1 poll queue).<br /> At last in step 6, only these 5 tags are freed, the other 4 tags leaked.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> regulator: raa215300: Fix resource leak in case of error<br /> <br /> The clk_register_clkdev() allocates memory by calling vclkdev_alloc() and<br /> this memory is not freed in the error path. Similarly, resources allocated<br /> by clk_register_fixed_rate() are not freed in the error path.<br /> <br /> Fix these issues by using devm_clk_hw_register_fixed_rate() and<br /> devm_clk_hw_register_clkdev().<br /> <br /> After this, the static variable clk is not needed. Replace it with <br /> local variable hw in probe() and drop calling clk_unregister_fixed_rate()<br /> from raa215300_rtc_unregister_device().

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> wifi: ath11k: fix registration of 6Ghz-only phy without the full channel range<br /> <br /> Because of what seems to be a typo, a 6Ghz-only phy for which the BDF<br /> does not allow the 7115Mhz channel will fail to register:<br /> <br /> WARNING: CPU: 2 PID: 106 at net/wireless/core.c:907 wiphy_register+0x914/0x954<br /> Modules linked in: ath11k_pci sbsa_gwdt<br /> CPU: 2 PID: 106 Comm: kworker/u8:5 Not tainted 6.3.0-rc7-next-20230418-00549-g1e096a17625a-dirty #9<br /> Hardware name: Freebox V7R Board (DT)<br /> Workqueue: ath11k_qmi_driver_event ath11k_qmi_driver_event_work<br /> pstate: 60000005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)<br /> pc : wiphy_register+0x914/0x954<br /> lr : ieee80211_register_hw+0x67c/0xc10<br /> sp : ffffff800b123aa0<br /> x29: ffffff800b123aa0 x28: 0000000000000000 x27: 0000000000000000<br /> x26: 0000000000000000 x25: 0000000000000006 x24: ffffffc008d51418<br /> x23: ffffffc008cb0838 x22: ffffff80176c2460 x21: 0000000000000168<br /> x20: ffffff80176c0000 x19: ffffff80176c03e0 x18: 0000000000000014<br /> x17: 00000000cbef338c x16: 00000000d2a26f21 x15: 00000000ad6bb85f<br /> x14: 0000000000000020 x13: 0000000000000020 x12: 00000000ffffffbd<br /> x11: 0000000000000208 x10: 00000000fffffdf7 x9 : ffffffc009394718<br /> x8 : ffffff80176c0528 x7 : 000000007fffffff x6 : 0000000000000006<br /> x5 : 0000000000000005 x4 : ffffff800b304284 x3 : ffffff800b304284<br /> x2 : ffffff800b304d98 x1 : 0000000000000000 x0 : 0000000000000000<br /> Call trace:<br /> wiphy_register+0x914/0x954<br /> ieee80211_register_hw+0x67c/0xc10<br /> ath11k_mac_register+0x7c4/0xe10<br /> ath11k_core_qmi_firmware_ready+0x1f4/0x570<br /> ath11k_qmi_driver_event_work+0x198/0x590<br /> process_one_work+0x1b8/0x328<br /> worker_thread+0x6c/0x414<br /> kthread+0x100/0x104<br /> ret_from_fork+0x10/0x20<br /> ---[ end trace 0000000000000000 ]---<br /> ath11k_pci 0002:01:00.0: ieee80211 registration failed: -22<br /> ath11k_pci 0002:01:00.0: failed register the radio with mac80211: -22<br /> ath11k_pci 0002:01:00.0: failed to create pdev core: -22

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> amba: bus: fix refcount leak<br /> <br /> commit 5de1540b7bc4 ("drivers/amba: create devices from device tree")<br /> increases the refcount of of_node, but not releases it in<br /> amba_device_release, so there is refcount leak. By using of_node_put<br /> to avoid refcount leak.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: libwx: fix memory leak in wx_setup_rx_resources<br /> <br /> When wx_alloc_page_pool() failed in wx_setup_rx_resources(), it doesn&amp;#39;t<br /> release DMA buffer. Add dma_free_coherent() in the error path to release<br /> the DMA buffer.