Filtered by vendor Linux
Subscriptions
Filtered by product Linux Kernel
Subscriptions
Total
13514 CVE
| CVE | Vendors | Products | Updated | CVSS v3.1 |
|---|---|---|---|---|
| CVE-2025-38100 | 1 Linux | 1 Linux Kernel | 2025-07-28 | 7.0 High |
| In the Linux kernel, the following vulnerability has been resolved: x86/iopl: Cure TIF_IO_BITMAP inconsistencies io_bitmap_exit() is invoked from exit_thread() when a task exists or when a fork fails. In the latter case the exit_thread() cleans up resources which were allocated during fork(). io_bitmap_exit() invokes task_update_io_bitmap(), which in turn ends up in tss_update_io_bitmap(). tss_update_io_bitmap() operates on the current task. If current has TIF_IO_BITMAP set, but no bitmap installed, tss_update_io_bitmap() crashes with a NULL pointer dereference. There are two issues, which lead to that problem: 1) io_bitmap_exit() should not invoke task_update_io_bitmap() when the task, which is cleaned up, is not the current task. That's a clear indicator for a cleanup after a failed fork(). 2) A task should not have TIF_IO_BITMAP set and neither a bitmap installed nor IOPL emulation level 3 activated. This happens when a kernel thread is created in the context of a user space thread, which has TIF_IO_BITMAP set as the thread flags are copied and the IO bitmap pointer is cleared. Other than in the failed fork() case this has no impact because kernel threads including IO workers never return to user space and therefore never invoke tss_update_io_bitmap(). Cure this by adding the missing cleanups and checks: 1) Prevent io_bitmap_exit() to invoke task_update_io_bitmap() if the to be cleaned up task is not the current task. 2) Clear TIF_IO_BITMAP in copy_thread() unconditionally. For user space forks it is set later, when the IO bitmap is inherited in io_bitmap_share(). For paranoia sake, add a warning into tss_update_io_bitmap() to catch the case, when that code is invoked with inconsistent state. | ||||
| CVE-2025-38093 | 1 Linux | 1 Linux Kernel | 2025-07-28 | 5.5 Medium |
| In the Linux kernel, the following vulnerability has been resolved: arm64: dts: qcom: x1e80100: Add GPU cooling Unlike the CPU, the GPU does not throttle its speed automatically when it reaches high temperatures. With certain high GPU loads it is possible to reach the critical hardware shutdown temperature of 120°C, endangering the hardware and making it impossible to run certain applications. Set up GPU cooling similar to the ACPI tables, by throttling the GPU speed when reaching 95°C and polling every 200ms. | ||||
| CVE-2025-38090 | 1 Linux | 1 Linux Kernel | 2025-07-28 | 7.0 High |
| In the Linux kernel, the following vulnerability has been resolved: drivers/rapidio/rio_cm.c: prevent possible heap overwrite In riocm_cdev_ioctl(RIO_CM_CHAN_SEND) -> cm_chan_msg_send() -> riocm_ch_send() cm_chan_msg_send() checks that userspace didn't send too much data but riocm_ch_send() failed to check that userspace sent sufficient data. The result is that riocm_ch_send() can write to fields in the rio_ch_chan_hdr which were outside the bounds of the space which cm_chan_msg_send() allocated. Address this by teaching riocm_ch_send() to check that the entire rio_ch_chan_hdr was copied in from userspace. | ||||
| CVE-2025-38089 | 1 Linux | 1 Linux Kernel | 2025-07-28 | 7.1 High |
| In the Linux kernel, the following vulnerability has been resolved: sunrpc: handle SVC_GARBAGE during svc auth processing as auth error tianshuo han reported a remotely-triggerable crash if the client sends a kernel RPC server a specially crafted packet. If decoding the RPC reply fails in such a way that SVC_GARBAGE is returned without setting the rq_accept_statp pointer, then that pointer can be dereferenced and a value stored there. If it's the first time the thread has processed an RPC, then that pointer will be set to NULL and the kernel will crash. In other cases, it could create a memory scribble. The server sunrpc code treats a SVC_GARBAGE return from svc_authenticate or pg_authenticate as if it should send a GARBAGE_ARGS reply. RFC 5531 says that if authentication fails that the RPC should be rejected instead with a status of AUTH_ERR. Handle a SVC_GARBAGE return as an AUTH_ERROR, with a reason of AUTH_BADCRED instead of returning GARBAGE_ARGS in that case. This sidesteps the whole problem of touching the rpc_accept_statp pointer in this situation and avoids the crash. | ||||
| CVE-2025-38088 | 1 Linux | 1 Linux Kernel | 2025-07-28 | 7.0 High |
| In the Linux kernel, the following vulnerability has been resolved: powerpc/powernv/memtrace: Fix out of bounds issue in memtrace mmap memtrace mmap issue has an out of bounds issue. This patch fixes the by checking that the requested mapping region size should stay within the allocated region size. | ||||
| CVE-2025-38087 | 1 Linux | 1 Linux Kernel | 2025-07-28 | 7.0 High |
| In the Linux kernel, the following vulnerability has been resolved: net/sched: fix use-after-free in taprio_dev_notifier Since taprio’s taprio_dev_notifier() isn’t protected by an RCU read-side critical section, a race with advance_sched() can lead to a use-after-free. Adding rcu_read_lock() inside taprio_dev_notifier() prevents this. | ||||
| CVE-2025-38086 | 1 Linux | 1 Linux Kernel | 2025-07-28 | 7.0 High |
| In the Linux kernel, the following vulnerability has been resolved: net: ch9200: fix uninitialised access during mii_nway_restart In mii_nway_restart() the code attempts to call mii->mdio_read which is ch9200_mdio_read(). ch9200_mdio_read() utilises a local buffer called "buff", which is initialised with control_read(). However "buff" is conditionally initialised inside control_read(): if (err == size) { memcpy(data, buf, size); } If the condition of "err == size" is not met, then "buff" remains uninitialised. Once this happens the uninitialised "buff" is accessed and returned during ch9200_mdio_read(): return (buff[0] | buff[1] << 8); The problem stems from the fact that ch9200_mdio_read() ignores the return value of control_read(), leading to uinit-access of "buff". To fix this we should check the return value of control_read() and return early on error. | ||||
| CVE-2025-38083 | 1 Linux | 1 Linux Kernel | 2025-07-28 | 6.3 Medium |
| In the Linux kernel, the following vulnerability has been resolved: net_sched: prio: fix a race in prio_tune() Gerrard Tai reported a race condition in PRIO, whenever SFQ perturb timer fires at the wrong time. The race is as follows: CPU 0 CPU 1 [1]: lock root [2]: qdisc_tree_flush_backlog() [3]: unlock root | | [5]: lock root | [6]: rehash | [7]: qdisc_tree_reduce_backlog() | [4]: qdisc_put() This can be abused to underflow a parent's qlen. Calling qdisc_purge_queue() instead of qdisc_tree_flush_backlog() should fix the race, because all packets will be purged from the qdisc before releasing the lock. | ||||
| CVE-2025-38001 | 1 Linux | 1 Linux Kernel | 2025-07-28 | 5.6 Medium |
| In the Linux kernel, the following vulnerability has been resolved: net_sched: hfsc: Address reentrant enqueue adding class to eltree twice Savino says: "We are writing to report that this recent patch (141d34391abbb315d68556b7c67ad97885407547) [1] can be bypassed, and a UAF can still occur when HFSC is utilized with NETEM. The patch only checks the cl->cl_nactive field to determine whether it is the first insertion or not [2], but this field is only incremented by init_vf [3]. By using HFSC_RSC (which uses init_ed) [4], it is possible to bypass the check and insert the class twice in the eltree. Under normal conditions, this would lead to an infinite loop in hfsc_dequeue for the reasons we already explained in this report [5]. However, if TBF is added as root qdisc and it is configured with a very low rate, it can be utilized to prevent packets from being dequeued. This behavior can be exploited to perform subsequent insertions in the HFSC eltree and cause a UAF." To fix both the UAF and the infinite loop, with netem as an hfsc child, check explicitly in hfsc_enqueue whether the class is already in the eltree whenever the HFSC_RSC flag is set. [1] https://web.git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=141d34391abbb315d68556b7c67ad97885407547 [2] https://elixir.bootlin.com/linux/v6.15-rc5/source/net/sched/sch_hfsc.c#L1572 [3] https://elixir.bootlin.com/linux/v6.15-rc5/source/net/sched/sch_hfsc.c#L677 [4] https://elixir.bootlin.com/linux/v6.15-rc5/source/net/sched/sch_hfsc.c#L1574 [5] https://lore.kernel.org/netdev/8DuRWwfqjoRDLDmBMlIfbrsZg9Gx50DHJc1ilxsEBNe2D6NMoigR_eIRIG0LOjMc3r10nUUZtArXx4oZBIdUfZQrwjcQhdinnMis_0G7VEk=@willsroot.io/T/#u | ||||
| CVE-2024-0565 | 3 Linux, Netapp, Redhat | 6 Linux Kernel, Ontap Tools, Enterprise Linux and 3 more | 2025-07-26 | 6.8 Medium |
| An out-of-bounds memory read flaw was found in receive_encrypted_standard in fs/smb/client/smb2ops.c in the SMB Client sub-component in the Linux Kernel. This issue occurs due to integer underflow on the memcpy length, leading to a denial of service. | ||||
| CVE-2023-42756 | 4 Debian, Fedoraproject, Linux and 1 more | 4 Debian Linux, Fedora, Linux Kernel and 1 more | 2025-07-26 | 4.4 Medium |
| A flaw was found in the Netfilter subsystem of the Linux kernel. A race condition between IPSET_CMD_ADD and IPSET_CMD_SWAP can lead to a kernel panic due to the invocation of `__ip_set_put` on a wrong `set`. This issue may allow a local user to crash the system. | ||||
| CVE-2023-6531 | 2 Linux, Redhat | 2 Linux Kernel, Enterprise Linux | 2025-07-26 | 7 High |
| A use-after-free flaw was found in the Linux Kernel due to a race problem in the unix garbage collector's deletion of SKB races with unix_stream_read_generic() on the socket that the SKB is queued on. | ||||
| CVE-2023-6546 | 3 Fedoraproject, Linux, Redhat | 9 Fedora, Linux Kernel, Enterprise Linux and 6 more | 2025-07-25 | 7 High |
| A race condition was found in the GSM 0710 tty multiplexor in the Linux kernel. This issue occurs when two threads execute the GSMIOC_SETCONF ioctl on the same tty file descriptor with the gsm line discipline enabled, and can lead to a use-after-free problem on a struct gsm_dlci while restarting the gsm mux. This could allow a local unprivileged user to escalate their privileges on the system. | ||||
| CVE-2023-33855 | 2 Ibm, Linux | 4 Aix, Common Cryptographic Architecture, I and 1 more | 2025-07-25 | 3.7 Low |
| Under certain conditions, RSA operations performed by IBM Common Cryptographic Architecture (CCA) 7.0.0 through 7.5.36 may exhibit non-constant-time behavior. This could allow a remote attacker to obtain sensitive information using a timing-based attack. IBM X-Force ID: 257676. | ||||
| CVE-2024-47107 | 2 Ibm, Linux | 2 Qradar Security Information And Event Manager, Linux Kernel | 2025-07-25 | 6.4 Medium |
| IBM QRadar SIEM 7.5 is vulnerable to stored cross-site scripting. This vulnerability allows authenticated users to embed arbitrary JavaScript code in the Web UI thus altering the intended functionality potentially leading to credentials disclosure within a trusted session. | ||||
| CVE-2023-47150 | 2 Ibm, Linux | 4 Aix, Common Cryptographic Architecture, I and 1 more | 2025-07-25 | 7.5 High |
| IBM Common Cryptographic Architecture (CCA) 7.0.0 through 7.5.36 could allow a remote user to cause a denial of service due to incorrect data handling for certain types of AES operations. IBM X-Force ID: 270602. | ||||
| CVE-2024-27269 | 2 Ibm, Linux | 2 Qradar Security Information And Event Manager, Linux Kernel | 2025-07-25 | 6.8 Medium |
| IBM QRadar SIEM 7.5 could allow a privileged user to configure user management that would disclose unintended sensitive information across tenants. IBM X-Force ID: 284575. | ||||
| CVE-2024-31892 | 2 Ibm, Linux | 3 Spectrum Scale Container Native Storage Access, Storage Scale, Linux Kernel | 2025-07-25 | 7.5 High |
| IBM Storage Scale GUI 5.1.9.0 through 5.1.9.6 and 5.2.0.0 through 5.2.1.1 could allow a user to perform unauthorized actions after intercepting and modifying a csv file due to improper neutralization of formula elements. | ||||
| CVE-2024-31891 | 2 Ibm, Linux | 3 Spectrum Scale Container Native Storage Access, Storage Scale, Linux Kernel | 2025-07-25 | 7.8 High |
| IBM Storage Scale GUI 5.1.9.0 through 5.1.9.6 and 5.2.0.0 through 5.2.1.1 contains a local privilege escalation vulnerability. A malicious actor with command line access to the 'scalemgmt' user can elevate privileges to gain root access to the host operating system. | ||||
| CVE-2024-38337 | 3 Ibm, Linux, Microsoft | 5 Aix, Linux On Ibm Z, Sterling Secure Proxy and 2 more | 2025-07-25 | 9.1 Critical |
| IBM Sterling Secure Proxy 6.0.0.0, 6.0.0.1, 6.0.0.2, 6.0.0.3, 6.1.0.0, and 6.2.0.0 could allow an unauthorized attacker to retrieve or alter sensitive information contents due to incorrect permission assignments. | ||||