Total
11827 CVE
| CVE | Vendors | Products | Updated | CVSS v3.1 |
|---|---|---|---|---|
| CVE-2024-33031 | 1 Qualcomm | 32 Ar8035, Ar8035 Firmware, Fastconnect 7800 and 29 more | 2024-11-07 | 6.7 Medium |
| Memory corruption while processing the update SIM PB records request. | ||||
| CVE-2024-51529 | 1 Huawei | 2 Emui, Harmonyos | 2024-11-07 | 5.5 Medium |
| Data verification vulnerability in the battery module Impact: Successful exploitation of this vulnerability may affect function stability. | ||||
| CVE-2024-51530 | 1 Huawei | 2 Emui, Harmonyos | 2024-11-07 | 6.6 Medium |
| LaunchAnywhere vulnerability in the account module Impact: Successful exploitation of this vulnerability may affect service confidentiality. | ||||
| CVE-2024-51520 | 1 Huawei | 1 Harmonyos | 2024-11-07 | 5.5 Medium |
| Vulnerability of input parameters not being verified in the HDC module Impact: Successful exploitation of this vulnerability may affect availability. | ||||
| CVE-2024-23386 | 1 Qualcomm | 20 Fastconnect 6900, Fastconnect 6900 Firmware, Fastconnect 7800 and 17 more | 2024-11-07 | 6.7 Medium |
| memory corruption when WiFi display APIs are invoked with large random inputs. | ||||
| CVE-2024-51514 | 1 Huawei | 1 Harmonyos | 2024-11-07 | 5.3 Medium |
| Vulnerability of pop-up windows belonging to no app in the VPN module Impact: Successful exploitation of this vulnerability may affect service confidentiality. | ||||
| CVE-2021-47129 | 2024-11-07 | 4.6 Medium | ||
| In the Linux kernel, the following vulnerability has been resolved: netfilter: nft_ct: skip expectations for confirmed conntrack nft_ct_expect_obj_eval() calls nf_ct_ext_add() for a confirmed conntrack entry. However, nf_ct_ext_add() can only be called for !nf_ct_is_confirmed(). [ 1825.349056] WARNING: CPU: 0 PID: 1279 at net/netfilter/nf_conntrack_extend.c:48 nf_ct_xt_add+0x18e/0x1a0 [nf_conntrack] [ 1825.351391] RIP: 0010:nf_ct_ext_add+0x18e/0x1a0 [nf_conntrack] [ 1825.351493] Code: 41 5c 41 5d 41 5e 41 5f c3 41 bc 0a 00 00 00 e9 15 ff ff ff ba 09 00 00 00 31 f6 4c 89 ff e8 69 6c 3d e9 eb 96 45 31 ed eb cd <0f> 0b e9 b1 fe ff ff e8 86 79 14 e9 eb bf 0f 1f 40 00 0f 1f 44 00 [ 1825.351721] RSP: 0018:ffffc90002e1f1e8 EFLAGS: 00010202 [ 1825.351790] RAX: 000000000000000e RBX: ffff88814f5783c0 RCX: ffffffffc0e4f887 [ 1825.351881] RDX: dffffc0000000000 RSI: 0000000000000008 RDI: ffff88814f578440 [ 1825.351971] RBP: 0000000000000000 R08: 0000000000000000 R09: ffff88814f578447 [ 1825.352060] R10: ffffed1029eaf088 R11: 0000000000000001 R12: ffff88814f578440 [ 1825.352150] R13: ffff8882053f3a00 R14: 0000000000000000 R15: 0000000000000a20 [ 1825.352240] FS: 00007f992261c900(0000) GS:ffff889faec00000(0000) knlGS:0000000000000000 [ 1825.352343] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 1825.352417] CR2: 000056070a4d1158 CR3: 000000015efe0000 CR4: 0000000000350ee0 [ 1825.352508] Call Trace: [ 1825.352544] nf_ct_helper_ext_add+0x10/0x60 [nf_conntrack] [ 1825.352641] nft_ct_expect_obj_eval+0x1b8/0x1e0 [nft_ct] [ 1825.352716] nft_do_chain+0x232/0x850 [nf_tables] Add the ct helper extension only for unconfirmed conntrack. Skip rule evaluation if the ct helper extension does not exist. Thus, you can only create expectations from the first packet. It should be possible to remove this limitation by adding a new action to attach a generic ct helper to the first packet. Then, use this ct helper extension from follow up packets to create the ct expectation. While at it, add a missing check to skip the template conntrack too and remove check for IPCT_UNTRACK which is implicit to !ct. | ||||
| CVE-2023-25520 | 1 Nvidia | 5 Jetson Agx Xavier, Jetson Linux, Jetson Tx2 and 2 more | 2024-11-07 | 4.4 Medium |
| NVIDIA Jetson Linux Driver Package contains a vulnerability in nvbootctrl, where a privileged local attacker can configure invalid settings, resulting in denial of service. | ||||
| CVE-2023-52597 | 1 Redhat | 1 Enterprise Linux | 2024-11-07 | 4 Medium |
| In the Linux kernel, the following vulnerability has been resolved: KVM: s390: fix setting of fpc register kvm_arch_vcpu_ioctl_set_fpu() allows to set the floating point control (fpc) register of a guest cpu. The new value is tested for validity by temporarily loading it into the fpc register. This may lead to corruption of the fpc register of the host process: if an interrupt happens while the value is temporarily loaded into the fpc register, and within interrupt context floating point or vector registers are used, the current fp/vx registers are saved with save_fpu_regs() assuming they belong to user space and will be loaded into fp/vx registers when returning to user space. test_fp_ctl() restores the original user space / host process fpc register value, however it will be discarded, when returning to user space. In result the host process will incorrectly continue to run with the value that was supposed to be used for a guest cpu. Fix this by simply removing the test. There is another test right before the SIE context is entered which will handles invalid values. This results in a change of behaviour: invalid values will now be accepted instead of that the ioctl fails with -EINVAL. This seems to be acceptable, given that this interface is most likely not used anymore, and this is in addition the same behaviour implemented with the memory mapped interface (replace invalid values with zero) - see sync_regs() in kvm-s390.c. | ||||
| CVE-2024-36908 | 2024-11-07 | 7.1 High | ||
| In the Linux kernel, the following vulnerability has been resolved: blk-iocost: do not WARN if iocg was already offlined In iocg_pay_debt(), warn is triggered if 'active_list' is empty, which is intended to confirm iocg is active when it has debt. However, warn can be triggered during a blkcg or disk removal, if iocg_waitq_timer_fn() is run at that time: WARNING: CPU: 0 PID: 2344971 at block/blk-iocost.c:1402 iocg_pay_debt+0x14c/0x190 Call trace: iocg_pay_debt+0x14c/0x190 iocg_kick_waitq+0x438/0x4c0 iocg_waitq_timer_fn+0xd8/0x130 __run_hrtimer+0x144/0x45c __hrtimer_run_queues+0x16c/0x244 hrtimer_interrupt+0x2cc/0x7b0 The warn in this situation is meaningless. Since this iocg is being removed, the state of the 'active_list' is irrelevant, and 'waitq_timer' is canceled after removing 'active_list' in ioc_pd_free(), which ensures iocg is freed after iocg_waitq_timer_fn() returns. Therefore, add the check if iocg was already offlined to avoid warn when removing a blkcg or disk. | ||||
| CVE-2024-51512 | 1 Huawei | 1 Harmonyos | 2024-11-07 | 6.2 Medium |
| Vulnerability of parameter type not being verified in the WantAgent module Impact: Successful exploitation of this vulnerability may affect availability. | ||||
| CVE-2024-51511 | 1 Huawei | 1 Harmonyos | 2024-11-07 | 6.2 Medium |
| Vulnerability of parameter type not being verified in the WantAgent module Impact: Successful exploitation of this vulnerability may affect availability. | ||||
| CVE-2023-45290 | 1 Redhat | 19 Advanced Cluster Security, Ansible Automation Platform, Cryostat and 16 more | 2024-11-07 | 6.5 Medium |
| When parsing a multipart form (either explicitly with Request.ParseMultipartForm or implicitly with Request.FormValue, Request.PostFormValue, or Request.FormFile), limits on the total size of the parsed form were not applied to the memory consumed while reading a single form line. This permits a maliciously crafted input containing very long lines to cause allocation of arbitrarily large amounts of memory, potentially leading to memory exhaustion. With fix, the ParseMultipartForm function now correctly limits the maximum size of form lines. | ||||
| CVE-2024-51519 | 1 Huawei | 1 Harmonyos | 2024-11-06 | 5 Medium |
| Vulnerability of input parameters not being verified in the HDC module Impact: Successful exploitation of this vulnerability may affect availability. | ||||
| CVE-2023-26273 | 2 Ibm, Linux | 2 Qradar Security Information And Event Manager, Linux Kernel | 2024-11-06 | 4.3 Medium |
| IBM QRadar SIEM 7.5.0 could allow an authenticated user to perform unauthorized actions due to hazardous input validation. IBM X-Force ID: 248134. | ||||
| CVE-2023-34421 | 1 Lenovo | 1 Xclarity Administrator | 2024-11-06 | 6.5 Medium |
| A valid, authenticated LXCA user with elevated privileges may be able to replace filesystem data through a specifically crafted web API call due to insufficient input validation. | ||||
| CVE-2023-34422 | 1 Lenovo | 1 Xclarity Administrator | 2024-11-06 | 6.5 Medium |
| A valid, authenticated LXCA user with elevated privileges may be able to delete folders in the LXCA filesystem through a specifically crafted web API call due to insufficient input validation. | ||||
| CVE-2024-5642 | 2024-11-06 | 6.5 Medium | ||
| CPython 3.9 and earlier doesn't disallow configuring an empty list ("[]") for SSLContext.set_npn_protocols() which is an invalid value for the underlying OpenSSL API. This results in a buffer over-read when NPN is used (see CVE-2024-5535 for OpenSSL). This vulnerability is of low severity due to NPN being not widely used and specifying an empty list likely being uncommon in-practice (typically a protocol name would be configured). | ||||
| CVE-2024-26757 | 1 Redhat | 1 Enterprise Linux | 2024-11-06 | 5.5 Medium |
| In the Linux kernel, the following vulnerability has been resolved: md: Don't ignore read-only array in md_check_recovery() Usually if the array is not read-write, md_check_recovery() won't register new sync_thread in the first place. And if the array is read-write and sync_thread is registered, md_set_readonly() will unregister sync_thread before setting the array read-only. md/raid follow this behavior hence there is no problem. After commit f52f5c71f3d4 ("md: fix stopping sync thread"), following hang can be triggered by test shell/integrity-caching.sh: 1) array is read-only. dm-raid update super block: rs_update_sbs ro = mddev->ro mddev->ro = 0 -> set array read-write md_update_sb 2) register new sync thread concurrently. 3) dm-raid set array back to read-only: rs_update_sbs mddev->ro = ro 4) stop the array: raid_dtr md_stop stop_sync_thread set_bit(MD_RECOVERY_INTR, &mddev->recovery); md_wakeup_thread_directly(mddev->sync_thread); wait_event(..., !test_bit(MD_RECOVERY_RUNNING, &mddev->recovery)) 5) sync thread done: md_do_sync set_bit(MD_RECOVERY_DONE, &mddev->recovery); md_wakeup_thread(mddev->thread); 6) daemon thread can't unregister sync thread: md_check_recovery if (!md_is_rdwr(mddev) && !test_bit(MD_RECOVERY_NEEDED, &mddev->recovery)) return; -> -> MD_RECOVERY_RUNNING can't be cleared, hence step 4 hang; The root cause is that dm-raid manipulate 'mddev->ro' by itself, however, dm-raid really should stop sync thread before setting the array read-only. Unfortunately, I need to read more code before I can refacter the handler of 'mddev->ro' in dm-raid, hence let's fix the problem the easy way for now to prevent dm-raid regression. | ||||
| CVE-2023-52522 | 1 Redhat | 5 Enterprise Linux, Rhel Aus, Rhel E4s and 2 more | 2024-11-06 | 5.5 Medium |
| In the Linux kernel, the following vulnerability has been resolved: net: fix possible store tearing in neigh_periodic_work() While looking at a related syzbot report involving neigh_periodic_work(), I found that I forgot to add an annotation when deleting an RCU protected item from a list. Readers use rcu_deference(*np), we need to use either rcu_assign_pointer() or WRITE_ONCE() on writer side to prevent store tearing. I use rcu_assign_pointer() to have lockdep support, this was the choice made in neigh_flush_dev(). | ||||