Vulnerabilidades

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:<br /> <br /> iommufd: Comprobar desbordamiento de uptr<br /> <br /> syzkaller encontró que configurar un mapa con una VA de usuario que se envuelve más allá de cero puede activar WARN_ONs, particularmente de pin_user_pages devolviendo 0 de forma extraña debido a argumentos inválidos.<br /> <br /> Evitar la creación de páginas con un uptr y un tamaño que causarían un desbordamiento matemático.<br /> <br /> ADVERTENCIA: CPU: 0 PID: 518 en drivers/iommu/iommufd/pages.c:793 pfn_reader_user_pin+0x2e6/0x390<br /> Módulos enlazados:<br /> CPU: 0 PID: 518 Comm: repro No contaminado 6.3.0-rc2-eeac8ede1755+ #1<br /> Nombre del hardware: 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 &amp;lt;0f&amp;gt; 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 /> Rastreo de llamadas:<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

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:<br /> <br /> net: ethernet: mtk_eth_soc: corrección de posible desreferencia de puntero NULL en mtk_hwlro_get_fdir_all()<br /> <br /> rule_locs se asigna en ethtool_get_rxnfc y el tamaño es determinado por rule_cnt del espacio de usuario. Por lo tanto, rule_cnt debe ser verificado antes de usar rule_locs para evitar la desreferencia de puntero NULL.

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:<br /> <br /> MIPS: KVM: Corregir desreferencia de puntero NULL<br /> <br /> Después del commit 45c7e8af4a5e3f0bea4ac209 (&amp;#39;MIPS: Remove KVM_TE support&amp;#39;), obtenemos una desreferencia de puntero NULL al crear un invitado KVM:<br /> <br /> [ 146.243409] Iniciando KVM con extensiones MIPS VZ<br /> [ 149.849151] CPU 3 No se puede manejar la solicitud de paginación del kernel en la dirección virtual 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] Nombre del hardware: 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] Módulos enlazados: 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] Proceso qemu-system-mip (pid: 2265, threadinfo=00000000ae2982d2, task=0000000038e09ad4, tls=000000ffeba16030)<br /> [ 149.849439] Pila : 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] Rastro de llamada:<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.84962

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:<br /> <br /> block, bfq: Corrige el error de división por cero en wsum cero<br /> <br /> Cuando la suma ponderada es cero, el cálculo del límite causa un error de división por cero. Corrige esto continuando al siguiente nivel.<br /> <br /> Esto fue descubierto al ejecutar como root:<br /> <br /> stress-ng --ioprio 0<br /> <br /> Corrige oops de división por error:<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 &amp;lt;48&amp;gt; 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 &amp;lt;48&amp;gt; 3d 00 f0 ff ff 77 48 c3 0f 1f 80 00 00 00 00 48 83 ec 18 89 7c

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:<br /> <br /> netfilter: ebtables: corregir uso después de liberación de blob de tabla<br /> <br /> No se nos permite devolver un error en este punto.<br /> Al mirar el código parece que ret siempre es 0 en este<br /> punto, pero no lo es.<br /> <br /> t = find_table_lock(net, repl-&amp;gt;name, &amp;amp;ret, &amp;amp;ebt_mutex);<br /> <br /> ... esto puede devolver una tabla válida, con ret != 0.<br /> <br /> Este error causa la actualización de table-&amp;gt;private con el nuevo<br /> blob, pero luego libera el blob inmediatamente en el llamador.<br /> <br /> Informe de Syzbot:<br /> <br /> ERROR: KASAN: vmalloc-fuera-de-límites en __ebt_unregister_table+0xc00/0xcd0 net/bridge/netfilter/ebtables.c:1168<br /> Lectura de tamaño 4 en la dirección ffffc90005425000 por la tarea kworker/u4:4/74<br /> Cola de trabajo: netns cleanup_net<br /> Traza de llamada:<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 parece estar bien (ret debería ser 0 en este punto) pero hacer<br /> esto más obvio.

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:<br /> <br /> ACPI: EC: Corrección de oops al eliminar controladores de consulta personalizados<br /> <br /> Al eliminar controladores de consulta personalizados, el controlador aún podría estar siendo utilizado dentro de la cola de trabajo de consulta de EC, causando un oops del kernel si el módulo que contenía la función de devolución de llamada ya había sido descargado.<br /> <br /> Solucione esto al vaciar la cola de trabajo de consulta de EC al eliminar controladores de consulta personalizados.<br /> <br /> Probado en un 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.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> m68k: Only force 030 bus error if PC not in exception table<br /> <br /> __get_kernel_nofault() does copy data in supervisor mode when<br /> forcing a task backtrace log through /proc/sysrq_trigger.<br /> This is expected cause a bus error exception on e.g. NULL<br /> pointer dereferencing when logging a kernel task has no<br /> workqueue associated. This bus error ought to be ignored.<br /> <br /> Our 030 bus error handler is ill equipped to deal with this:<br /> <br /> Whenever ssw indicates a kernel mode access on a data fault,<br /> we don&amp;#39;t even attempt to handle the fault and instead always<br /> send a SEGV signal (or panic). As a result, the check<br /> for exception handling at the fault PC (buried in<br /> send_sig_fault() which gets called from do_page_fault()<br /> eventually) is never used.<br /> <br /> In contrast, both 040 and 060 access error handlers do not<br /> care whether a fault happened on supervisor mode access,<br /> and will call do_page_fault() on those, ultimately honoring<br /> the exception table.<br /> <br /> Add a check in bus_error030 to call do_page_fault() in case<br /> we do have an entry for the fault PC in our exception table.<br /> <br /> I had attempted a fix for this earlier in 2019 that did rely<br /> on testing pagefault_disabled() (see link below) to achieve<br /> the same thing, but this patch should be more generic.<br /> <br /> Tested on 030 Atari Falcon.