Export limit exceeded: 26181 CVEs match your query. Please refine your search to export 10,000 CVEs or fewer.
Search
Search Results (26181 CVEs found)
| CVE | Vendors | Products | Updated | CVSS v3.1 |
|---|---|---|---|---|
| CVE-2026-99218 | 1 Linux | 2 Linux, Linux Kernel | 2026-11-03 | 7 High |
| In the Linux kernel, the following vulnerability has been resolved: coredump: hold RCU while releasing parked threads coredump_finish() releases the parked threads by clearing ->task in their core_thread entry and calling wake_up_process() on each of them. It does that without holding a reference on the task and without being inside rcu. But calling wake_up_process(task) without rcu here isn't safe. A parked thread doesn't need that wakeup to leave. A spurious wakeup or a preemption after the store is enough for the task to go away. So if the coredump client is preempted between the store and wake_up_process() the thread can exit and be freed in the meantime and try_to_wake_up() takes pi_lock in freed memory. Hold rcu across the loop. | ||||
| CVE-2026-98058 | 1 Linux | 1 Linux Kernel | 2026-11-03 | 5.5 Medium |
| In the Linux kernel, the following vulnerability has been resolved: bpf: Mark syscall helpers as sleepable bpf_sys_bpf() executes the bpf(2) syscall body, which can take mutexes, allocate with GFP_KERNEL, and wait for an RCU grace period. bpf_sys_close() reaches close_fd() and filp_close(), which can sleep as well. Both helpers are limited to BPF_PROG_TYPE_SYSCALL, whose main program is sleepable. That does not make every callback sleepable: a syscall program can register a bpf_timer callback, and the verifier checks that callback in a non-sleepable context while retaining the syscall helper set. Without .might_sleep on the prototypes, such a callback can invoke bpf_sys_bpf() from hrtimer softirq context and trigger a scheduling-while-atomic failure. bpf_sys_close() is exposed through the same missing context check. Set .might_sleep on both prototypes so the existing helper-context check rejects them from timer callbacks and other atomic regions. Calls from the sleepable main body remain valid. | ||||
| CVE-2026-99250 | 1 Linux | 2 Linux, Linux Kernel | 2026-11-03 | N/A |
| In the Linux kernel, the following vulnerability has been resolved: printk: Postpone kthread startup There have been various bug reports related to SMP systems hanging on boot. The reports vary but seem to have some overlap with regard to missed IPI's during SMP setup. The reports also show that reverting NBCON console usage allows the bugs to disappear. The NBCON kthreads for console printing are started very early during boot using early_initcall(). Since these kthreads are asynchronously enabling/disabling interrupts during early boot, they may be interfering with early SMP setup on some hardware platforms. Starting the console printing kthreads later has shown to avoid the hanging on systems that could previously reproduce the issue. Postpone kthread starting until after all arch initcalls have completed. | ||||
| CVE-2026-99259 | 1 Linux | 2 Linux, Linux Kernel | 2026-11-03 | N/A |
| In the Linux kernel, the following vulnerability has been resolved: soc/tegra: pmc: Fix uninitialised clock rate For legacy 32-bit Tegra devices, the warning in the tegra_pmc_enter_suspend_mode() function is being triggered because the early_pmc->rate variable is never configured and hence, always 0. This issue started occurring after updating the PMC driver to create the PMC context dynamically which causes the 'rate' to be set in the new dynamic context, but missed updating the rate in the early PMC context. Fix this by initialising the early_pmc->rate variable for 32-bit Tegra devices when the rate for the PMC context is initialised. [treding@nvidia.com: move assignment to existing #ifdef block] | ||||
| CVE-2026-99248 | 1 Linux | 2 Linux, Linux Kernel | 2026-11-03 | N/A |
| In the Linux kernel, the following vulnerability has been resolved: i2c: xiic: restore non-managed runtime PM to fix clk WARN flood The devres conversion replaced manual pm_runtime_enable()/disable() with devm_pm_runtime_set_active_enabled() and dropped the remove-time runtime PM teardown. The managed release tears runtime PM down in the wrong order: it calls pm_runtime_dont_use_autosuspend() before pm_runtime_disable(), i.e. while runtime PM is still enabled, and devres is LIFO so the devm_clk_get_enabled() release runs afterwards. At remove(), pm_runtime_put_sync() leaves the device active with the autosuspend timer armed. Clearing use_autosuspend then makes rpm_idle() suspend immediately, and xiic_i2c_runtime_suspend() clk_disable()s the clock. The later devm_clk_get_enabled() release clk_disable_unprepare()s the already-disabled clock, so clk_core_disable() WARNs ("clkN already disabled") on every teardown. Drop the managed helper and restore the non-managed runtime PM setup and teardown, so runtime PM is enabled once in probe and disabled once in remove and the clock enable count stays balanced. Order the remove teardown so runtime PM is disabled before the usage count is dropped: pm_runtime_disable() followed by pm_runtime_put_noidle() instead of pm_runtime_put_sync(). Dropping the count first with autosuspend still enabled arms the autosuspend timer, and a preemption before pm_runtime_disable() lets it expire, suspend the device and clk_disable() the clock, which the devm release then disables again - the same WARN. Restore the non-managed IRQ request as well. The probe error paths now unwind runtime PM by hand via goto, and a devm-registered handler is only freed later during devres unwind, so it would stay live across the manual teardown (and across any future failing step added after it). Request the IRQ with request_threaded_irq() and free it explicitly in the probe error path and in remove. The probe error path also clears use_autosuspend, to match the teardown in remove(). | ||||
| CVE-2026-99251 | 1 Linux | 2 Linux, Linux Kernel | 2026-11-03 | N/A |
| In the Linux kernel, the following vulnerability has been resolved: Drivers: hv: Avoid infinite retry loop in init_vp_index() There is a retry loop in init_vp_index() where the CPUs from a certain node are stripped out if they have already been in the allocated cpumask or not in HK_TYPE_MANAGED_IRQ housekeeping cpumask. If there is no CPU left, the allocated cpumask is ignored and the process is retried again. However, if the HK_TYPE_MANAGED_IRQ housekeeping cpumask turns out not to contain any CPU in that particular node, that will become an infinite retry loop. This particular problem was reported by sashiko [1]. This should rarely happen, but we still need to guard against this. Fix this infinite loop problem by also skipping NUMA node that has no housekeeping CPU in the inner while loop of init_vp_index(). Also update the early abort check to check for the absence of online housekeeping CPUs instead of just the emptiness of the cpumask. As the outer for loop will only be reached if the housekeeping cpumask has at least one online CPU, a NUMA node with housekeeping CPUs will eventually be found. | ||||
| CVE-2025-12767 | 2 Ibm, Linux | 2 Concert, Linux Kernel | 2026-11-03 | 5.3 Medium |
| IBM Concert 1.0.0 through 3.0.0 could allow a remote attacker to cause a denial of service using a specially crafted regular expression that would cause excessive resource consumption. | ||||
| CVE-2025-36084 | 2 Ibm, Linux | 2 Concert, Linux Kernel | 2026-11-03 | 5.9 Medium |
| IBM Concert 1.0.0 through 3.0.0 uses weaker than expected cryptographic algorithms that could allow an attacker to decrypt highly sensitive information. | ||||
| CVE-2026-15915 | 2 Ibm, Linux | 2 Concert, Linux Kernel | 2026-11-03 | 6.2 Medium |
| IBM Concert 1.0.0 through 3.0.0 could allow a local attacker to obtain sensitive information due to recursive copying of build context directories into container images. | ||||
| CVE-2026-16426 | 2 Ibm, Linux | 2 Concert, Linux Kernel | 2026-11-03 | 6.5 Medium |
| IBM Concert 1.0.0 through 3.0.0 is vulnerable to server-side request forgery (SSRF). This may allow an authenticated attacker to send unauthorized requests from the system, potentially leading to network enumeration or facilitating other attacks. | ||||
| CVE-2026-17465 | 2 Ibm, Linux | 2 Concert, Linux Kernel | 2026-11-03 | 6.5 Medium |
| IBM Concert 1.0.0 through 3.0.0 could allow a remote authenticated attacker to cause a denial of service due to improper enforcement of storage limits. | ||||
| CVE-2026-17472 | 2 Ibm, Linux | 2 Concert, Linux Kernel | 2026-11-03 | 9.6 Critical |
| IBM Concert 1.0.0 through 3.0.0 could allow a remote authenticated attacker to access or modify unauthorized resources due to the use of wildcards in RBAC permission definitions. | ||||
| CVE-2026-15661 | 2 Ibm, Linux | 2 Concert, Linux Kernel | 2026-11-03 | 5.3 Medium |
| IBM Concert 1.0 through 3.0.0 could allow an unauthorized user to inject data into log messages due to improper neutralization of special elements when written to log files. | ||||
| CVE-2026-6930 | 2 Ibm, Linux | 2 Concert, Linux Kernel | 2026-11-03 | 3.7 Low |
| IBM Concert 1.0 through 3.0.0 uses weaker than expected cryptographic algorithms that could allow an attacker to decrypt highly sensitive information. | ||||
| CVE-2026-1501 | 2 Ibm, Linux | 2 Concert, Linux Kernel | 2026-11-03 | 3.7 Low |
| IBM Concert 1.0 through 3.0.0 is vulnerable to Improper Certificate Validation. | ||||
| CVE-2026-1510 | 2 Ibm, Linux | 2 Concert, Linux Kernel | 2026-11-03 | 4.7 Medium |
| IBM Concert 1.0 through 3.0.0 is vulnerable to Information Disclosure via Heap Inspection. | ||||
| CVE-2026-3303 | 2 Ibm, Linux | 2 Concert, Linux Kernel | 2026-11-03 | 3.7 Low |
| IBM Concert 1.0 through 3.0.0 uses cross-origin resource sharing (CORS) which could allow an attacker to carry out privileged actions as the domain name is not being limited to only trusted domains. | ||||
| CVE-2026-3628 | 2 Ibm, Linux | 2 Concert, Linux Kernel | 2026-11-03 | 5.3 Medium |
| IBM Concert 1.0 through 3.0.0 allows information disclosure through exposure of schema suggestions. | ||||
| CVE-2026-99257 | 1 Linux | 2 Linux, Linux Kernel | 2026-11-03 | N/A |
| In the Linux kernel, the following vulnerability has been resolved: gpio: shared: gracefully handle no-device lookup of shared GPIOs We use platform lookup tables for shared GPIOs. This mechanism needs a struct device to work so fwnode-based lookup with no device associated currently causes a NULL-pointer deference. Adding this functionality will require a larger rework and it has never worked anyway so add a check that allows the kernel to gracefully handle this situation with an error ahead of implementing that functionality as a new feature. | ||||
| CVE-2026-4405 | 2 Ibm, Linux | 2 Concert, Linux Kernel | 2026-11-03 | 4 Medium |
| IBM Concert 1.0 through 3.0.0 allows web page cache to be stored locally which can be read by another user on the system. | ||||