Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> clocksource: hyper-v: unexport __init-annotated hv_init_clocksource()<br /> <br /> EXPORT_SYMBOL and __init is a bad combination because the .init.text<br /> section is freed up after the initialization. Hence, modules cannot<br /> use symbols annotated __init. The access to a freed symbol may end up<br /> with kernel panic.<br /> <br /> modpost used to detect it, but it has been broken for a decade.<br /> <br /> Recently, I fixed modpost so it started to warn it again, then this<br /> showed up in linux-next builds.<br /> <br /> There are two ways to fix it:<br /> <br /> - Remove __init<br /> - Remove EXPORT_SYMBOL<br /> <br /> I chose the latter for this case because the only in-tree call-site,<br /> arch/x86/kernel/cpu/mshyperv.c is never compiled as modular.<br /> (CONFIG_HYPERVISOR_GUEST is boolean)

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ipv6: Fix signed integer overflow in l2tp_ip6_sendmsg<br /> <br /> When len &gt;= INT_MAX - transhdrlen, ulen = len + transhdrlen will be<br /> overflow. To fix, we can follow what udpv6 does and subtract the<br /> transhdrlen from the max.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> i40e: Fix call trace in setup_tx_descriptors<br /> <br /> After PF reset and ethtool -t there was call trace in dmesg<br /> sometimes leading to panic. When there was some time, around 5<br /> seconds, between reset and test there were no errors.<br /> <br /> Problem was that pf reset calls i40e_vsi_close in prep_for_reset<br /> and ethtool -t calls i40e_vsi_close in diag_test. If there was not<br /> enough time between those commands the second i40e_vsi_close starts<br /> before previous i40e_vsi_close was done which leads to crash.<br /> <br /> Add check to diag_test if pf is in reset and don&amp;#39;t start offline<br /> tests if it is true.<br /> Add netif_info("testing failed") into unhappy path of i40e_diag_test()

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> usb: dwc2: Fix memory leak in dwc2_hcd_init<br /> <br /> usb_create_hcd will alloc memory for hcd, and we should<br /> call usb_put_hcd to free it when platform_get_resource()<br /> fails to prevent memory leak.<br /> goto error2 label instead error1 to fix this.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> irqchip/realtek-rtl: Fix refcount leak in map_interrupts<br /> <br /> of_find_node_by_phandle() returns a node pointer with refcount<br /> incremented, we should use of_node_put() on it when not need anymore.<br /> This function doesn&amp;#39;t call of_node_put() in error path.<br /> Call of_node_put() directly after of_property_read_u32() to cover<br /> both normal path and error path.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> irqchip/gic-v3: Fix refcount leak in gic_populate_ppi_partitions<br /> <br /> of_find_node_by_phandle() returns a node pointer with refcount<br /> incremented, we should use of_node_put() on it when not need anymore.<br /> Add missing of_node_put() to avoid refcount leak.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> irqchip/gic-v3: Fix error handling in gic_populate_ppi_partitions<br /> <br /> of_get_child_by_name() returns a node pointer with refcount<br /> incremented, we should use of_node_put() on it when not need anymore.<br /> When kcalloc fails, it missing of_node_put() and results in refcount<br /> leak. Fix this by goto out_put_node label.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> irqchip/apple-aic: Fix refcount leak in build_fiq_affinity<br /> <br /> of_find_node_by_phandle() returns a node pointer with refcount<br /> incremented, we should use of_node_put() on it when not need anymore.<br /> Add missing of_node_put() to avoid refcount leak.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> irqchip/apple-aic: Fix refcount leak in aic_of_ic_init<br /> <br /> of_get_child_by_name() returns a node pointer with refcount<br /> incremented, we should use of_node_put() on it when not need anymore.<br /> Add missing of_node_put() to avoid refcount leak.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> irqchip/gic/realview: Fix refcount leak in realview_gic_of_init<br /> <br /> of_find_matching_node_and_match() returns a node pointer with refcount<br /> incremented, we should use of_node_put() on it when not need anymore.<br /> Add missing of_node_put() to avoid refcount leak.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> block: Fix handling of offline queues in blk_mq_alloc_request_hctx()<br /> <br /> This patch prevents that test nvme/004 triggers the following:<br /> <br /> UBSAN: array-index-out-of-bounds in block/blk-mq.h:135:9<br /> index 512 is out of range for type &amp;#39;long unsigned int [512]&amp;#39;<br /> Call Trace:<br /> show_stack+0x52/0x58<br /> dump_stack_lvl+0x49/0x5e<br /> dump_stack+0x10/0x12<br /> ubsan_epilogue+0x9/0x3b<br /> __ubsan_handle_out_of_bounds.cold+0x44/0x49<br /> blk_mq_alloc_request_hctx+0x304/0x310<br /> __nvme_submit_sync_cmd+0x70/0x200 [nvme_core]<br /> nvmf_connect_io_queue+0x23e/0x2a0 [nvme_fabrics]<br /> nvme_loop_connect_io_queues+0x8d/0xb0 [nvme_loop]<br /> nvme_loop_create_ctrl+0x58e/0x7d0 [nvme_loop]<br /> nvmf_create_ctrl+0x1d7/0x4d0 [nvme_fabrics]<br /> nvmf_dev_write+0xae/0x111 [nvme_fabrics]<br /> vfs_write+0x144/0x560<br /> ksys_write+0xb7/0x140<br /> __x64_sys_write+0x42/0x50<br /> do_syscall_64+0x35/0x80<br /> entry_SYSCALL_64_after_hwframe+0x44/0xae

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> arm64: ftrace: consistently handle PLTs.<br /> <br /> Sometimes it is necessary to use a PLT entry to call an ftrace<br /> trampoline. This is handled by ftrace_make_call() and ftrace_make_nop(),<br /> with each having *almost* identical logic, but this is not handled by<br /> ftrace_modify_call() since its introduction in commit:<br /> <br /> 3b23e4991fb66f6d ("arm64: implement ftrace with regs")<br /> <br /> Due to this, if we ever were to call ftrace_modify_call() for a callsite<br /> which requires a PLT entry for a trampoline, then either:<br /> <br /> a) If the old addr requires a trampoline, ftrace_modify_call() will use<br /> an out-of-range address to generate the &amp;#39;old&amp;#39; branch instruction.<br /> This will result in warnings from aarch64_insn_gen_branch_imm() and<br /> ftrace_modify_code(), and no instructions will be modified. As<br /> ftrace_modify_call() will return an error, this will result in<br /> subsequent internal ftrace errors.<br /> <br /> b) If the old addr does not require a trampoline, but the new addr does,<br /> ftrace_modify_call() will use an out-of-range address to generate the<br /> &amp;#39;new&amp;#39; branch instruction. This will result in warnings from<br /> aarch64_insn_gen_branch_imm(), and ftrace_modify_code() will replace<br /> the &amp;#39;old&amp;#39; branch with a BRK. This will result in a kernel panic when<br /> this BRK is later executed.<br /> <br /> Practically speaking, case (a) is vastly more likely than case (b), and<br /> typically this will result in internal ftrace errors that don&amp;#39;t<br /> necessarily affect the rest of the system. This can be demonstrated with<br /> an out-of-tree test module which triggers ftrace_modify_call(), e.g.<br /> <br /> | # insmod test_ftrace.ko<br /> | test_ftrace: Function test_function raw=0xffffb3749399201c, callsite=0xffffb37493992024<br /> | branch_imm_common: offset out of range<br /> | branch_imm_common: offset out of range<br /> | ------------[ ftrace bug ]------------<br /> | ftrace failed to modify<br /> | [] test_function+0x8/0x38 [test_ftrace]<br /> | actual: 1d:00:00:94<br /> | Updating ftrace call site to call a different ftrace function<br /> | ftrace record flags: e0000002<br /> | (2) R<br /> | expected tramp: ffffb374ae42ed54<br /> | ------------[ cut here ]------------<br /> | WARNING: CPU: 0 PID: 165 at kernel/trace/ftrace.c:2085 ftrace_bug+0x280/0x2b0<br /> | Modules linked in: test_ftrace(+)<br /> | CPU: 0 PID: 165 Comm: insmod Not tainted 5.19.0-rc2-00002-g4d9ead8b45ce #13<br /> | Hardware name: linux,dummy-virt (DT)<br /> | pstate: 60400005 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)<br /> | pc : ftrace_bug+0x280/0x2b0<br /> | lr : ftrace_bug+0x280/0x2b0<br /> | sp : ffff80000839ba00<br /> | x29: ffff80000839ba00 x28: 0000000000000000 x27: ffff80000839bcf0<br /> | x26: ffffb37493994180 x25: ffffb374b0991c28 x24: ffffb374b0d70000<br /> | x23: 00000000ffffffea x22: ffffb374afcc33b0 x21: ffffb374b08f9cc8<br /> | x20: ffff572b8462c000 x19: ffffb374b08f9000 x18: ffffffffffffffff<br /> | x17: 6c6c6163202c6331 x16: ffffb374ae5ad110 x15: ffffb374b0d51ee4<br /> | x14: 0000000000000000 x13: 3435646532346561 x12: 3437336266666666<br /> | x11: 203a706d61727420 x10: 6465746365707865 x9 : ffffb374ae5149e8<br /> | x8 : 336266666666203a x7 : 706d617274206465 x6 : 00000000fffff167<br /> | x5 : ffff572bffbc4a08 x4 : 00000000fffff167 x3 : 0000000000000000<br /> | x2 : 0000000000000000 x1 : ffff572b84461e00 x0 : 0000000000000022<br /> | Call trace:<br /> | ftrace_bug+0x280/0x2b0<br /> | ftrace_replace_code+0x98/0xa0<br /> | ftrace_modify_all_code+0xe0/0x144<br /> | arch_ftrace_update_code+0x14/0x20<br /> | ftrace_startup+0xf8/0x1b0<br /> | register_ftrace_function+0x38/0x90<br /> | test_ftrace_init+0xd0/0x1000 [test_ftrace]<br /> | do_one_initcall+0x50/0x2b0<br /> | do_init_module+0x50/0x1f0<br /> | load_module+0x17c8/0x1d64<br /> | __do_sys_finit_module+0xa8/0x100<br /> | __arm64_sys_finit_module+0x2c/0x3c<br /> | invoke_syscall+0x50/0x120<br /> | el0_svc_common.constprop.0+0xdc/0x100<br /> | do_el0_svc+0x3c/0xd0<br /> | el0_svc+0x34/0xb0<br /> | el0t_64_sync_handler+0xbc/0x140<br /> | el0t_64_sync+0x18c/0x190<br /> | ---[ end trace 0000000000000000 ]---<br /> <br /> We can solve this by consistently determining whether to use a PLT entry<br /> for an address.<br /> <br /> Note that since (the earlier) commit:<br /> <br /> f1a54ae9<br /> ---truncated---