Total
32233 CVE
| CVE | Vendors | Products | Updated | CVSS v2 | CVSS v3 |
|---|---|---|---|---|---|
| CVE-2023-23603 | 1 Mozilla | 3 Firefox, Firefox Esr, Thunderbird | 2025-01-10 | N/A | 6.5 MEDIUM |
| Regular expressions used to filter out forbidden properties and values from style directives in calls to <code>console.log</code> weren't accounting for external URLs. Data could then be potentially exfiltrated from the browser. This vulnerability affects Firefox < 109, Thunderbird < 102.7, and Firefox ESR < 102.7. | |||||
| CVE-2022-45853 | 1 Zyxel | 20 Gs1900-10hp, Gs1900-10hp Firmware, Gs1900-16 and 17 more | 2025-01-10 | N/A | 6.7 MEDIUM |
| The privilege escalation vulnerability in the Zyxel GS1900-8 firmware version V2.70(AAHH.3) and the GS1900-8HP firmware version V2.70(AAHI.3) could allow an authenticated, local attacker with administrator privileges to execute some system commands as 'root' on a vulnerable device via SSH. | |||||
| CVE-2023-33105 | 1 Qualcomm | 298 Ar8035, Ar8035 Firmware, Ar9380 and 295 more | 2025-01-10 | N/A | 7.5 HIGH |
| Transient DOS in WLAN Host and Firmware when large number of open authentication frames are sent with an invalid transaction sequence number. | |||||
| CVE-2023-33103 | 1 Qualcomm | 96 Ar8035, Ar8035 Firmware, Fastconnect 6700 and 93 more | 2025-01-10 | N/A | 7.5 HIGH |
| Transient DOS while processing CAG info IE received from NW. | |||||
| CVE-2024-56717 | 1 Linux | 1 Linux Kernel | 2025-01-10 | N/A | 5.5 MEDIUM |
| In the Linux kernel, the following vulnerability has been resolved: net: mscc: ocelot: fix incorrect IFH SRC_PORT field in ocelot_ifh_set_basic() Packets injected by the CPU should have a SRC_PORT field equal to the CPU port module index in the Analyzer block (ocelot->num_phys_ports). The blamed commit copied the ocelot_ifh_set_basic() call incorrectly from ocelot_xmit_common() in net/dsa/tag_ocelot.c. Instead of calling with "x", it calls with BIT_ULL(x), but the field is not a port mask, but rather a single port index. [ side note: this is the technical debt of code duplication :( ] The error used to be silent and doesn't appear to have other user-visible manifestations, but with new changes in the packing library, it now fails loudly as follows: ------------[ cut here ]------------ Cannot store 0x40 inside bits 46-43 - will truncate sja1105 spi2.0: xmit timed out WARNING: CPU: 1 PID: 102 at lib/packing.c:98 __pack+0x90/0x198 sja1105 spi2.0: timed out polling for tstamp CPU: 1 UID: 0 PID: 102 Comm: felix_xmit Tainted: G W N 6.13.0-rc1-00372-gf706b85d972d-dirty #2605 Call trace: __pack+0x90/0x198 (P) __pack+0x90/0x198 (L) packing+0x78/0x98 ocelot_ifh_set_basic+0x260/0x368 ocelot_port_inject_frame+0xa8/0x250 felix_port_deferred_xmit+0x14c/0x258 kthread_worker_fn+0x134/0x350 kthread+0x114/0x138 The code path pertains to the ocelot switchdev driver and to the felix secondary DSA tag protocol, ocelot-8021q. Here seen with ocelot-8021q. The messenger (packing) is not really to blame, so fix the original commit instead. | |||||
| CVE-2024-56718 | 1 Linux | 1 Linux Kernel | 2025-01-10 | N/A | 5.5 MEDIUM |
| In the Linux kernel, the following vulnerability has been resolved: net/smc: protect link down work from execute after lgr freed link down work may be scheduled before lgr freed but execute after lgr freed, which may result in crash. So it is need to hold a reference before shedule link down work, and put the reference after work executed or canceled. The relevant crash call stack as follows: list_del corruption. prev->next should be ffffb638c9c0fe20, but was 0000000000000000 ------------[ cut here ]------------ kernel BUG at lib/list_debug.c:51! invalid opcode: 0000 [#1] SMP NOPTI CPU: 6 PID: 978112 Comm: kworker/6:119 Kdump: loaded Tainted: G #1 Hardware name: Alibaba Cloud Alibaba Cloud ECS, BIOS 2221b89 04/01/2014 Workqueue: events smc_link_down_work [smc] RIP: 0010:__list_del_entry_valid.cold+0x31/0x47 RSP: 0018:ffffb638c9c0fdd8 EFLAGS: 00010086 RAX: 0000000000000054 RBX: ffff942fb75e5128 RCX: 0000000000000000 RDX: ffff943520930aa0 RSI: ffff94352091fc80 RDI: ffff94352091fc80 RBP: 0000000000000000 R08: 0000000000000000 R09: ffffb638c9c0fc38 R10: ffffb638c9c0fc30 R11: ffffffffa015eb28 R12: 0000000000000002 R13: ffffb638c9c0fe20 R14: 0000000000000001 R15: ffff942f9cd051c0 FS: 0000000000000000(0000) GS:ffff943520900000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f4f25214000 CR3: 000000025fbae004 CR4: 00000000007706e0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 PKRU: 55555554 Call Trace: rwsem_down_write_slowpath+0x17e/0x470 smc_link_down_work+0x3c/0x60 [smc] process_one_work+0x1ac/0x350 worker_thread+0x49/0x2f0 ? rescuer_thread+0x360/0x360 kthread+0x118/0x140 ? __kthread_bind_mask+0x60/0x60 ret_from_fork+0x1f/0x30 | |||||
| CVE-2024-56770 | 1 Linux | 1 Linux Kernel | 2025-01-10 | N/A | 5.5 MEDIUM |
| In the Linux kernel, the following vulnerability has been resolved: net/sched: netem: account for backlog updates from child qdisc In general, 'qlen' of any classful qdisc should keep track of the number of packets that the qdisc itself and all of its children holds. In case of netem, 'qlen' only accounts for the packets in its internal tfifo. When netem is used with a child qdisc, the child qdisc can use 'qdisc_tree_reduce_backlog' to inform its parent, netem, about created or dropped SKBs. This function updates 'qlen' and the backlog statistics of netem, but netem does not account for changes made by a child qdisc. 'qlen' then indicates the wrong number of packets in the tfifo. If a child qdisc creates new SKBs during enqueue and informs its parent about this, netem's 'qlen' value is increased. When netem dequeues the newly created SKBs from the child, the 'qlen' in netem is not updated. If 'qlen' reaches the configured sch->limit, the enqueue function stops working, even though the tfifo is not full. Reproduce the bug: Ensure that the sender machine has GSO enabled. Configure netem as root qdisc and tbf as its child on the outgoing interface of the machine as follows: $ tc qdisc add dev <oif> root handle 1: netem delay 100ms limit 100 $ tc qdisc add dev <oif> parent 1:0 tbf rate 50Mbit burst 1542 latency 50ms Send bulk TCP traffic out via this interface, e.g., by running an iPerf3 client on the machine. Check the qdisc statistics: $ tc -s qdisc show dev <oif> Statistics after 10s of iPerf3 TCP test before the fix (note that netem's backlog > limit, netem stopped accepting packets): qdisc netem 1: root refcnt 2 limit 1000 delay 100ms Sent 2767766 bytes 1848 pkt (dropped 652, overlimits 0 requeues 0) backlog 4294528236b 1155p requeues 0 qdisc tbf 10: parent 1:1 rate 50Mbit burst 1537b lat 50ms Sent 2767766 bytes 1848 pkt (dropped 327, overlimits 7601 requeues 0) backlog 0b 0p requeues 0 Statistics after the fix: qdisc netem 1: root refcnt 2 limit 1000 delay 100ms Sent 37766372 bytes 24974 pkt (dropped 9, overlimits 0 requeues 0) backlog 0b 0p requeues 0 qdisc tbf 10: parent 1:1 rate 50Mbit burst 1537b lat 50ms Sent 37766372 bytes 24974 pkt (dropped 327, overlimits 96017 requeues 0) backlog 0b 0p requeues 0 tbf segments the GSO SKBs (tbf_segment) and updates the netem's 'qlen'. The interface fully stops transferring packets and "locks". In this case, the child qdisc and tfifo are empty, but 'qlen' indicates the tfifo is at its limit and no more packets are accepted. This patch adds a counter for the entries in the tfifo. Netem's 'qlen' is only decreased when a packet is returned by its dequeue function, and not during enqueuing into the child qdisc. External updates to 'qlen' are thus accounted for and only the behavior of the backlog statistics changes. As in other qdiscs, 'qlen' then keeps track of how many packets are held in netem and all of its children. As before, sch->limit remains as the maximum number of packets in the tfifo. The same applies to netem's backlog statistics. | |||||
| CVE-2024-56771 | 1 Linux | 1 Linux Kernel | 2025-01-10 | N/A | 5.5 MEDIUM |
| In the Linux kernel, the following vulnerability has been resolved: mtd: spinand: winbond: Fix 512GW, 01GW, 01JW and 02JW ECC information These four chips: * W25N512GW * W25N01GW * W25N01JW * W25N02JW all require a single bit of ECC strength and thus feature an on-die Hamming-like ECC engine. There is no point in filling a ->get_status() callback for them because the main ECC status bytes are located in standard places, and retrieving the number of bitflips in case of corrected chunk is both useless and unsupported (if there are bitflips, then there is 1 at most, so no need to query the chip for that). Without this change, a kernel warning triggers every time a bit flips. | |||||
| CVE-2023-30285 | 1 Deviniti | 1 Issue Sync | 2025-01-10 | N/A | 7.5 HIGH |
| An issue in Deviniti Issue Sync Synchronization v3.5.2 for Jira allows attackers to obtain the login credentials of a user via a crafted request sent to /rest/synchronizer/1.0/technicalUser. | |||||
| CVE-2023-33507 | 1 Kramerav | 2 Via Go2, Via Go2 Firmware | 2025-01-10 | N/A | 7.5 HIGH |
| KramerAV VIA GO² < 4.0.1.1326 is vulnerable to Unauthenticated arbitrary file read. | |||||
| CVE-2024-24988 | 1 Mattermost | 1 Mattermost Server | 2025-01-10 | N/A | 4.3 MEDIUM |
| Mattermost fails to properly validate the length of the emoji value in the custom user status, allowing an attacker to send multiple times a very long string as an emoji value causing high resource consumption and possibly crashing the server. | |||||
| CVE-2024-20659 | 1 Microsoft | 10 Windows 10 1809, Windows 10 21h2, Windows 10 22h2 and 7 more | 2025-01-10 | N/A | 7.1 HIGH |
| Windows Hyper-V Security Feature Bypass Vulnerability | |||||
| CVE-2024-30092 | 1 Microsoft | 12 Windows 10 1507, Windows 10 1607, Windows 10 1809 and 9 more | 2025-01-10 | N/A | 8.0 HIGH |
| Windows Hyper-V Remote Code Execution Vulnerability | |||||
| CVE-2023-34257 | 1 Bmc | 1 Patrol Agent | 2025-01-10 | N/A | 9.8 CRITICAL |
| An issue was discovered in BMC Patrol through 23.1.00. The agent's configuration can be remotely modified (and, by default, authentication is not required). Some configuration fields related to SNMP (e.g., masterAgentName or masterAgentStartLine) result in code execution when the agent is restarted. NOTE: the vendor's perspective is "These are not vulnerabilities for us as we have provided the option to implement the authentication." | |||||
| CVE-2023-33735 | 1 Dlink | 2 Dir-846, Dir-846 Firmware | 2025-01-10 | N/A | 9.8 CRITICAL |
| D-Link DIR-846 v1.00A52 was discovered to contain a remote command execution (RCE) vulnerability via the tomography_ping_address parameter in the /HNAP1 interface. | |||||
| CVE-2024-43468 | 1 Microsoft | 1 Configuration Manager | 2025-01-10 | N/A | 9.8 CRITICAL |
| Microsoft Configuration Manager Remote Code Execution Vulnerability | |||||
| CVE-2024-43610 | 1 Microsoft | 1 Copilot Studio | 2025-01-10 | N/A | 7.4 HIGH |
| Exposure of Sensitive Information to an Unauthorized Actor in Copilot Studio allows a unauthenticated attacker to view sensitive information through network attack vector | |||||
| CVE-2024-7417 | 1 Royal-elementor-addons | 1 Royal Elementor Addons | 2025-01-10 | N/A | 4.3 MEDIUM |
| The Royal Elementor Addons and Templates plugin for WordPress is vulnerable to Information Exposure in all versions up to, and including, 1.3.986 via the data_fetch. This makes it possible for authenticated attackers, with subscriber-level access and above, to extract data from password protected posts. | |||||
| CVE-2023-29747 | 1 Story Saver For Instagram - Video Downloader Project | 1 Story Saver For Instagram - Video Downloader | 2025-01-09 | N/A | 9.8 CRITICAL |
| Story Saver for Instragram - Video Downloader 1.0.6 for Android exists exposed component, the component provides the method to modify the SharedPreference file. The attacker can use the method to modify the data in any SharedPreference file, these data will be loaded into the memory when the application is opened. Depending on how the data is used, this can result in various attack consequences, such as ad display exceptions. | |||||
| CVE-2024-56780 | 1 Linux | 1 Linux Kernel | 2025-01-09 | N/A | 5.5 MEDIUM |
| In the Linux kernel, the following vulnerability has been resolved: quota: flush quota_release_work upon quota writeback One of the paths quota writeback is called from is: freeze_super() sync_filesystem() ext4_sync_fs() dquot_writeback_dquots() Since we currently don't always flush the quota_release_work queue in this path, we can end up with the following race: 1. dquot are added to releasing_dquots list during regular operations. 2. FS Freeze starts, however, this does not flush the quota_release_work queue. 3. Freeze completes. 4. Kernel eventually tries to flush the workqueue while FS is frozen which hits a WARN_ON since transaction gets started during frozen state: ext4_journal_check_start+0x28/0x110 [ext4] (unreliable) __ext4_journal_start_sb+0x64/0x1c0 [ext4] ext4_release_dquot+0x90/0x1d0 [ext4] quota_release_workfn+0x43c/0x4d0 Which is the following line: WARN_ON(sb->s_writers.frozen == SB_FREEZE_COMPLETE); Which ultimately results in generic/390 failing due to dmesg noise. This was detected on powerpc machine 15 cores. To avoid this, make sure to flush the workqueue during dquot_writeback_dquots() so we dont have any pending workitems after freeze. | |||||