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 /> x86/mm: Disallow vsyscall page read for copy_from_kernel_nofault()<br /> <br /> When trying to use copy_from_kernel_nofault() to read vsyscall page<br /> through a bpf program, the following oops was reported:<br /> <br /> BUG: unable to handle page fault for address: ffffffffff600000<br /> #PF: supervisor read access in kernel mode<br /> #PF: error_code(0x0000) - not-present page<br /> PGD 3231067 P4D 3231067 PUD 3233067 PMD 3235067 PTE 0<br /> Oops: 0000 [#1] PREEMPT SMP PTI<br /> CPU: 1 PID: 20390 Comm: test_progs ...... 6.7.0+ #58<br /> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996) ......<br /> RIP: 0010:copy_from_kernel_nofault+0x6f/0x110<br /> ......<br /> Call Trace:<br /> <br /> ? copy_from_kernel_nofault+0x6f/0x110<br /> bpf_probe_read_kernel+0x1d/0x50<br /> bpf_prog_2061065e56845f08_do_probe_read+0x51/0x8d<br /> trace_call_bpf+0xc5/0x1c0<br /> perf_call_bpf_enter.isra.0+0x69/0xb0<br /> perf_syscall_enter+0x13e/0x200<br /> syscall_trace_enter+0x188/0x1c0<br /> do_syscall_64+0xb5/0xe0<br /> entry_SYSCALL_64_after_hwframe+0x6e/0x76<br /> <br /> ......<br /> ---[ end trace 0000000000000000 ]---<br /> <br /> The oops is triggered when:<br /> <br /> 1) A bpf program uses bpf_probe_read_kernel() to read from the vsyscall<br /> page and invokes copy_from_kernel_nofault() which in turn calls<br /> __get_user_asm().<br /> <br /> 2) Because the vsyscall page address is not readable from kernel space,<br /> a page fault exception is triggered accordingly.<br /> <br /> 3) handle_page_fault() considers the vsyscall page address as a user<br /> space address instead of a kernel space address. This results in the<br /> fix-up setup by bpf not being applied and a page_fault_oops() is invoked<br /> due to SMAP.<br /> <br /> Considering handle_page_fault() has already considered the vsyscall page<br /> address as a userspace address, fix the problem by disallowing vsyscall<br /> page read for copy_from_kernel_nofault().

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> RDMA/mlx5: Fix fortify source warning while accessing Eth segment<br /> <br /> ------------[ cut here ]------------<br /> memcpy: detected field-spanning write (size 56) of single field "eseg-&gt;inline_hdr.start" at /var/lib/dkms/mlnx-ofed-kernel/5.8/build/drivers/infiniband/hw/mlx5/wr.c:131 (size 2)<br /> WARNING: CPU: 0 PID: 293779 at /var/lib/dkms/mlnx-ofed-kernel/5.8/build/drivers/infiniband/hw/mlx5/wr.c:131 mlx5_ib_post_send+0x191b/0x1a60 [mlx5_ib]<br /> Modules linked in: 8021q garp mrp stp llc rdma_ucm(OE) rdma_cm(OE) iw_cm(OE) ib_ipoib(OE) ib_cm(OE) ib_umad(OE) mlx5_ib(OE) ib_uverbs(OE) ib_core(OE) mlx5_core(OE) pci_hyperv_intf mlxdevm(OE) mlx_compat(OE) tls mlxfw(OE) psample nft_fib_inet nft_fib_ipv4 nft_fib_ipv6 nft_fib nft_reject_inet nf_reject_ipv4 nf_reject_ipv6 nft_reject nft_ct nft_chain_nat nf_nat nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 ip_set nf_tables libcrc32c nfnetlink mst_pciconf(OE) knem(OE) vfio_pci vfio_pci_core vfio_iommu_type1 vfio iommufd irqbypass cuse nfsv3 nfs fscache netfs xfrm_user xfrm_algo ipmi_devintf ipmi_msghandler binfmt_misc crct10dif_pclmul crc32_pclmul polyval_clmulni polyval_generic ghash_clmulni_intel sha512_ssse3 snd_pcsp aesni_intel crypto_simd cryptd snd_pcm snd_timer joydev snd soundcore input_leds serio_raw evbug nfsd auth_rpcgss nfs_acl lockd grace sch_fq_codel sunrpc drm efi_pstore ip_tables x_tables autofs4 psmouse virtio_net net_failover failover floppy<br /> [last unloaded: mlx_compat(OE)]<br /> CPU: 0 PID: 293779 Comm: ssh Tainted: G OE 6.2.0-32-generic #32~22.04.1-Ubuntu<br /> Hardware name: Red Hat KVM, BIOS 0.5.1 01/01/2011<br /> RIP: 0010:mlx5_ib_post_send+0x191b/0x1a60 [mlx5_ib]<br /> Code: 0c 01 00 a8 01 75 25 48 8b 75 a0 b9 02 00 00 00 48 c7 c2 10 5b fd c0 48 c7 c7 80 5b fd c0 c6 05 57 0c 03 00 01 e8 95 4d 93 da 0b 44 8b 4d b0 4c 8b 45 c8 48 8b 4d c0 e9 49 fb ff ff 41 0f b7<br /> RSP: 0018:ffffb5b48478b570 EFLAGS: 00010046<br /> RAX: 0000000000000000 RBX: 0000000000000001 RCX: 0000000000000000<br /> RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000<br /> RBP: ffffb5b48478b628 R08: 0000000000000000 R09: 0000000000000000<br /> R10: 0000000000000000 R11: 0000000000000000 R12: ffffb5b48478b5e8<br /> R13: ffff963a3c609b5e R14: ffff9639c3fbd800 R15: ffffb5b480475a80<br /> FS: 00007fc03b444c80(0000) GS:ffff963a3dc00000(0000) knlGS:0000000000000000<br /> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> CR2: 0000556f46bdf000 CR3: 0000000006ac6003 CR4: 00000000003706f0<br /> DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000<br /> DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400<br /> Call Trace:<br /> <br /> ? show_regs+0x72/0x90<br /> ? mlx5_ib_post_send+0x191b/0x1a60 [mlx5_ib]<br /> ? __warn+0x8d/0x160<br /> ? mlx5_ib_post_send+0x191b/0x1a60 [mlx5_ib]<br /> ? report_bug+0x1bb/0x1d0<br /> ? handle_bug+0x46/0x90<br /> ? exc_invalid_op+0x19/0x80<br /> ? asm_exc_invalid_op+0x1b/0x20<br /> ? mlx5_ib_post_send+0x191b/0x1a60 [mlx5_ib]<br /> mlx5_ib_post_send_nodrain+0xb/0x20 [mlx5_ib]<br /> ipoib_send+0x2ec/0x770 [ib_ipoib]<br /> ipoib_start_xmit+0x5a0/0x770 [ib_ipoib]<br /> dev_hard_start_xmit+0x8e/0x1e0<br /> ? validate_xmit_skb_list+0x4d/0x80<br /> sch_direct_xmit+0x116/0x3a0<br /> __dev_xmit_skb+0x1fd/0x580<br /> __dev_queue_xmit+0x284/0x6b0<br /> ? _raw_spin_unlock_irq+0xe/0x50<br /> ? __flush_work.isra.0+0x20d/0x370<br /> ? push_pseudo_header+0x17/0x40 [ib_ipoib]<br /> neigh_connected_output+0xcd/0x110<br /> ip_finish_output2+0x179/0x480<br /> ? __smp_call_single_queue+0x61/0xa0<br /> __ip_finish_output+0xc3/0x190<br /> ip_finish_output+0x2e/0xf0<br /> ip_output+0x78/0x110<br /> ? __pfx_ip_finish_output+0x10/0x10<br /> ip_local_out+0x64/0x70<br /> __ip_queue_xmit+0x18a/0x460<br /> ip_queue_xmit+0x15/0x30<br /> __tcp_transmit_skb+0x914/0x9c0<br /> tcp_write_xmit+0x334/0x8d0<br /> tcp_push_one+0x3c/0x60<br /> tcp_sendmsg_locked+0x2e1/0xac0<br /> tcp_sendmsg+0x2d/0x50<br /> inet_sendmsg+0x43/0x90<br /> sock_sendmsg+0x68/0x80<br /> sock_write_iter+0x93/0x100<br /> vfs_write+0x326/0x3c0<br /> ksys_write+0xbd/0xf0<br /> ? do_syscall_64+0x69/0x90<br /> __x64_sys_write+0x19/0x30<br /> do_syscall_<br /> ---truncated---

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 /> soc: qcom: pmic_glink_altmode: fix drm bridge use-after-free<br /> <br /> A recent DRM series purporting to simplify support for "transparent<br /> bridges" and handling of probe deferrals ironically exposed a<br /> use-after-free issue on pmic_glink_altmode probe deferral.<br /> <br /> This has manifested itself as the display subsystem occasionally failing<br /> to initialise and NULL-pointer dereferences during boot of machines like<br /> the Lenovo ThinkPad X13s.<br /> <br /> Specifically, the dp-hpd bridge is currently registered before all<br /> resources have been acquired which means that it can also be<br /> deregistered on probe deferrals.<br /> <br /> In the meantime there is a race window where the new aux bridge driver<br /> (or PHY driver previously) may have looked up the dp-hpd bridge and<br /> stored a (non-reference-counted) pointer to the bridge which is about to<br /> be deallocated.<br /> <br /> When the display controller is later initialised, this triggers a<br /> use-after-free when attaching the bridges:<br /> <br /> dp -&gt; aux -&gt; dp-hpd (freed)<br /> <br /> which may, for example, result in the freed bridge failing to attach:<br /> <br /> [drm:drm_bridge_attach [drm]] *ERROR* failed to attach bridge /soc@0/phy@88eb000 to encoder TMDS-31: -16<br /> <br /> or a NULL-pointer dereference:<br /> <br /> Unable to handle kernel NULL pointer dereference at virtual address 0000000000000000<br /> ...<br /> Call trace:<br /> drm_bridge_attach+0x70/0x1a8 [drm]<br /> drm_aux_bridge_attach+0x24/0x38 [aux_bridge]<br /> drm_bridge_attach+0x80/0x1a8 [drm]<br /> dp_bridge_init+0xa8/0x15c [msm]<br /> msm_dp_modeset_init+0x28/0xc4 [msm]<br /> <br /> The DRM bridge implementation is clearly fragile and implicitly built on<br /> the assumption that bridges may never go away. In this case, the fix is<br /> to move the bridge registration in the pmic_glink_altmode driver to<br /> after all resources have been looked up.<br /> <br /> Incidentally, with the new dp-hpd bridge implementation, which registers<br /> child devices, this is also a requirement due to a long-standing issue<br /> in driver core that can otherwise lead to a probe deferral loop (see<br /> commit fbc35b45f9f6 ("Add documentation on meaning of -EPROBE_DEFER")).<br /> <br /> [DB: slightly fixed commit message by adding the word &amp;#39;commit&amp;#39;]

A vulnerability was found in Tenda AC500 2.0.1.9(1307). It has been classified as critical. This affects the function R7WebsSecurityHandler of the file /goform/execCommand. The manipulation of the argument password leads to stack-based buffer overflow. It is possible to initiate the attack remotely. The exploit has been disclosed to the public and may be used. The identifier VDB-261141 was assigned to this vulnerability. NOTE: The vendor was contacted early about this disclosure but did not respond in any way.

A vulnerability was found in Tenda AC500 2.0.1.9(1307). It has been declared as critical. This vulnerability affects the function formQuickIndex of the file /goform/QuickIndex. The manipulation of the argument PPPOEPassword leads to stack-based buffer overflow. The attack can be initiated remotely. The exploit has been disclosed to the public and may be used. VDB-261142 is the identifier assigned to this vulnerability. NOTE: The vendor was contacted early about this disclosure but did not respond in any way.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: hns3: fix kernel crash when 1588 is received on HIP08 devices<br /> <br /> The HIP08 devices does not register the ptp devices, so the<br /> hdev-&gt;ptp is NULL, but the hardware can receive 1588 messages,<br /> and set the HNS3_RXD_TS_VLD_B bit, so, if match this case, the<br /> access of hdev-&gt;ptp-&gt;flags will cause a kernel crash:<br /> <br /> [ 5888.946472] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000018<br /> [ 5888.946475] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000018<br /> ...<br /> [ 5889.266118] pc : hclge_ptp_get_rx_hwts+0x40/0x170 [hclge]<br /> [ 5889.272612] lr : hclge_ptp_get_rx_hwts+0x34/0x170 [hclge]<br /> [ 5889.279101] sp : ffff800012c3bc50<br /> [ 5889.283516] x29: ffff800012c3bc50 x28: ffff2040002be040<br /> [ 5889.289927] x27: ffff800009116484 x26: 0000000080007500<br /> [ 5889.296333] x25: 0000000000000000 x24: ffff204001c6f000<br /> [ 5889.302738] x23: ffff204144f53c00 x22: 0000000000000000<br /> [ 5889.309134] x21: 0000000000000000 x20: ffff204004220080<br /> [ 5889.315520] x19: ffff204144f53c00 x18: 0000000000000000<br /> [ 5889.321897] x17: 0000000000000000 x16: 0000000000000000<br /> [ 5889.328263] x15: 0000004000140ec8 x14: 0000000000000000<br /> [ 5889.334617] x13: 0000000000000000 x12: 00000000010011df<br /> [ 5889.340965] x11: bbfeff4d22000000 x10: 0000000000000000<br /> [ 5889.347303] x9 : ffff800009402124 x8 : 0200f78811dfbb4d<br /> [ 5889.353637] x7 : 2200000000191b01 x6 : ffff208002a7d480<br /> [ 5889.359959] x5 : 0000000000000000 x4 : 0000000000000000<br /> [ 5889.366271] x3 : 0000000000000000 x2 : 0000000000000000<br /> [ 5889.372567] x1 : 0000000000000000 x0 : ffff20400095c080<br /> [ 5889.378857] Call trace:<br /> [ 5889.382285] hclge_ptp_get_rx_hwts+0x40/0x170 [hclge]<br /> [ 5889.388304] hns3_handle_bdinfo+0x324/0x410 [hns3]<br /> [ 5889.394055] hns3_handle_rx_bd+0x60/0x150 [hns3]<br /> [ 5889.399624] hns3_clean_rx_ring+0x84/0x170 [hns3]<br /> [ 5889.405270] hns3_nic_common_poll+0xa8/0x220 [hns3]<br /> [ 5889.411084] napi_poll+0xcc/0x264<br /> [ 5889.415329] net_rx_action+0xd4/0x21c<br /> [ 5889.419911] __do_softirq+0x130/0x358<br /> [ 5889.424484] irq_exit+0x134/0x154<br /> [ 5889.428700] __handle_domain_irq+0x88/0xf0<br /> [ 5889.433684] gic_handle_irq+0x78/0x2c0<br /> [ 5889.438319] el1_irq+0xb8/0x140<br /> [ 5889.442354] arch_cpu_idle+0x18/0x40<br /> [ 5889.446816] default_idle_call+0x5c/0x1c0<br /> [ 5889.451714] cpuidle_idle_call+0x174/0x1b0<br /> [ 5889.456692] do_idle+0xc8/0x160<br /> [ 5889.460717] cpu_startup_entry+0x30/0xfc<br /> [ 5889.465523] secondary_start_kernel+0x158/0x1ec<br /> [ 5889.470936] Code: 97ffab78 f9411c14 91408294 f9457284 (f9400c80)<br /> [ 5889.477950] SMP: stopping secondary CPUs<br /> [ 5890.514626] SMP: failed to stop secondary CPUs 0-69,71-95<br /> [ 5890.522951] Starting crashdump kernel...

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: ip_tunnel: make sure to pull inner header in ip_tunnel_rcv()<br /> <br /> Apply the same fix than ones found in :<br /> <br /> 8d975c15c0cd ("ip6_tunnel: make sure to pull inner header in __ip6_tnl_rcv()")<br /> 1ca1ba465e55 ("geneve: make sure to pull inner header in geneve_rx()")<br /> <br /> We have to save skb-&gt;network_header in a temporary variable<br /> in order to be able to recompute the network_header pointer<br /> after a pskb_inet_may_pull() call.<br /> <br /> pskb_inet_may_pull() makes sure the needed headers are in skb-&gt;head.<br /> <br /> syzbot reported:<br /> BUG: KMSAN: uninit-value in __INET_ECN_decapsulate include/net/inet_ecn.h:253 [inline]<br /> BUG: KMSAN: uninit-value in INET_ECN_decapsulate include/net/inet_ecn.h:275 [inline]<br /> BUG: KMSAN: uninit-value in IP_ECN_decapsulate include/net/inet_ecn.h:302 [inline]<br /> BUG: KMSAN: uninit-value in ip_tunnel_rcv+0xed9/0x2ed0 net/ipv4/ip_tunnel.c:409<br /> __INET_ECN_decapsulate include/net/inet_ecn.h:253 [inline]<br /> INET_ECN_decapsulate include/net/inet_ecn.h:275 [inline]<br /> IP_ECN_decapsulate include/net/inet_ecn.h:302 [inline]<br /> ip_tunnel_rcv+0xed9/0x2ed0 net/ipv4/ip_tunnel.c:409<br /> __ipgre_rcv+0x9bc/0xbc0 net/ipv4/ip_gre.c:389<br /> ipgre_rcv net/ipv4/ip_gre.c:411 [inline]<br /> gre_rcv+0x423/0x19f0 net/ipv4/ip_gre.c:447<br /> gre_rcv+0x2a4/0x390 net/ipv4/gre_demux.c:163<br /> ip_protocol_deliver_rcu+0x264/0x1300 net/ipv4/ip_input.c:205<br /> ip_local_deliver_finish+0x2b8/0x440 net/ipv4/ip_input.c:233<br /> NF_HOOK include/linux/netfilter.h:314 [inline]<br /> ip_local_deliver+0x21f/0x490 net/ipv4/ip_input.c:254<br /> dst_input include/net/dst.h:461 [inline]<br /> ip_rcv_finish net/ipv4/ip_input.c:449 [inline]<br /> NF_HOOK include/linux/netfilter.h:314 [inline]<br /> ip_rcv+0x46f/0x760 net/ipv4/ip_input.c:569<br /> __netif_receive_skb_one_core net/core/dev.c:5534 [inline]<br /> __netif_receive_skb+0x1a6/0x5a0 net/core/dev.c:5648<br /> netif_receive_skb_internal net/core/dev.c:5734 [inline]<br /> netif_receive_skb+0x58/0x660 net/core/dev.c:5793<br /> tun_rx_batched+0x3ee/0x980 drivers/net/tun.c:1556<br /> tun_get_user+0x53b9/0x66e0 drivers/net/tun.c:2009<br /> tun_chr_write_iter+0x3af/0x5d0 drivers/net/tun.c:2055<br /> call_write_iter include/linux/fs.h:2087 [inline]<br /> new_sync_write fs/read_write.c:497 [inline]<br /> vfs_write+0xb6b/0x1520 fs/read_write.c:590<br /> ksys_write+0x20f/0x4c0 fs/read_write.c:643<br /> __do_sys_write fs/read_write.c:655 [inline]<br /> __se_sys_write fs/read_write.c:652 [inline]<br /> __x64_sys_write+0x93/0xd0 fs/read_write.c:652<br /> do_syscall_x64 arch/x86/entry/common.c:52 [inline]<br /> do_syscall_64+0xcf/0x1e0 arch/x86/entry/common.c:83<br /> entry_SYSCALL_64_after_hwframe+0x63/0x6b<br /> <br /> Uninit was created at:<br /> __alloc_pages+0x9a6/0xe00 mm/page_alloc.c:4590<br /> alloc_pages_mpol+0x62b/0x9d0 mm/mempolicy.c:2133<br /> alloc_pages+0x1be/0x1e0 mm/mempolicy.c:2204<br /> skb_page_frag_refill+0x2bf/0x7c0 net/core/sock.c:2909<br /> tun_build_skb drivers/net/tun.c:1686 [inline]<br /> tun_get_user+0xe0a/0x66e0 drivers/net/tun.c:1826<br /> tun_chr_write_iter+0x3af/0x5d0 drivers/net/tun.c:2055<br /> call_write_iter include/linux/fs.h:2087 [inline]<br /> new_sync_write fs/read_write.c:497 [inline]<br /> vfs_write+0xb6b/0x1520 fs/read_write.c:590<br /> ksys_write+0x20f/0x4c0 fs/read_write.c:643<br /> __do_sys_write fs/read_write.c:655 [inline]<br /> __se_sys_write fs/read_write.c:652 [inline]<br /> __x64_sys_write+0x93/0xd0 fs/read_write.c:652<br /> do_syscall_x64 arch/x86/entry/common.c:52 [inline]<br /> do_syscall_64+0xcf/0x1e0 arch/x86/entry/common.c:83<br /> entry_SYSCALL_64_after_hwframe+0x63/0x6b

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> bpf: Fix stackmap overflow check on 32-bit arches<br /> <br /> The stackmap code relies on roundup_pow_of_two() to compute the number<br /> of hash buckets, and contains an overflow check by checking if the<br /> resulting value is 0. However, on 32-bit arches, the roundup code itself<br /> can overflow by doing a 32-bit left-shift of an unsigned long value,<br /> which is undefined behaviour, so it is not guaranteed to truncate<br /> neatly. This was triggered by syzbot on the DEVMAP_HASH type, which<br /> contains the same check, copied from the hashtab code.<br /> <br /> The commit in the fixes tag actually attempted to fix this, but the fix<br /> did not account for the UB, so the fix only works on CPUs where an<br /> overflow does result in a neat truncation to zero, which is not<br /> guaranteed. Checking the value before rounding does not have this<br /> problem.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> bpf: Fix hashtab overflow check on 32-bit arches<br /> <br /> The hashtab code relies on roundup_pow_of_two() to compute the number of<br /> hash buckets, and contains an overflow check by checking if the<br /> resulting value is 0. However, on 32-bit arches, the roundup code itself<br /> can overflow by doing a 32-bit left-shift of an unsigned long value,<br /> which is undefined behaviour, so it is not guaranteed to truncate<br /> neatly. This was triggered by syzbot on the DEVMAP_HASH type, which<br /> contains the same check, copied from the hashtab code. So apply the same<br /> fix to hashtab, by moving the overflow check to before the roundup.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> bpf: Fix DEVMAP_HASH overflow check on 32-bit arches<br /> <br /> The devmap code allocates a number hash buckets equal to the next power<br /> of two of the max_entries value provided when creating the map. When<br /> rounding up to the next power of two, the 32-bit variable storing the<br /> number of buckets can overflow, and the code checks for overflow by<br /> checking if the truncated 32-bit value is equal to 0. However, on 32-bit<br /> arches the rounding up itself can overflow mid-way through, because it<br /> ends up doing a left-shift of 32 bits on an unsigned long value. If the<br /> size of an unsigned long is four bytes, this is undefined behaviour, so<br /> there is no guarantee that we&amp;#39;ll end up with a nice and tidy 0-value at<br /> the end.<br /> <br /> Syzbot managed to turn this into a crash on arm32 by creating a<br /> DEVMAP_HASH with max_entries &gt; 0x80000000 and then trying to update it.<br /> Fix this by moving the overflow check to before the rounding up<br /> operation.