Filtered by vendor Linux
Subscribe
Total
19806 CVE
| CVE | Vendors | Products | Updated | CVSS v2 | CVSS v3 |
|---|---|---|---|---|---|
| CVE-2026-64255 | 1 Linux | 1 Linux Kernel | 2026-11-08 | N/A | 8.8 HIGH |
| In the Linux kernel, the following vulnerability has been resolved: wifi: iwlwifi: mld: validate sta_mask before ffs() in BA session handlers Three BA session handlers use ffs(ba_data->sta_mask) - 1 to derive a station ID without checking that sta_mask is non-zero. When sta_mask is zero, ffs() returns 0 and the subtraction wraps to 0xFFFFFFFF, causing an out-of-bounds access on fw_id_to_link_sta[]. Add WARN_ON_ONCE(!ba_data->sta_mask) guards before each ffs() call, consistent with the existing check in iwl_mld_ampdu_rx_start(). | |||||
| CVE-2026-64250 | 1 Linux | 1 Linux Kernel | 2026-11-08 | N/A | 5.5 MEDIUM |
| In the Linux kernel, the following vulnerability has been resolved: LoongArch: Report dying CPU to RCU in stop_this_cpu() This is a port of MIPS commit 9f3f3bdc6d9dac1 ("MIPS: smp: report dying CPU to RCU in stop_this_cpu()"). smp_send_stop() parks all secondary CPUs in stop_this_cpu(). And the function marks the CPU offline for the scheduler via set_cpu_online(false) but never informs RCU, so RCU keeps expecting a quiescent state from CPUs that are now spinning forever with interrupts disabled. As long as nothing waits for an RCU grace period after smp_send_stop() this is harmless, which is why it went unnoticed. However, since commit 91840be8f710370 ("irq_work: Fix use-after-free in irq_work_single() on PREEMPT_RT"), irq_work_sync() calls synchronize_rcu() on architectures without an irq_work self-IPI, i.e. where arch_irq_work_has_interrupt() returns false. Any irq_work_sync() issued in the reboot/shutdown/halt path after smp_send_stop() then blocks on a grace period that can never complete, hanging the reboot: WARNING: CPU: 0 PID: 15 at kernel/irq_work.c:144 irq_work_queue_on ... rcu: INFO: rcu_sched detected stalls on CPUs/tasks: rcu: Offline CPU 1 blocking current GP. rcu: Offline CPU 2 blocking current GP. rcu: Offline CPU 3 blocking current GP. This issue needs some hacks to reproduce, and it was not noticed on LoongArch because arch_irq_work_has_interrupt() usually returns true. Call rcutree_report_cpu_dead() once interrupts are disabled, mirroring the generic CPU-hotplug offline path, so RCU stops waiting on the parked CPUs and grace periods can still complete. LoongArch shuts down all CPUs here without going through the CPU-hotplug mechanism, so this report is not otherwise issued. | |||||
| CVE-2026-64240 | 1 Linux | 1 Linux Kernel | 2026-11-08 | N/A | 5.5 MEDIUM |
| In the Linux kernel, the following vulnerability has been resolved: media: rc: igorplugusb: fix control request setup packet Commit eac69475b01f ("media: rc: igorplugusb: heed coherency rules") changed the control request storage from an embedded struct to an allocated pointer so it can obey DMA coherency rules. However, the driver still passes &ir->request to usb_fill_control_urb(). That points the URB setup packet at the pointer field itself rather than at the allocated struct usb_ctrlrequest. USB core then interprets pointer bytes as the setup packet. This can produce an invalid bRequestType and trigger the control direction warning reported by syzbot: usb 2-1: BOGUS control dir, pipe 80003580 doesn't match bRequestType 0 Pass ir->request itself as the setup packet. | |||||
| CVE-2026-64235 | 1 Linux | 1 Linux Kernel | 2026-11-08 | N/A | 8.1 HIGH |
| In the Linux kernel, the following vulnerability has been resolved: x86/ftrace: Relocate %rip-relative percpu refs in dynamic trampolines With CONFIG_CALL_DEPTH_TRACKING enabled on an x86 retbleed-affected platform (eg: Skylake), with retbleed=stuff, registering a dynamic ftrace trampoline crashes on the first call into the traced function: BUG: unable to handle page fault for address: ffff88817ae18880 #PF: supervisor write access in kernel mode #PF: error_code(0x0002) - not-present page PGD 4b53067 P4D 4b53067 PUD 0 Oops: Oops: 0002 [#1] SMP PTI CPU: 3 UID: 0 PID: 187 Comm: usleep Not tainted 7.0.10 #243 PREEMPT(full) Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Arch Linux 1.17.0-2-2 04/01/2014 Code: 24 78 00 00 00 00 48 89 ea 48 89 54 24 20 48 8b b4 24 b8 00 00 00 48 8b bc 24 b0 00 00 00 48 89 bc 24 80 00 00 00 48 83 ef 05 <65> 48 c1 3d 1f a8 b6 02 05 48 8b 15 f6 00 00 00 4c 89 3c 24 4c 89 Call Trace: <TASK> ? find_held_lock ? exc_page_fault ? lock_release ? __x64_sys_clock_nanosleep ? lockdep_hardirqs_on_prepare ? trace_hardirqs_on __x64_sys_clock_nanosleep do_syscall_64 ? exc_page_fault ? call_depth_return_thunk entry_SYSCALL_64_after_hwframe ... Kernel panic - not syncing: Fatal exception This small reproducer allows to easily trigger the crash: # echo 'p __x64_sys_clock_nanosleep' > /sys/kernel/tracing/kprobe_events # echo 1 > /sys/kernel/tracing/events/kprobes/p___x64_sys_clock_nanosleep_0/enable # usleep 1 Monitoring the crash under GDB points to the exact instruction in charge of incrementing the call depth: sarq $5, %gs:__x86_call_depth(%rip) This instruction matches the one inserted by the ftrace_regs_caller from ftrace_64.S. This emitted code was likely working fine until the introduction of 59bec00ace28 ("x86/percpu: Introduce %rip-relative addressing to PER_CPU_VAR()"): it has made the call depth accounting addressing relative to $rip, instead of being based on an absolute address. As this code exact location depends on where the trampoline lives in memory, the corresponding displacement needs to be adjusted at runtime to actually correctly find the per-cpu __x86_call_depth value, otherwise the targeted address is wrong, leading to the page fault seen above. Fix the %rip-relative displacement of the copied CALL_DEPTH_ACCOUNT instruction (from ftrace_regs_caller) by calling text_poke_apply_relocation(), as it is done for example by the x86 BPF JIT compiler through x86_call_depth_emit_accounting(). This corrects both CALL_DEPTH_ACCOUNT slots, in ftrace_caller and ftrace_regs_caller. [ bp: Massage. ] | |||||
| CVE-2026-64249 | 1 Linux | 1 Linux Kernel | 2026-11-08 | N/A | 7.8 HIGH |
| In the Linux kernel, the following vulnerability has been resolved: fpga: region: fix use-after-free in child_regions_with_firmware() Move of_node_put(child_region) after the error print to avoid accessing freed memory when pr_err() references child_region. [ Yilun: Fix the Fixes tag ] | |||||
| CVE-2026-64253 | 1 Linux | 1 Linux Kernel | 2026-11-08 | N/A | 5.5 MEDIUM |
| In the Linux kernel, the following vulnerability has been resolved: kernel/fork: clear PF_BLOCK_TS in copy_process() PF_BLOCK_TS is only set in blk_time_get_ns() when current->plug is non-NULL, and blk_finish_plug() clears it via __blk_flush_plug() before NULLing the plug pointer. copy_process() breaks the invariant by inheriting PF_BLOCK_TS from the parent while resetting the child's plug to NULL. Clear PF_BLOCK_TS alongside that assignment so callers can rely on "PF_BLOCK_TS set implies current->plug != NULL" and dereference current->plug unguarded. | |||||
| CVE-2026-64241 | 1 Linux | 1 Linux Kernel | 2026-11-08 | N/A | 5.5 MEDIUM |
| In the Linux kernel, the following vulnerability has been resolved: gpio: rockchip: teardown bugs and resource leaks Address several teardown issues and resource leaks in the driver's remove path and error handling: 1. Debounce clock reference leak: The debounce clock (bank->db_clk) is obtained using of_clk_get() which increments the clock's reference count, but clk_put() is never called. Register a devm action to cleanly release it on unbind. Note that of_clk_get(..., 1) remains necessary over devm_clk_get() because the DT binding does not define clock-names, precluding name-based lookup. 2. Unregistered chained IRQ handler: The chained IRQ handler is not disconnected in remove(). If a stray interrupt fires after the driver is removed, the kernel attempts to execute a stale handler, leading to a panic. Fix this by clearing the handler in remove(). 3. IRQ domain leak: The linear IRQ domain and its generic chips are allocated manually during probe but never removed. Remove the IRQ domain during driver teardown to free the associated generic chips and mappings. [Bartosz: don't emit an error message on devres allocation failure] | |||||
| CVE-2023-5178 | 3 Linux, Netapp, Redhat | 5 Linux Kernel, Active Iq Unified Manager, Solidfire \& Hci Management Node and 2 more | 2026-11-07 | N/A | 8.8 HIGH |
| A use-after-free vulnerability was found in drivers/nvme/target/tcp.c` in `nvmet_tcp_free_crypto` due to a logical bug in the NVMe/TCP subsystem in the Linux kernel. This issue may allow a malicious user to cause a use-after-free and double-free problem, which may permit remote code execution or lead to local privilege escalation. | |||||
| CVE-2023-4732 | 2 Linux, Redhat | 10 Linux Kernel, Codeready Linux Builder, Codeready Linux Builder For Arm64 and 7 more | 2026-11-07 | N/A | 4.7 MEDIUM |
| A flaw was found in pfn_swap_entry_to_page in memory management subsystem in the Linux Kernel. In this flaw, an attacker with a local user privilege may cause a denial of service problem due to a BUG statement referencing pmd_t x. | |||||
| CVE-2023-4387 | 2 Linux, Redhat | 2 Linux Kernel, Enterprise Linux | 2026-11-07 | N/A | 7.1 HIGH |
| A use-after-free flaw was found in vmxnet3_rq_alloc_rx_buf in drivers/net/vmxnet3/vmxnet3_drv.c in VMware's vmxnet3 ethernet NIC driver in the Linux Kernel. This issue could allow a local attacker to crash the system due to a double-free while cleaning up vmxnet3_rq_cleanup_all, which could also lead to a kernel information leak problem. | |||||
| CVE-2023-4385 | 1 Linux | 1 Linux Kernel | 2026-11-07 | N/A | 5.5 MEDIUM |
| A NULL pointer dereference flaw was found in dbFree in fs/jfs/jfs_dmap.c in the journaling file system (JFS) in the Linux Kernel. This issue may allow a local attacker to crash the system due to a missing sanity check. | |||||
| CVE-2023-4147 | 4 Debian, Fedoraproject, Linux and 1 more | 8 Debian Linux, Fedora, Linux Kernel and 5 more | 2026-11-07 | N/A | 7.8 HIGH |
| A use-after-free flaw was found in the Linux kernel’s Netfilter functionality when adding a rule with NFTA_RULE_CHAIN_ID. This flaw allows a local user to crash or escalate their privileges on the system. | |||||
| CVE-2023-3812 | 2 Linux, Redhat | 2 Linux Kernel, Enterprise Linux | 2026-11-07 | N/A | 7.8 HIGH |
| An out-of-bounds memory access flaw was found in the Linux kernel’s TUN/TAP device driver functionality in how a user generates a malicious (too big) networking packet when napi frags is enabled. This flaw allows a local user to crash or potentially escalate their privileges on the system. | |||||
| CVE-2023-3773 | 4 Debian, Fedoraproject, Linux and 1 more | 4 Debian Linux, Fedora, Linux Kernel and 1 more | 2026-11-07 | N/A | 5.5 MEDIUM |
| A flaw was found in the Linux kernel’s IP framework for transforming packets (XFRM subsystem). This issue may allow a malicious user with CAP_NET_ADMIN privileges to cause a 4 byte out-of-bounds read of XFRMA_MTIMER_THRESH when parsing netlink attributes, leading to potential leakage of sensitive heap data to userspace. | |||||
| CVE-2023-3772 | 4 Debian, Fedoraproject, Linux and 1 more | 6 Debian Linux, Fedora, Linux Kernel and 3 more | 2026-11-07 | N/A | 5.5 MEDIUM |
| A flaw was found in the Linux kernel’s IP framework for transforming packets (XFRM subsystem). This issue may allow a malicious user with CAP_NET_ADMIN privileges to directly dereference a NULL pointer in xfrm_update_ae_params(), leading to a possible kernel crash and denial of service. | |||||
| CVE-2023-3397 | 1 Linux | 1 Linux Kernel | 2026-11-07 | N/A | 7.0 HIGH |
| A race condition occurred between the functions lmLogClose and txEnd in JFS, in the Linux Kernel, executed in different threads. This flaw allows a local attacker with normal user privileges to crash the system or leak internal kernel information. | |||||
| CVE-2023-39197 | 2 Fedoraproject, Linux | 2 Fedora, Linux Kernel | 2026-11-07 | N/A | 4.0 MEDIUM |
| An out-of-bounds read vulnerability was found in Netfilter Connection Tracking (conntrack) in the Linux kernel. This flaw allows a remote user to disclose sensitive information via the DCCP protocol. | |||||
| CVE-2023-4273 | 5 Debian, Fedoraproject, Linux and 2 more | 12 Debian Linux, Fedora, Linux Kernel and 9 more | 2026-11-07 | N/A | 6.0 MEDIUM |
| A flaw was found in the exFAT driver of the Linux kernel. The vulnerability exists in the implementation of the file name reconstruction function, which is responsible for reading file name entries from a directory index and merging file name parts belonging to one file into a single long file name. Since the file name characters are copied into a stack variable, a local privileged attacker could use this flaw to overflow the kernel stack. | |||||
| CVE-2023-4194 | 4 Debian, Fedoraproject, Linux and 1 more | 4 Debian Linux, Fedora, Linux Kernel and 1 more | 2026-11-07 | N/A | 5.5 MEDIUM |
| A flaw was found in the Linux kernel's TUN/TAP functionality. This issue could allow a local user to bypass network filters and gain unauthorized access to some resources. The original patches fixing CVE-2023-1076 are incorrect or incomplete. The problem is that the following upstream commits - a096ccca6e50 ("tun: tun_chr_open(): correctly initialize socket uid"), - 66b2c338adce ("tap: tap_open(): correctly initialize socket uid"), pass "inode->i_uid" to sock_init_data_uid() as the last parameter and that turns out to not be accurate. | |||||
| CVE-2023-4133 | 3 Fedoraproject, Linux, Redhat | 3 Fedora, Linux Kernel, Enterprise Linux | 2026-11-07 | N/A | 5.5 MEDIUM |
| A use-after-free vulnerability was found in the cxgb4 driver in the Linux kernel. The bug occurs when the cxgb4 device is detaching due to a possible rearming of the flower_stats_timer from the work queue. This flaw allows a local user to crash the system, causing a denial of service condition. | |||||