Dunateo/VulnDesc_CWE_Mapping huggingface dataset:
In the Linux kernel, the following vulnerability has been resolved:net: marvell: prestera: fix port event handling on initFor some reason there might be a crash during ports creation if portevents are handling at the same time  because fw may send initialport event with down state.The crash points to cancel_delayed_work() which is called when port wentis down.  Currently I did not find out the real cause of the issue, sofixed it by cancel port stats work only if previous port's state was up& runnig.The following is the crash which can be triggered:[   28.311104] Unable to handle kernel paging request at virtual address000071775f776600[   28.319097] Mem abort info:[   28.321914]   ESR = 0x96000004[   28.324996]   EC = 0x25: DABT (current EL), IL = 32 bits[   28.330350]   SET = 0, FnV = 0[   28.333430]   EA = 0, S1PTW = 0[   28.336597] Data abort info:[   28.339499]   ISV = 0, ISS = 0x00000004[   28.343362]   CM = 0, WnR = 0[   28.346354] user pgtable: 4k pages, 48-bit VAs, pgdp=0000000100bf7000[   28.352842] [000071775f776600] pgd=0000000000000000,p4d=0000000000000000[   28.359695] Internal error: Oops: 96000004 [#1] PREEMPT SMP[   28.365310] Modules linked in: prestera_pci(+) presterauio_pdrv_genirq[   28.372005] CPU: 0 PID: 1291 Comm: kworker/0:1H Not tainted5.11.0-rc4 #1[   28.378846] Hardware name: DNI AmazonGo1 A7040 board (DT)[   28.384283] Workqueue: prestera_fw_wq prestera_fw_evt_work_fn[prestera_pci][   28.391413] pstate: 60000085 (nZCv daIf -PAN -UAO -TCO BTYPE=--)[   28.397468] pc : get_work_pool+0x48/0x60[   28.401442] lr : try_to_grab_pending+0x6c/0x1b0[   28.406018] sp : ffff80001391bc60[   28.409358] x29: ffff80001391bc60 x28: 0000000000000000[   28.414725] x27: ffff000104fc8b40 x26: ffff80001127de88[   28.420089] x25: 0000000000000000 x24: ffff000106119760[   28.425452] x23: ffff00010775dd60 x22: ffff00010567e000[   28.430814] x21: 0000000000000000 x20: ffff80001391bcb0[   28.436175] x19: ffff00010775deb8 x18: 00000000000000c0[   28.441537] x17: 0000000000000000 x16: 000000008d9b0e88[   28.446898] x15: 0000000000000001 x14: 00000000000002ba[   28.452261] x13: 80a3002c00000002 x12: 00000000000005f4[   28.457622] x11: 0000000000000030 x10: 000000000000000c[   28.462985] x9 : 000000000000000c x8 : 0000000000000030[   28.468346] x7 : ffff800014400000 x6 : ffff000106119758[   28.473708] x5 : 0000000000000003 x4 : ffff00010775dc60[   28.479068] x3 : 0000000000000000 x2 : 0000000000000060[   28.484429] x1 : 000071775f776600 x0 : ffff00010775deb8[   28.489791] Call trace:[   28.492259]  get_work_pool+0x48/0x60[   28.495874]  cancel_delayed_work+0x38/0xb0[   28.500011]  prestera_port_handle_event+0x90/0xa0 [prestera][   28.505743]  prestera_evt_recv+0x98/0xe0 [prestera][   28.510683]  prestera_fw_evt_work_fn+0x180/0x228 [prestera_pci][   28.516660]  process_one_work+0x1e8/0x360[   28.520710]  worker_thread+0x44/0x480[   28.524412]  kthread+0x154/0x160[   28.527670]  ret_from_fork+0x10/0x38[   28.531290] Code: a8c17bfd d50323bf d65f03c0 9278dc21 (f9400020)[   28.537429] ---[ end trace 5eced933df3a080b ]---
Weakness: CWE-400 Uncontrolled Resource Consumption
In the Linux kernel, the following vulnerability has been resolved:virtio-net: fix pages leaking when building skb in big modeWe try to use build_skb() if we had sufficient tailroom. But we forgetto release the unused pages chained via private in big mode which willleak pages. Fixing this by release the pages after building the skb inbig mode.
Weakness: CWE-119 Improper Restriction of Operations within the Bounds of a Memory Buffer
In the Linux kernel, the following vulnerability has been resolved:riscv, bpf: Fix potential NULL dereferenceThe bpf_jit_binary_free() function requires a non-NULL argument. Whenthe RISC-V BPF JIT fails to converge in NR_JIT_ITERATIONS steps,jit_data->header will be NULL, which triggers a NULLdereference. Avoid this by checking the argument, prior calling thefunction.
Weakness: CWE-476 NULL Pointer Dereference
In the Linux kernel, the following vulnerability has been resolved:net: ipv4: fix memory leak in ip_mc_add1_srcBUG: memory leakunreferenced object 0xffff888101bc4c00 (size 32):  comm "syz-executor527", pid 360, jiffies 4294807421 (age 19.329s)  hex dump (first 32 bytes):    00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................    01 00 00 00 00 00 00 00 ac 14 14 bb 00 00 02 00 ................  backtrace:    [<00000000f17c5244>] kmalloc include/linux/slab.h:558 [inline]    [<00000000f17c5244>] kzalloc include/linux/slab.h:688 [inline]    [<00000000f17c5244>] ip_mc_add1_src net/ipv4/igmp.c:1971 [inline]    [<00000000f17c5244>] ip_mc_add_src+0x95f/0xdb0 net/ipv4/igmp.c:2095    [<000000001cb99709>] ip_mc_source+0x84c/0xea0 net/ipv4/igmp.c:2416    [<0000000052cf19ed>] do_ip_setsockopt net/ipv4/ip_sockglue.c:1294 [inline]    [<0000000052cf19ed>] ip_setsockopt+0x114b/0x30c0 net/ipv4/ip_sockglue.c:1423    [<00000000477edfbc>] raw_setsockopt+0x13d/0x170 net/ipv4/raw.c:857    [<00000000e75ca9bb>] __sys_setsockopt+0x158/0x270 net/socket.c:2117    [<00000000bdb993a8>] __do_sys_setsockopt net/socket.c:2128 [inline]    [<00000000bdb993a8>] __se_sys_setsockopt net/socket.c:2125 [inline]    [<00000000bdb993a8>] __x64_sys_setsockopt+0xba/0x150 net/socket.c:2125    [<000000006a1ffdbd>] do_syscall_64+0x40/0x80 arch/x86/entry/common.c:47    [<00000000b11467c4>] entry_SYSCALL_64_after_hwframe+0x44/0xaeIn commit 24803f38a5c0 ("igmp: do not remove igmp souce list info when setlink down"), the ip_mc_clear_src() in ip_mc_destroy_dev() was removed,because it was also called in igmpv3_clear_delrec().Rough callgraph:inetdev_destroy-> ip_mc_destroy_dev     -> igmpv3_clear_delrec        -> ip_mc_clear_src-> RCU_INIT_POINTER(dev->ip_ptr, NULL)However, ip_mc_clear_src() called in igmpv3_clear_delrec() doesn'trelease in_dev->mc_list->sources. And RCU_INIT_POINTER() assigns theNULL to dev->ip_ptr. As a result, in_dev cannot be obtained throughinetdev_by_index() and then in_dev->mc_list->sources cannot be releasedby ip_mc_del1_src() in the sock_close. Rough call sequence goes like:sock_close-> __sock_release   -> inet_release      -> ip_mc_drop_socket         -> inetdev_by_index         -> ip_mc_leave_src            -> ip_mc_del_src               -> ip_mc_del1_srcSo we still need to call ip_mc_clear_src() in ip_mc_destroy_dev() to freein_dev->mc_list->sources.
Weakness: CWE-400 Uncontrolled Resource Consumption
In the Linux kernel, the following vulnerability has been resolved:cpufreq: CPPC: Fix potential memleak in cppc_cpufreq_cpu_initIt's a classic example of memleak, we allocate something, we fail andnever free the resources.Make sure we free all resources on policy ->init() failures.
Weakness: CWE-400 Uncontrolled Resource Consumption
In the Linux kernel, the following vulnerability has been resolved:tipc: check for null after calling kmemdupkmemdup can return a null pointer so need to check for it, otherwisethe null key will be dereferenced later in tipc_crypto_key_xmit ascan be seen in the trace [1].[1] https://syzkaller.appspot.com/bug?id=bca180abb29567b189efdbdb34cbf7ba851c2a58
Weakness: CWE-690 Unchecked Return Value to NULL Pointer Dereference
In the Linux kernel, the following vulnerability has been resolved:scsi: megaraid_sas: Fix resource leak in case of probe failureThe driver doesn't clean up all the allocated resources properly whenscsi_add_host(), megasas_start_aen() function fails during the PCI deviceprobe.Clean up all those resources.
Weakness: CWE-400 Uncontrolled Resource Consumption
In the Linux kernel, the following vulnerability has been resolved:enetc: Fix illegal access when reading affinity_hintirq_set_affinity_hit() stores a reference to the cpumask_tparameter in the irq descriptor, and that reference can beaccessed later from irq_affinity_hint_proc_show(). Sincethe cpu_mask parameter passed to irq_set_affinity_hit() hasonly temporary storage (it's on the stack memory), lateraccesses to it are illegal. Thus reads from the correspondingprocfs affinity_hint file can result in paging request oops.The issue is fixed by the get_cpu_mask() helper, which providesa permanent storage for the cpumask_t parameter.
Weakness: CWE-400 Uncontrolled Resource Consumption
In the Linux kernel, the following vulnerability has been resolved:scsi: pm80xx: Do not call scsi_remove_host() in pm8001_alloc()Calling scsi_remove_host() before scsi_add_host() results in a crash: BUG: kernel NULL pointer dereference, address: 0000000000000108 RIP: 0010:device_del+0x63/0x440 Call Trace:  device_unregister+0x17/0x60  scsi_remove_host+0xee/0x2a0  pm8001_pci_probe+0x6ef/0x1b90 [pm80xx]  local_pci_probe+0x3f/0x90We cannot call scsi_remove_host() in pm8001_alloc() because scsi_add_host()has not been called yet at that point in time.Function call tree:  pm8001_pci_probe()  |  `- pm8001_pci_alloc()  |  |  |  `- pm8001_alloc()  |     |  |     `- scsi_remove_host()  |  `- scsi_add_host()
Weakness: CWE-476 NULL Pointer Dereference
In the Linux kernel, the following vulnerability has been resolved:net: sched: fix memory leak in tcindex_partial_destroy_workSyzbot reported memory leak in tcindex_set_parms(). The problem was innon-freed perfect hash in tcindex_partial_destroy_work().In tcindex_set_parms() new tcindex_data is allocated and some fields fromold one are copied to new one, but not the perfect hash. Sincetcindex_partial_destroy_work() is the destroy function for oldtcindex_data, we need to free perfect hash to avoid memory leak.
Weakness: CWE-400 Uncontrolled Resource Consumption
In the Linux kernel, the following vulnerability has been resolved:drm/amd/display: Avoid HDCP over-read and corruptionInstead of reading the desired 5 bytes of the actual target field,the code was reading 8. This could result in a corrupted value if thetrailing 3 bytes were non-zero, so instead use an appropriately sizedand zero-initialized bounce buffer, and read only 5 bytes before castingto u64.
Weakness: CWE-119 Improper Restriction of Operations within the Bounds of a Memory Buffer
In the Linux kernel, the following vulnerability has been resolved:can: m_can: m_can_read_fifo: fix memory leak in error branchIn m_can_read_fifo(), if the second call to m_can_fifo_read() fails,the function jump to the out_fail label and returns without callingm_can_receive_skb(). This means that the skb previously allocated byalloc_can_skb() is not freed. In other terms, this is a memory leak.This patch adds a goto label to destroy the skb if an error occurs.Issue was found with GCC -fanalyzer, please follow the link below fordetails.
Weakness: CWE-401 Missing Release of Memory after Effective Lifetime
In the Linux kernel, the following vulnerability has been resolved:watchdog: Fix possible use-after-free in wdt_startup()This module's remove path calls del_timer(). However, that functiondoes not wait until the timer handler finishes. This means that thetimer handler may still be running after the driver's remove functionhas finished, which would result in a use-after-free.Fix by calling del_timer_sync(), which makes sure the timer handlerhas finished, and unable to re-schedule itself.
Weakness: CWE-416 Use After Free
In the Linux kernel, the following vulnerability has been resolved:s390/qeth: fix NULL deref in qeth_clear_working_pool_list()When qeth_set_online() calls qeth_clear_working_pool_list() to rollback after an error exit from qeth_hardsetup_card(), we are at risk ofaccessing card->qdio.in_q before it was allocated byqeth_alloc_qdio_queues() via qeth_mpc_initialize().qeth_clear_working_pool_list() then dereferences NULL, and by writing toqueue->bufs[i].pool_entry scribbles all over the CPU's lowcore.Resulting in a crash when those lowcore areas are used next (eg. onthe next machine-check interrupt).Such a scenario would typically happen when the device is first setonline and its queues aren't allocated yet. An early IO error or certainmisconfigs (eg. mismatched transport mode, bad portno) then cause us toerror out from qeth_hardsetup_card() with card->qdio.in_q still beingNULL.Fix it by checking the pointer for NULL before accessing it.Note that we also have (rare) paths inside qeth_mpc_initialize() wherea configuration change can cause us to free the existing queues,expecting that subsequent code will allocate them again. If we thenerror out before that re-allocation happens, the same bug occurs.Root-caused-by: Heiko Carstens <hca@linux.ibm.com>
Weakness: CWE-476 NULL Pointer Dereference
In the Linux kernel, the following vulnerability has been resolved:comedi: ni_usb6501: fix NULL-deref in command pathsThe driver uses endpoint-sized USB transfer buffers but had no sanitychecks on the sizes. This can lead to zero-size-pointer dereferences oroverflowed transfer buffers in ni6501_port_command() andni6501_counter_command() if a (malicious) device has smaller max-packetsizes than expected (or when doing descriptor fuzz testing).Add the missing sanity checks to probe().
Weakness: CWE-476 NULL Pointer Dereference
In the Linux kernel, the following vulnerability has been resolved:watchdog: sc520_wdt: Fix possible use-after-free in wdt_turnoff()This module's remove path calls del_timer(). However, that functiondoes not wait until the timer handler finishes. This means that thetimer handler may still be running after the driver's remove functionhas finished, which would result in a use-after-free.Fix by calling del_timer_sync(), which makes sure the timer handlerhas finished, and unable to re-schedule itself.
Weakness: CWE-416 Use After Free
In the Linux kernel, the following vulnerability has been resolved:ethernet: hisilicon: hns: hns_dsaf_misc: fix a possible array overflow in hns_dsaf_ge_srst_by_port()The if statement:  if (port >= DSAF_GE_NUM)        return
Weakness: CWE-129: Improper Validation of Array Index
In the Linux kernel, the following vulnerability has been resolved:drm/sched: Avoid data corruptionsWait for all dependencies of a job  to complete beforekilling it to avoid data corruptions.
Weakness: CWE-787 Out-of-bounds Write
In the Linux kernel, the following vulnerability has been resolved:can: peak_pci: peak_pci_remove(): fix UAFWhen remove the module peek_pci, referencing 'chan' again afterreleasing 'dev' will cause UAF.Fix this by releasing 'dev' later.The following log reveals it:[   35.961814 ] BUG: KASAN: use-after-free in peak_pci_remove+0x16f/0x270 [peak_pci][   35.963414 ] Read of size 8 at addr ffff888136998ee8 by task modprobe/5537[   35.965513 ] Call Trace:[   35.965718 ]  dump_stack_lvl+0xa8/0xd1[   35.966028 ]  print_address_description+0x87/0x3b0[   35.966420 ]  kasan_report+0x172/0x1c0[   35.966725 ]  ? peak_pci_remove+0x16f/0x270 [peak_pci][   35.967137 ]  ? trace_irq_enable_rcuidle+0x10/0x170[   35.967529 ]  ? peak_pci_remove+0x16f/0x270 [peak_pci][   35.967945 ]  __asan_report_load8_noabort+0x14/0x20[   35.968346 ]  peak_pci_remove+0x16f/0x270 [peak_pci][   35.968752 ]  pci_device_remove+0xa9/0x250
Weakness: CWE-416 Use After Free
In the Linux kernel, the following vulnerability has been resolved:nvme-rdma: destroy cm id before destroy qp to avoid use after freeWe should always destroy cm_id before destroy qp to avoid to get cmaevent after qp was destroyed, which may lead to use after free.In RDMA connection establishment error flow, don't destroy qp in cmevent handler.Just report cm_error to upper level, qp will be destroyin nvme_rdma_alloc_queue() after destroy cm id.
Weakness: CWE-416 Use After Free
In the Linux kernel, the following vulnerability has been resolved:net: stmmac: dwmac-rk: fix oob read in rk_gmac_setupKASAN reports an out-of-bounds read in rk_gmac_setup on the line:
Weakness: CWE-125 Out-of-bounds Read
In the Linux kernel, the following vulnerability has been resolved:KVM: x86: Immediately reset the MMU context when the SMM flag is clearedImmediately reset the MMU context when the vCPU's SMM flag is cleared sothat the SMM flag in the MMU role is always synchronized with the vCPU'sflag.  If RSM fails (which isn't correctly emulated), KVM will bailwithout calling post_leave_smm() and leave the MMU in a bad state.The bad MMU role can lead to a NULL pointer dereference when grabbing ashadow page's rmap for a page fault as the initial lookups for the gfnwill happen with the vCPU's SMM flag (=0), whereas the rmap lookup willuse the shadow page's SMM flag, which comes from the MMU (=1).  SMM hasan entirely different set of memslots, and so the initial lookup can finda memslot (SMM=0) and then explode on the rmap memslot lookup (SMM=1).  general protection fault, probably for non-canonical address 0xdffffc0000000000: 0000 [#1] PREEMPT SMP KASAN  KASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007]  CPU: 1 PID: 8410 Comm: syz-executor382 Not tainted 5.13.0-rc5-syzkaller #0  Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011  RIP: 0010:__gfn_to_rmap arch/x86/kvm/mmu/mmu.c:935 [inline]  RIP: 0010:gfn_to_rmap+0x2b0/0x4d0 arch/x86/kvm/mmu/mmu.c:947  Code: <42> 80 3c 20 00 74 08 4c 89 ff e8 f1 79 a9 00 4c 89 fb 4d 8b 37 44  RSP: 0018:ffffc90000ffef98 EFLAGS: 00010246  RAX: 0000000000000000 RBX: ffff888015b9f414 RCX: ffff888019669c40  RDX: 0000000000000000 RSI: 0000000000000001 RDI: 0000000000000001  RBP: 0000000000000001 R08: ffffffff811d9cdb R09: ffffed10065a6002  R10: ffffed10065a6002 R11: 0000000000000000 R12: dffffc0000000000  R13: 0000000000000003 R14: 0000000000000001 R15: 0000000000000000  FS:  000000000124b300(0000) GS:ffff8880b9b00000(0000) knlGS:0000000000000000  CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033  CR2: 0000000000000000 CR3: 0000000028e31000 CR4: 00000000001526e0  DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000  DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400  Call Trace:   rmap_add arch/x86/kvm/mmu/mmu.c:965 [inline]   mmu_set_spte+0x862/0xe60 arch/x86/kvm/mmu/mmu.c:2604   __direct_map arch/x86/kvm/mmu/mmu.c:2862 [inline]   direct_page_fault+0x1f74/0x2b70 arch/x86/kvm/mmu/mmu.c:3769   kvm_mmu_do_page_fault arch/x86/kvm/mmu.h:124 [inline]   kvm_mmu_page_fault+0x199/0x1440 arch/x86/kvm/mmu/mmu.c:5065   vmx_handle_exit+0x26/0x160 arch/x86/kvm/vmx/vmx.c:6122   vcpu_enter_guest+0x3bdd/0x9630 arch/x86/kvm/x86.c:9428   vcpu_run+0x416/0xc20 arch/x86/kvm/x86.c:9494   kvm_arch_vcpu_ioctl_run+0x4e8/0xa40 arch/x86/kvm/x86.c:9722   kvm_vcpu_ioctl+0x70f/0xbb0 arch/x86/kvm/../../../virt/kvm/kvm_main.c:3460   vfs_ioctl fs/ioctl.c:51 [inline]   __do_sys_ioctl fs/ioctl.c:1069 [inline]   __se_sys_ioctl+0xfb/0x170 fs/ioctl.c:1055   do_syscall_64+0x3f/0xb0 arch/x86/entry/common.c:47   entry_SYSCALL_64_after_hwframe+0x44/0xae  RIP: 0033:0x440ce9
Weakness: CWE-476 NULL Pointer Dereference
Improper DLL loading algorithms in B&R Automation Studio versions >=4.0 and <4.12 may allow an authenticated local attacker to execute code in the context of the product.
Weakness: CWE-20 Improper Input Validation
D-Link DVG-3104MS version 1.0.2.0.3, 1.0.2.0.4, and 1.0.2.0.4E contains hard-coded credentials for undocumented user accounts in the '/etc/passwd' file. As weak passwords have been used, the plaintext passwords can be recovered from the hash values. NOTE: This vulnerability only affects products that are no longer supported by the maintainer
Weakness: CWE-798 Use of Hard-coded Credentials
Cross-Site Request Forgery (CSRF) vulnerability in the terms of use page in Liferay Portal before 7.3.6, and Liferay DXP 7.3 before service pack 1, 7.2 before fix pack 11 allows remote attackers to accept the site's terms of use via social engineering and enticing the user to visit a malicious page.
Weakness: CWE-352 Cross-Site Request Forgery (CSRF)
Insufficient validation of untrusted input in Intents in Google Chrome on Android prior to 95.0.4638.69 allowed a remote attacker to arbitrarily browser to a malicious URL via a crafted HTML page.
Weakness: CWE-20 Improper Input Validation
Polipo through 1.1.1, when NDEBUG is used, allows a heap-based buffer overflow during parsing of a Range header. NOTE: This vulnerability only affects products that are no longer supported by the maintainer
Weakness: CWE-787 Out-of-bounds Write
CA eHealth Performance Manager through 6.3.2.12 is affected by Privilege Escalation via a Dynamically Linked Shared Object Library. A regular user must create a malicious library in the writable RPATH, to be dynamically linked when the emtgtctl2 executable is run. The code in the library will be executed as the ehealth user. NOTE: This vulnerability only affects products that are no longer supported by the maintainer
Weakness: CWE-426 Untrusted Search Path
CA eHealth Performance Manager through 6.3.2.12 is affected by Improper Restriction of Excessive Authentication Attempts. An attacker is able to perform an arbitrary number of /web/frames/ authentication attempts using different passwords, and eventually gain access to a targeted account, NOTE: This vulnerability only affects products that are no longer supported by the maintainer
Weakness: CWE-307 Improper Restriction of Excessive Authentication Attempts
The Arm Mali GPU kernel driver allows privilege escalation or information disclosure because GPU memory operations are mishandled, leading to a use-after-free. This affects Bifrost r0p0 through r28p0 before r29p0, Valhall r19p0 through r28p0 before r29p0, and Midgard r4p0 through r30p0.
Weakness: CWE-416 Use After Free
In Solstice Pod before 3.0.3, the firmware can easily be decompiled/disassembled. The decompiled/disassembled files contain non-obfuscated code. NOTE: it is unclear whether lack of obfuscation is directly associated with a negative impact, or instead only facilitates an attack technique
Weakness: CWE-311 Missing Encryption of Sensitive Data
The server in Circontrol Raption through 5.11.2 has a pre-authentication stack-based buffer overflow that can be exploited to gain run-time control of the device as root. The ocpp1.5 and pwrstudio binaries on the charging station do not use a number of common exploitation mitigations. In particular, there are no stack canaries and they do not use the Position Independent Executable (PIE) format.
Weakness: CWE-121 Stack-based Buffer Overflow
An issue was discovered in the failure crate through 0.1.5 for Rust. It may introduce "compatibility hazards" in some applications, and has a type confusion flaw when downcasting. NOTE: This vulnerability only affects products that are no longer supported by the maintainer. NOTE: This may overlap CVE-2019-25010
Weakness: CWE-843 Access of Resource Using Incompatible Type ('Type Confusion')
airhost.exe in Zoom Client for Meetings 4.6.11 uses the SHA-256 hash of 0123425234234fsdfsdr3242 for initialization of an OpenSSL EVP AES-256 CBC context. NOTE: the vendor states that this initialization only occurs within unreachable code
Weakness: CWE-327 Use of a Broken or Risky Cryptographic Algorithm
An issue was discovered in Luvion Grand Elite 3 Connect through 2020-02-25. Authentication to the device is based on a username and password. The root credentials are the same across all devices of this model.
Weakness: CWE-521 Weak Password Requirements
airhost.exe in Zoom Client for Meetings 4.6.11 uses 3423423432325249 as the Initialization Vector (IV) for AES-256 CBC encryption. NOTE: the vendor states that this IV is used only within unreachable code
Weakness: CWE-330 Use of Insufficiently Random Values
FasterXML jackson-databind 2.x before 2.9.10.4 mishandles the interaction between serialization gadgets and typing, related to org.apache.commons.proxy.provider.remoting.RmiProvider (aka apache/commons-proxy).
Weakness: CWE-502 Deserialization of Untrusted Data
An issue was discovered in Svakom Siime Eye 14.1.00000001.3.330.0.0.3.14. By sending a set_params.cgi?telnetd=1&save=1&reboot=1 request to the webserver, it is possible to enable the telnet interface on the device. The telnet interface can then be used to obtain access to the device with root privileges via a reecam4debug default password. This default telnet password is the same across all Siime Eye devices. In order for the attack to be exploited, an attacker must be physically close in order to connect to the device's Wi-Fi access point.
Weakness: CWE-1188 Insecure Default Initialization of Resource