Vulnerabilidades

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ksmbd: avoid out of bounds access in decode_preauth_ctxt()<br /> <br /> Confirm that the accessed pneg_ctxt-&gt;HashAlgorithms address sits within<br /> the SMB request boundary; deassemble_neg_contexts() only checks that the<br /> eight byte smb2_neg_context header + (client controlled) DataLength are<br /> within the packet boundary, which is insufficient.<br /> <br /> Checking for sizeof(struct smb2_preauth_neg_context) is overkill given<br /> that the type currently assumes SMB311_SALT_SIZE bytes of trailing Salt.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net/sched: taprio: Limit TCA_TAPRIO_ATTR_SCHED_CYCLE_TIME to INT_MAX.<br /> <br /> syzkaller found zero division error [0] in div_s64_rem() called from<br /> get_cycle_time_elapsed(), where sched-&gt;cycle_time is the divisor.<br /> <br /> We have tests in parse_taprio_schedule() so that cycle_time will never<br /> be 0, and actually cycle_time is not 0 in get_cycle_time_elapsed().<br /> <br /> The problem is that the types of divisor are different; cycle_time is<br /> s64, but the argument of div_s64_rem() is s32.<br /> <br /> syzkaller fed this input and 0x100000000 is cast to s32 to be 0.<br /> <br /> @TCA_TAPRIO_ATTR_SCHED_CYCLE_TIME={0xc, 0x8, 0x100000000}<br /> <br /> We use s64 for cycle_time to cast it to ktime_t, so let&amp;#39;s keep it and<br /> set max for cycle_time.<br /> <br /> While at it, we prevent overflow in setup_txtime() and add another<br /> test in parse_taprio_schedule() to check if cycle_time overflows.<br /> <br /> Also, we add a new tdc test case for this issue.<br /> <br /> [0]:<br /> divide error: 0000 [#1] PREEMPT SMP KASAN NOPTI<br /> CPU: 1 PID: 103 Comm: kworker/1:3 Not tainted 6.5.0-rc1-00330-g60cc1f7d0605 #3<br /> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.0-0-gd239552ce722-prebuilt.qemu.org 04/01/2014<br /> Workqueue: ipv6_addrconf addrconf_dad_work<br /> RIP: 0010:div_s64_rem include/linux/math64.h:42 [inline]<br /> RIP: 0010:get_cycle_time_elapsed net/sched/sch_taprio.c:223 [inline]<br /> RIP: 0010:find_entry_to_transmit+0x252/0x7e0 net/sched/sch_taprio.c:344<br /> Code: 3c 02 00 0f 85 5e 05 00 00 48 8b 4c 24 08 4d 8b bd 40 01 00 00 48 8b 7c 24 48 48 89 c8 4c 29 f8 48 63 f7 48 99 48 89 74 24 70 f7 fe 48 29 d1 48 8d 04 0f 49 89 cc 48 89 44 24 20 49 8d 85 10<br /> RSP: 0018:ffffc90000acf260 EFLAGS: 00010206<br /> RAX: 177450e0347560cf RBX: 0000000000000000 RCX: 177450e0347560cf<br /> RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000100000000<br /> RBP: 0000000000000056 R08: 0000000000000000 R09: ffffed10020a0934<br /> R10: ffff8880105049a7 R11: ffff88806cf3a520 R12: ffff888010504800<br /> R13: ffff88800c00d800 R14: ffff8880105049a0 R15: 0000000000000000<br /> FS: 0000000000000000(0000) GS:ffff88806cf00000(0000) knlGS:0000000000000000<br /> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> CR2: 00007f0edf84f0e8 CR3: 000000000d73c002 CR4: 0000000000770ee0<br /> PKRU: 55555554<br /> Call Trace:<br /> <br /> get_packet_txtime net/sched/sch_taprio.c:508 [inline]<br /> taprio_enqueue_one+0x900/0xff0 net/sched/sch_taprio.c:577<br /> taprio_enqueue+0x378/0xae0 net/sched/sch_taprio.c:658<br /> dev_qdisc_enqueue+0x46/0x170 net/core/dev.c:3732<br /> __dev_xmit_skb net/core/dev.c:3821 [inline]<br /> __dev_queue_xmit+0x1b2f/0x3000 net/core/dev.c:4169<br /> dev_queue_xmit include/linux/netdevice.h:3088 [inline]<br /> neigh_resolve_output net/core/neighbour.c:1552 [inline]<br /> neigh_resolve_output+0x4a7/0x780 net/core/neighbour.c:1532<br /> neigh_output include/net/neighbour.h:544 [inline]<br /> ip6_finish_output2+0x924/0x17d0 net/ipv6/ip6_output.c:135<br /> __ip6_finish_output+0x620/0xaa0 net/ipv6/ip6_output.c:196<br /> ip6_finish_output net/ipv6/ip6_output.c:207 [inline]<br /> NF_HOOK_COND include/linux/netfilter.h:292 [inline]<br /> ip6_output+0x206/0x410 net/ipv6/ip6_output.c:228<br /> dst_output include/net/dst.h:458 [inline]<br /> NF_HOOK.constprop.0+0xea/0x260 include/linux/netfilter.h:303<br /> ndisc_send_skb+0x872/0xe80 net/ipv6/ndisc.c:508<br /> ndisc_send_ns+0xb5/0x130 net/ipv6/ndisc.c:666<br /> addrconf_dad_work+0xc14/0x13f0 net/ipv6/addrconf.c:4175<br /> process_one_work+0x92c/0x13a0 kernel/workqueue.c:2597<br /> worker_thread+0x60f/0x1240 kernel/workqueue.c:2748<br /> kthread+0x2fe/0x3f0 kernel/kthread.c:389<br /> ret_from_fork+0x2c/0x50 arch/x86/entry/entry_64.S:308<br /> <br /> Modules linked in:

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> platform/x86: think-lmi: Fix memory leaks when parsing ThinkStation WMI strings<br /> <br /> My previous commit introduced a memory leak where the item allocated<br /> from tlmi_setting was not freed.<br /> This commit also renames it to avoid confusion with the similarly name<br /> variable in the same function.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> btrfs: set page extent mapped after read_folio in relocate_one_page<br /> <br /> One of the CI runs triggered the following panic<br /> <br /> assertion failed: PagePrivate(page) &amp;&amp; page-&gt;private, in fs/btrfs/subpage.c:229<br /> ------------[ cut here ]------------<br /> kernel BUG at fs/btrfs/subpage.c:229!<br /> Internal error: Oops - BUG: 00000000f2000800 [#1] SMP<br /> CPU: 0 PID: 923660 Comm: btrfs Not tainted 6.5.0-rc3+ #1<br /> pstate: 61400005 (nZCv daif +PAN -UAO -TCO +DIT -SSBS BTYPE=--)<br /> pc : btrfs_subpage_assert+0xbc/0xf0<br /> lr : btrfs_subpage_assert+0xbc/0xf0<br /> sp : ffff800093213720<br /> x29: ffff800093213720 x28: ffff8000932138b4 x27: 000000000c280000<br /> x26: 00000001b5d00000 x25: 000000000c281000 x24: 000000000c281fff<br /> x23: 0000000000001000 x22: 0000000000000000 x21: ffffff42b95bf880<br /> x20: ffff42b9528e0000 x19: 0000000000001000 x18: ffffffffffffffff<br /> x17: 667274622f736620 x16: 6e69202c65746176 x15: 0000000000000028<br /> x14: 0000000000000003 x13: 00000000002672d7 x12: 0000000000000000<br /> x11: ffffcd3f0ccd9204 x10: ffffcd3f0554ae50 x9 : ffffcd3f0379528c<br /> x8 : ffff800093213428 x7 : 0000000000000000 x6 : ffffcd3f091771e8<br /> x5 : ffff42b97f333948 x4 : 0000000000000000 x3 : 0000000000000000<br /> x2 : 0000000000000000 x1 : ffff42b9556cde80 x0 : 000000000000004f<br /> Call trace:<br /> btrfs_subpage_assert+0xbc/0xf0<br /> btrfs_subpage_set_dirty+0x38/0xa0<br /> btrfs_page_set_dirty+0x58/0x88<br /> relocate_one_page+0x204/0x5f0<br /> relocate_file_extent_cluster+0x11c/0x180<br /> relocate_data_extent+0xd0/0xf8<br /> relocate_block_group+0x3d0/0x4e8<br /> btrfs_relocate_block_group+0x2d8/0x490<br /> btrfs_relocate_chunk+0x54/0x1a8<br /> btrfs_balance+0x7f4/0x1150<br /> btrfs_ioctl+0x10f0/0x20b8<br /> __arm64_sys_ioctl+0x120/0x11d8<br /> invoke_syscall.constprop.0+0x80/0xd8<br /> do_el0_svc+0x6c/0x158<br /> el0_svc+0x50/0x1b0<br /> el0t_64_sync_handler+0x120/0x130<br /> el0t_64_sync+0x194/0x198<br /> Code: 91098021 b0007fa0 91346000 97e9c6d2 (d4210000)<br /> <br /> This is the same problem outlined in 17b17fcd6d44 ("btrfs:<br /> set_page_extent_mapped after read_folio in btrfs_cont_expand") , and the<br /> fix is the same. I originally looked for the same pattern elsewhere in<br /> our code, but mistakenly skipped over this code because I saw the page<br /> cache readahead before we set_page_extent_mapped, not realizing that<br /> this was only in the !page case, that we can still end up with a<br /> !uptodate page and then do the btrfs_read_folio further down.<br /> <br /> The fix here is the same as the above mentioned patch, move the<br /> set_page_extent_mapped call to after the btrfs_read_folio() block to<br /> make sure that we have the subpage blocksize stuff setup properly before<br /> using the page.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net/net_failover: fix txq exceeding warning<br /> <br /> The failover txq is inited as 16 queues.<br /> when a packet is transmitted from the failover device firstly,<br /> the failover device will select the queue which is returned from<br /> the primary device if the primary device is UP and running.<br /> If the primary device txq is bigger than the default 16,<br /> it can lead to the following warning:<br /> eth0 selects TX queue 18, but real number of TX queues is 16<br /> <br /> The warning backtrace is:<br /> [ 32.146376] CPU: 18 PID: 9134 Comm: chronyd Tainted: G E 6.2.8-1.el7.centos.x86_64 #1<br /> [ 32.147175] Hardware name: Red Hat KVM, BIOS 1.10.2-3.el7_4.1 04/01/2014<br /> [ 32.147730] Call Trace:<br /> [ 32.147971] <br /> [ 32.148183] dump_stack_lvl+0x48/0x70<br /> [ 32.148514] dump_stack+0x10/0x20<br /> [ 32.148820] netdev_core_pick_tx+0xb1/0xe0<br /> [ 32.149180] __dev_queue_xmit+0x529/0xcf0<br /> [ 32.149533] ? __check_object_size.part.0+0x21c/0x2c0<br /> [ 32.149967] ip_finish_output2+0x278/0x560<br /> [ 32.150327] __ip_finish_output+0x1fe/0x2f0<br /> [ 32.150690] ip_finish_output+0x2a/0xd0<br /> [ 32.151032] ip_output+0x7a/0x110<br /> [ 32.151337] ? __pfx_ip_finish_output+0x10/0x10<br /> [ 32.151733] ip_local_out+0x5e/0x70<br /> [ 32.152054] ip_send_skb+0x19/0x50<br /> [ 32.152366] udp_send_skb.isra.0+0x163/0x3a0<br /> [ 32.152736] udp_sendmsg+0xba8/0xec0<br /> [ 32.153060] ? __folio_memcg_unlock+0x25/0x60<br /> [ 32.153445] ? __pfx_ip_generic_getfrag+0x10/0x10<br /> [ 32.153854] ? sock_has_perm+0x85/0xa0<br /> [ 32.154190] inet_sendmsg+0x6d/0x80<br /> [ 32.154508] ? inet_sendmsg+0x6d/0x80<br /> [ 32.154838] sock_sendmsg+0x62/0x70<br /> [ 32.155152] ____sys_sendmsg+0x134/0x290<br /> [ 32.155499] ___sys_sendmsg+0x81/0xc0<br /> [ 32.155828] ? _get_random_bytes.part.0+0x79/0x1a0<br /> [ 32.156240] ? ip4_datagram_release_cb+0x5f/0x1e0<br /> [ 32.156649] ? get_random_u16+0x69/0xf0<br /> [ 32.156989] ? __fget_light+0xcf/0x110<br /> [ 32.157326] __sys_sendmmsg+0xc4/0x210<br /> [ 32.157657] ? __sys_connect+0xb7/0xe0<br /> [ 32.157995] ? __audit_syscall_entry+0xce/0x140<br /> [ 32.158388] ? syscall_trace_enter.isra.0+0x12c/0x1a0<br /> [ 32.158820] __x64_sys_sendmmsg+0x24/0x30<br /> [ 32.159171] do_syscall_64+0x38/0x90<br /> [ 32.159493] entry_SYSCALL_64_after_hwframe+0x72/0xdc<br /> <br /> Fix that by reducing txq number as the non-existent primary-dev does.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net/smc: fix potential panic dues to unprotected smc_llc_srv_add_link()<br /> <br /> There is a certain chance to trigger the following panic:<br /> <br /> PID: 5900 TASK: ffff88c1c8af4100 CPU: 1 COMMAND: "kworker/1:48"<br /> #0 [ffff9456c1cc79a0] machine_kexec at ffffffff870665b7<br /> #1 [ffff9456c1cc79f0] __crash_kexec at ffffffff871b4c7a<br /> #2 [ffff9456c1cc7ab0] crash_kexec at ffffffff871b5b60<br /> #3 [ffff9456c1cc7ac0] oops_end at ffffffff87026ce7<br /> #4 [ffff9456c1cc7ae0] page_fault_oops at ffffffff87075715<br /> #5 [ffff9456c1cc7b58] exc_page_fault at ffffffff87ad0654<br /> #6 [ffff9456c1cc7b80] asm_exc_page_fault at ffffffff87c00b62<br /> [exception RIP: ib_alloc_mr+19]<br /> RIP: ffffffffc0c9cce3 RSP: ffff9456c1cc7c38 RFLAGS: 00010202<br /> RAX: 0000000000000000 RBX: 0000000000000002 RCX: 0000000000000004<br /> RDX: 0000000000000010 RSI: 0000000000000000 RDI: 0000000000000000<br /> RBP: ffff88c1ea281d00 R8: 000000020a34ffff R9: ffff88c1350bbb20<br /> R10: 0000000000000000 R11: 0000000000000001 R12: 0000000000000000<br /> R13: 0000000000000010 R14: ffff88c1ab040a50 R15: ffff88c1ea281d00<br /> ORIG_RAX: ffffffffffffffff CS: 0010 SS: 0018<br /> #7 [ffff9456c1cc7c60] smc_ib_get_memory_region at ffffffffc0aff6df [smc]<br /> #8 [ffff9456c1cc7c88] smcr_buf_map_link at ffffffffc0b0278c [smc]<br /> #9 [ffff9456c1cc7ce0] __smc_buf_create at ffffffffc0b03586 [smc]<br /> <br /> The reason here is that when the server tries to create a second link,<br /> smc_llc_srv_add_link() has no protection and may add a new link to<br /> link group. This breaks the security environment protected by<br /> llc_conf_mutex.

*** 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.