Vulnerabilities

Rejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ipv6: Fix signed integer overflow in __ip6_append_data<br /> <br /> Resurrect ubsan overflow checks and ubsan report this warning,<br /> fix it by change the variable [length] type to size_t.<br /> <br /> UBSAN: signed-integer-overflow in net/ipv6/ip6_output.c:1489:19<br /> 2147479552 + 8567 cannot be represented in type &amp;#39;int&amp;#39;<br /> CPU: 0 PID: 253 Comm: err Not tainted 5.16.0+ #1<br /> Hardware name: linux,dummy-virt (DT)<br /> Call trace:<br /> dump_backtrace+0x214/0x230<br /> show_stack+0x30/0x78<br /> dump_stack_lvl+0xf8/0x118<br /> dump_stack+0x18/0x30<br /> ubsan_epilogue+0x18/0x60<br /> handle_overflow+0xd0/0xf0<br /> __ubsan_handle_add_overflow+0x34/0x44<br /> __ip6_append_data.isra.48+0x1598/0x1688<br /> ip6_append_data+0x128/0x260<br /> udpv6_sendmsg+0x680/0xdd0<br /> inet6_sendmsg+0x54/0x90<br /> sock_sendmsg+0x70/0x88<br /> ____sys_sendmsg+0xe8/0x368<br /> ___sys_sendmsg+0x98/0xe0<br /> __sys_sendmmsg+0xf4/0x3b8<br /> __arm64_sys_sendmmsg+0x34/0x48<br /> invoke_syscall+0x64/0x160<br /> el0_svc_common.constprop.4+0x124/0x300<br /> do_el0_svc+0x44/0xc8<br /> el0_svc+0x3c/0x1e8<br /> el0t_64_sync_handler+0x88/0xb0<br /> el0t_64_sync+0x16c/0x170<br /> <br /> Changes since v1:<br /> -Change the variable [length] type to unsigned, as Eric Dumazet suggested.<br /> Changes since v2:<br /> -Don&amp;#39;t change exthdrlen type in ip6_make_skb, as Paolo Abeni suggested.<br /> Changes since v3:<br /> -Don&amp;#39;t change ulen type in udpv6_sendmsg and l2tp_ip6_sendmsg, as<br /> Jakub Kicinski suggested.

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

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ice: Fix memory corruption in VF driver<br /> <br /> Disable VF&amp;#39;s RX/TX queues, when it&amp;#39;s disabled. VF can have queues enabled,<br /> when it requests a reset. If PF driver assumes that VF is disabled,<br /> while VF still has queues configured, VF may unmap DMA resources.<br /> In such scenario device still can map packets to memory, which ends up<br /> silently corrupting it.<br /> Previously, VF driver could experience memory corruption, which lead to<br /> crash:<br /> [ 5119.170157] BUG: unable to handle kernel paging request at 00001b9780003237<br /> [ 5119.170166] PGD 0 P4D 0<br /> [ 5119.170173] Oops: 0002 [#1] PREEMPT_RT SMP PTI<br /> [ 5119.170181] CPU: 30 PID: 427592 Comm: kworker/u96:2 Kdump: loaded Tainted: G W I --------- - - 4.18.0-372.9.1.rt7.166.el8.x86_64 #1<br /> [ 5119.170189] Hardware name: Dell Inc. PowerEdge R740/014X06, BIOS 2.3.10 08/15/2019<br /> [ 5119.170193] Workqueue: iavf iavf_adminq_task [iavf]<br /> [ 5119.170219] RIP: 0010:__page_frag_cache_drain+0x5/0x30<br /> [ 5119.170238] Code: 0f 0f b6 77 51 85 f6 74 07 31 d2 e9 05 df ff ff e9 90 fe ff ff 48 8b 05 49 db 33 01 eb b4 0f 1f 80 00 00 00 00 0f 1f 44 00 00 29 77 34 74 01 c3 48 8b 07 f6 c4 80 74 0f 0f b6 77 51 85 f6 74<br /> [ 5119.170244] RSP: 0018:ffffa43b0bdcfd78 EFLAGS: 00010282<br /> [ 5119.170250] RAX: ffffffff896b3e40 RBX: ffff8fb282524000 RCX: 0000000000000002<br /> [ 5119.170254] RDX: 0000000049000000 RSI: 0000000000000000 RDI: 00001b9780003203<br /> [ 5119.170259] RBP: ffff8fb248217b00 R08: 0000000000000022 R09: 0000000000000009<br /> [ 5119.170262] R10: 2b849d6300000000 R11: 0000000000000020 R12: 0000000000000000<br /> [ 5119.170265] R13: 0000000000001000 R14: 0000000000000009 R15: 0000000000000000<br /> [ 5119.170269] FS: 0000000000000000(0000) GS:ffff8fb1201c0000(0000) knlGS:0000000000000000<br /> [ 5119.170274] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> [ 5119.170279] CR2: 00001b9780003237 CR3: 00000008f3e1a003 CR4: 00000000007726e0<br /> [ 5119.170283] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000<br /> [ 5119.170286] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400<br /> [ 5119.170290] PKRU: 55555554<br /> [ 5119.170292] Call Trace:<br /> [ 5119.170298] iavf_clean_rx_ring+0xad/0x110 [iavf]<br /> [ 5119.170324] iavf_free_rx_resources+0xe/0x50 [iavf]<br /> [ 5119.170342] iavf_free_all_rx_resources.part.51+0x30/0x40 [iavf]<br /> [ 5119.170358] iavf_virtchnl_completion+0xd8a/0x15b0 [iavf]<br /> [ 5119.170377] ? iavf_clean_arq_element+0x210/0x280 [iavf]<br /> [ 5119.170397] iavf_adminq_task+0x126/0x2e0 [iavf]<br /> [ 5119.170416] process_one_work+0x18f/0x420<br /> [ 5119.170429] worker_thread+0x30/0x370<br /> [ 5119.170437] ? process_one_work+0x420/0x420<br /> [ 5119.170445] kthread+0x151/0x170<br /> [ 5119.170452] ? set_kthread_struct+0x40/0x40<br /> [ 5119.170460] ret_from_fork+0x35/0x40<br /> [ 5119.170477] Modules linked in: iavf sctp ip6_udp_tunnel udp_tunnel mlx4_en mlx4_core nfp tls vhost_net vhost vhost_iotlb tap tun xt_CHECKSUM ipt_MASQUERADE xt_conntrack ipt_REJECT nf_reject_ipv4 nft_compat nft_counter nft_chain_nat nf_nat nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 nf_tables nfnetlink bridge stp llc rpcsec_gss_krb5 auth_rpcgss nfsv4 dns_resolver nfs lockd grace fscache sunrpc intel_rapl_msr iTCO_wdt iTCO_vendor_support dell_smbios wmi_bmof dell_wmi_descriptor dcdbas kvm_intel kvm irqbypass intel_rapl_common isst_if_common skx_edac irdma nfit libnvdimm x86_pkg_temp_thermal i40e intel_powerclamp coretemp crct10dif_pclmul crc32_pclmul ghash_clmulni_intel ib_uverbs rapl ipmi_ssif intel_cstate intel_uncore mei_me pcspkr acpi_ipmi ib_core mei lpc_ich i2c_i801 ipmi_si ipmi_devintf wmi ipmi_msghandler acpi_power_meter xfs libcrc32c sd_mod t10_pi sg mgag200 drm_kms_helper syscopyarea sysfillrect sysimgblt fb_sys_fops ice ahci drm libahci crc32c_intel libata tg3 megaraid_sas<br /> [ 5119.170613] i2c_algo_bit dm_mirror dm_region_hash dm_log dm_mod fuse [last unloaded: iavf]<br /> [ 5119.170627] CR2: 00001b9780003237