Total
33556 CVE
| CVE | Vendors | Products | Updated | CVSS v3.1 |
|---|---|---|---|---|
| CVE-2024-45008 | 1 Linux | 1 Linux Kernel | 2025-11-03 | 5.5 Medium |
| In the Linux kernel, the following vulnerability has been resolved: Input: MT - limit max slots syzbot is reporting too large allocation at input_mt_init_slots(), for num_slots is supplied from userspace using ioctl(UI_DEV_CREATE). Since nobody knows possible max slots, this patch chose 1024. | ||||
| CVE-2024-45007 | 1 Linux | 1 Linux Kernel | 2025-11-03 | 5.5 Medium |
| In the Linux kernel, the following vulnerability has been resolved: char: xillybus: Don't destroy workqueue from work item running on it Triggered by a kref decrement, destroy_workqueue() may be called from within a work item for destroying its own workqueue. This illegal situation is averted by adding a module-global workqueue for exclusive use of the offending work item. Other work items continue to be queued on per-device workqueues to ensure performance. | ||||
| CVE-2024-44991 | 1 Linux | 1 Linux Kernel | 2025-11-03 | 5.5 Medium |
| In the Linux kernel, the following vulnerability has been resolved: tcp: prevent concurrent execution of tcp_sk_exit_batch Its possible that two threads call tcp_sk_exit_batch() concurrently, once from the cleanup_net workqueue, once from a task that failed to clone a new netns. In the latter case, error unwinding calls the exit handlers in reverse order for the 'failed' netns. tcp_sk_exit_batch() calls tcp_twsk_purge(). Problem is that since commit b099ce2602d8 ("net: Batch inet_twsk_purge"), this function picks up twsk in any dying netns, not just the one passed in via exit_batch list. This means that the error unwind of setup_net() can "steal" and destroy timewait sockets belonging to the exiting netns. This allows the netns exit worker to proceed to call WARN_ON_ONCE(!refcount_dec_and_test(&net->ipv4.tcp_death_row.tw_refcount)); without the expected 1 -> 0 transition, which then splats. At same time, error unwind path that is also running inet_twsk_purge() will splat as well: WARNING: .. at lib/refcount.c:31 refcount_warn_saturate+0x1ed/0x210 ... refcount_dec include/linux/refcount.h:351 [inline] inet_twsk_kill+0x758/0x9c0 net/ipv4/inet_timewait_sock.c:70 inet_twsk_deschedule_put net/ipv4/inet_timewait_sock.c:221 inet_twsk_purge+0x725/0x890 net/ipv4/inet_timewait_sock.c:304 tcp_sk_exit_batch+0x1c/0x170 net/ipv4/tcp_ipv4.c:3522 ops_exit_list+0x128/0x180 net/core/net_namespace.c:178 setup_net+0x714/0xb40 net/core/net_namespace.c:375 copy_net_ns+0x2f0/0x670 net/core/net_namespace.c:508 create_new_namespaces+0x3ea/0xb10 kernel/nsproxy.c:110 ... because refcount_dec() of tw_refcount unexpectedly dropped to 0. This doesn't seem like an actual bug (no tw sockets got lost and I don't see a use-after-free) but as erroneous trigger of debug check. Add a mutex to force strict ordering: the task that calls tcp_twsk_purge() blocks other task from doing final _dec_and_test before mutex-owner has removed all tw sockets of dying netns. | ||||
| CVE-2024-44988 | 1 Linux | 1 Linux Kernel | 2025-11-03 | 5.5 Medium |
| In the Linux kernel, the following vulnerability has been resolved: net: dsa: mv88e6xxx: Fix out-of-bound access If an ATU violation was caused by a CPU Load operation, the SPID could be larger than DSA_MAX_PORTS (the size of mv88e6xxx_chip.ports[] array). | ||||
| CVE-2024-44970 | 2 Linux, Redhat | 2 Linux Kernel, Enterprise Linux | 2025-11-03 | 5.5 Medium |
| In the Linux kernel, the following vulnerability has been resolved: net/mlx5e: SHAMPO, Fix invalid WQ linked list unlink When all the strides in a WQE have been consumed, the WQE is unlinked from the WQ linked list (mlx5_wq_ll_pop()). For SHAMPO, it is possible to receive CQEs with 0 consumed strides for the same WQE even after the WQE is fully consumed and unlinked. This triggers an additional unlink for the same wqe which corrupts the linked list. Fix this scenario by accepting 0 sized consumed strides without unlinking the WQE again. | ||||
| CVE-2024-44968 | 1 Linux | 1 Linux Kernel | 2025-11-03 | 5.5 Medium |
| In the Linux kernel, the following vulnerability has been resolved: tick/broadcast: Move per CPU pointer access into the atomic section The recent fix for making the take over of the broadcast timer more reliable retrieves a per CPU pointer in preemptible context. This went unnoticed as compilers hoist the access into the non-preemptible region where the pointer is actually used. But of course it's valid that the compiler keeps it at the place where the code puts it which rightfully triggers: BUG: using smp_processor_id() in preemptible [00000000] code: caller is hotplug_cpu__broadcast_tick_pull+0x1c/0xc0 Move it to the actual usage site which is in a non-preemptible region. | ||||
| CVE-2024-44967 | 1 Linux | 1 Linux Kernel | 2025-11-03 | 7.8 High |
| In the Linux kernel, the following vulnerability has been resolved: drm/mgag200: Bind I2C lifetime to DRM device Managed cleanup with devm_add_action_or_reset() will release the I2C adapter when the underlying Linux device goes away. But the connector still refers to it, so this cleanup leaves behind a stale pointer in struct drm_connector.ddc. Bind the lifetime of the I2C adapter to the connector's lifetime by using DRM's managed release. When the DRM device goes away (after the Linux device) DRM will first clean up the connector and then clean up the I2C adapter. | ||||
| CVE-2024-44966 | 1 Linux | 1 Linux Kernel | 2025-11-03 | 5.5 Medium |
| In the Linux kernel, the following vulnerability has been resolved: binfmt_flat: Fix corruption when not offsetting data start Commit 04d82a6d0881 ("binfmt_flat: allow not offsetting data start") introduced a RISC-V specific variant of the FLAT format which does not allocate any space for the (obsolete) array of shared library pointers. However, it did not disable the code which initializes the array, resulting in the corruption of sizeof(long) bytes before the DATA segment, generally the end of the TEXT segment. Introduce MAX_SHARED_LIBS_UPDATE which depends on the state of CONFIG_BINFMT_FLAT_NO_DATA_START_OFFSET to guard the initialization of the shared library pointer region so that it will only be initialized if space is reserved for it. | ||||
| CVE-2024-44965 | 2 Linux, Redhat | 2 Linux Kernel, Enterprise Linux | 2025-11-03 | 5.5 Medium |
| In the Linux kernel, the following vulnerability has been resolved: x86/mm: Fix pti_clone_pgtable() alignment assumption Guenter reported dodgy crashes on an i386-nosmp build using GCC-11 that had the form of endless traps until entry stack exhaust and then #DF from the stack guard. It turned out that pti_clone_pgtable() had alignment assumptions on the start address, notably it hard assumes start is PMD aligned. This is true on x86_64, but very much not true on i386. These assumptions can cause the end condition to malfunction, leading to a 'short' clone. Guess what happens when the user mapping has a short copy of the entry text? Use the correct increment form for addr to avoid alignment assumptions. | ||||
| CVE-2024-44958 | 2 Linux, Redhat | 2 Linux Kernel, Enterprise Linux | 2025-11-03 | 5.5 Medium |
| In the Linux kernel, the following vulnerability has been resolved: sched/smt: Fix unbalance sched_smt_present dec/inc I got the following warn report while doing stress test: jump label: negative count! WARNING: CPU: 3 PID: 38 at kernel/jump_label.c:263 static_key_slow_try_dec+0x9d/0xb0 Call Trace: <TASK> __static_key_slow_dec_cpuslocked+0x16/0x70 sched_cpu_deactivate+0x26e/0x2a0 cpuhp_invoke_callback+0x3ad/0x10d0 cpuhp_thread_fun+0x3f5/0x680 smpboot_thread_fn+0x56d/0x8d0 kthread+0x309/0x400 ret_from_fork+0x41/0x70 ret_from_fork_asm+0x1b/0x30 </TASK> Because when cpuset_cpu_inactive() fails in sched_cpu_deactivate(), the cpu offline failed, but sched_smt_present is decremented before calling sched_cpu_deactivate(), it leads to unbalanced dec/inc, so fix it by incrementing sched_smt_present in the error path. | ||||
| CVE-2024-44949 | 1 Linux | 1 Linux Kernel | 2025-11-03 | 7.8 High |
| In the Linux kernel, the following vulnerability has been resolved: parisc: fix a possible DMA corruption ARCH_DMA_MINALIGN was defined as 16 - this is too small - it may be possible that two unrelated 16-byte allocations share a cache line. If one of these allocations is written using DMA and the other is written using cached write, the value that was written with DMA may be corrupted. This commit changes ARCH_DMA_MINALIGN to be 128 on PA20 and 32 on PA1.1 - that's the largest possible cache line size. As different parisc microarchitectures have different cache line size, we define arch_slab_minalign(), cache_line_size() and dma_get_cache_alignment() so that the kernel may tune slab cache parameters dynamically, based on the detected cache line size. | ||||
| CVE-2024-44948 | 1 Linux | 1 Linux Kernel | 2025-11-03 | 5.5 Medium |
| In the Linux kernel, the following vulnerability has been resolved: x86/mtrr: Check if fixed MTRRs exist before saving them MTRRs have an obsolete fixed variant for fine grained caching control of the 640K-1MB region that uses separate MSRs. This fixed variant has a separate capability bit in the MTRR capability MSR. So far all x86 CPUs which support MTRR have this separate bit set, so it went unnoticed that mtrr_save_state() does not check the capability bit before accessing the fixed MTRR MSRs. Though on a CPU that does not support the fixed MTRR capability this results in a #GP. The #GP itself is harmless because the RDMSR fault is handled gracefully, but results in a WARN_ON(). Add the missing capability check to prevent this. | ||||
| CVE-2024-44940 | 1 Linux | 1 Linux Kernel | 2025-11-03 | 7.8 High |
| In the Linux kernel, the following vulnerability has been resolved: fou: remove warn in gue_gro_receive on unsupported protocol Drop the WARN_ON_ONCE inn gue_gro_receive if the encapsulated type is not known or does not have a GRO handler. Such a packet is easily constructed. Syzbot generates them and sets off this warning. Remove the warning as it is expected and not actionable. The warning was previously reduced from WARN_ON to WARN_ON_ONCE in commit 270136613bf7 ("fou: Do WARN_ON_ONCE in gue_gro_receive for bad proto callbacks"). | ||||
| CVE-2024-44931 | 2 Linux, Redhat | 2 Linux Kernel, Enterprise Linux | 2025-11-03 | 5.5 Medium |
| In the Linux kernel, the following vulnerability has been resolved: gpio: prevent potential speculation leaks in gpio_device_get_desc() Userspace may trigger a speculative read of an address outside the gpio descriptor array. Users can do that by calling gpio_ioctl() with an offset out of range. Offset is copied from user and then used as an array index to get the gpio descriptor without sanitization in gpio_device_get_desc(). This change ensures that the offset is sanitized by using array_index_nospec() to mitigate any possibility of speculative information leaks. This bug was discovered and resolved using Coverity Static Analysis Security Testing (SAST) by Synopsys, Inc. | ||||
| CVE-2024-44302 | 1 Apple | 6 Ipados, Iphone Os, Macos and 3 more | 2025-11-03 | 5.5 Medium |
| The issue was addressed with improved checks. This issue is fixed in tvOS 18.1, iOS 18.1 and iPadOS 18.1, iOS 17.7.1 and iPadOS 17.7.1, macOS Ventura 13.7.1, macOS Sonoma 14.7.1, watchOS 11.1, visionOS 2.1. Processing a maliciously crafted font may result in the disclosure of process memory. | ||||
| CVE-2024-44301 | 1 Apple | 1 Macos | 2025-11-03 | 5.5 Medium |
| The issue was addressed with improved checks. This issue is fixed in macOS Ventura 13.7.1, macOS Sonoma 14.7.1. A malicious application may be able to modify protected parts of the file system. | ||||
| CVE-2024-44300 | 1 Apple | 1 Macos | 2025-11-03 | 5.5 Medium |
| A logic issue was addressed with improved file handling. This issue is fixed in macOS Sequoia 15.2, macOS Ventura 13.7.2, macOS Sonoma 14.7.2. An app may be able to access protected user data. | ||||
| CVE-2024-44297 | 1 Apple | 6 Ipad Os, Iphone Os, Macos and 3 more | 2025-11-03 | 6.5 Medium |
| The issue was addressed with improved bounds checks. This issue is fixed in tvOS 18.1, iOS 18.1 and iPadOS 18.1, iOS 17.7.1 and iPadOS 17.7.1, macOS Ventura 13.7.1, macOS Sonoma 14.7.1, watchOS 11.1, visionOS 2.1. Processing a maliciously crafted message may lead to a denial-of-service. | ||||
| CVE-2024-44296 | 2 Apple, Redhat | 10 Ipados, Iphone Os, Macos and 7 more | 2025-11-03 | 5.4 Medium |
| The issue was addressed with improved checks. This issue is fixed in tvOS 18.1, iOS 18.1 and iPadOS 18.1, iOS 17.7.1 and iPadOS 17.7.1, watchOS 11.1, visionOS 2.1, macOS Sequoia 15.1, Safari 18.1. Processing maliciously crafted web content may prevent Content Security Policy from being enforced. | ||||
| CVE-2024-44295 | 1 Apple | 2 Mac Os, Macos | 2025-11-03 | 7.7 High |
| This issue was addressed with additional entitlement checks. This issue is fixed in macOS Ventura 13.7.1, macOS Sonoma 14.7.1. An app may be able to modify protected parts of the file system. | ||||