Filtered by vendor Linux
Subscribe
Total
19806 CVE
| CVE | Vendors | Products | Updated | CVSS v2 | CVSS v3 |
|---|---|---|---|---|---|
| CVE-2026-47622 | 2 Linux, Nvidia | 2 Linux Kernel, Dynamo | 2026-10-24 | N/A | 5.3 MEDIUM |
| NVIDIA Dynamo for Linux contains a vulnerability where an attacker could cause the generation of error messages that contain sensitive information. A successful exploit of this vulnerability might lead to information disclosure. | |||||
| CVE-2026-47617 | 2 Linux, Nvidia | 2 Linux Kernel, Dynamo | 2026-10-24 | N/A | 7.5 HIGH |
| NVIDIA Dynamo for Linux contains a vulnerability in the multimodal media fetcher where an attacker may cause server-side request forgery via DNS rebinding. A successful exploit of this vulnerability might lead to information disclosure. | |||||
| CVE-2026-47612 | 2 Linux, Nvidia | 2 Linux Kernel, Dynamo | 2026-10-24 | N/A | 7.5 HIGH |
| NVIDIA Dynamo for Linux contains a vulnerability in the image loading component where an attacker may cause improper limitation of a pathname to a restricted directory. A successful exploit of this vulnerability might lead to information disclosure. | |||||
| CVE-2026-47621 | 2 Linux, Nvidia | 2 Linux Kernel, Dynamo | 2026-10-24 | N/A | 6.5 MEDIUM |
| NVIDIA Dynamo for Linux contains a vulnerability where an attacker could cause a race condition in the LoRA manager singleton initialization. A successful exploit of this vulnerability might lead to denial of service and data tampering. | |||||
| CVE-2026-47487 | 2 Linux, Nvidia | 2 Linux Kernel, Triton Inference Server | 2026-10-24 | N/A | 4.4 MEDIUM |
| NVIDIA Triton Inference Server for Linux contains a vulnerability where a user could cause files outside the model repository to be read, written to, or modified by providing a path in the model name to the Triton MLflow plugin. A successful exploit of this vulnerability might lead to denial of service and information disclosure. | |||||
| CVE-2026-24254 | 2 Linux, Nvidia | 2 Linux Kernel, Dynamo | 2026-10-24 | N/A | 9.8 CRITICAL |
| NVIDIA Dynamo for Linux contains a vulnerability in the multimodal serving topology, where an attacker could cause an out-of-bounds write. A successful exploit of this vulnerability might lead to code execution, escalation of privileges, data tampering, denial of service, and information disclosure. | |||||
| CVE-2026-47615 | 2 Linux, Nvidia | 2 Linux Kernel, Dynamo | 2026-10-24 | N/A | 7.5 HIGH |
| NVIDIA Dynamo for Linux contains a vulnerability where an attacker may cause server-side request forgery by supplying a crafted URL in a multimodal request. A successful exploit of this vulnerability might lead to information disclosure. | |||||
| CVE-2026-47618 | 2 Linux, Nvidia | 2 Linux Kernel, Dynamo | 2026-10-24 | N/A | 7.5 HIGH |
| NVIDIA Dynamo for Linux contains a vulnerability in the Rust multimodal media fetcher where an attacker could cause server-side request forgery. A successful exploit of this vulnerability might lead to information disclosure. | |||||
| CVE-2026-64312 | 1 Linux | 1 Linux Kernel | 2026-10-24 | N/A | 7.5 HIGH |
| In the Linux kernel, the following vulnerability has been resolved: crypto: pcrypt - restore callback for non-parallel fallback pcrypt installs pcrypt_aead_done() on the child AEAD request before trying to submit it through padata. If padata_do_parallel() returns -EBUSY, pcrypt falls back to calling the child AEAD directly. That fallback must not keep the padata completion callback. Otherwise an asynchronous completion runs pcrypt_aead_done() even though the request was never enrolled in padata. Restore the original request callback and callback data before calling the child AEAD directly. This keeps the fallback path aligned with a direct AEAD request while leaving the parallel path unchanged. | |||||
| CVE-2026-64274 | 1 Linux | 1 Linux Kernel | 2026-10-24 | N/A | 7.8 HIGH |
| In the Linux kernel, the following vulnerability has been resolved: Input: goodix - clamp the device-reported contact count goodix_ts_read_input_report() copies the number of touch points reported by the device into an on-stack buffer u8 point_data[2 + GOODIX_MAX_CONTACT_SIZE * GOODIX_MAX_CONTACTS]; which is sized for at most GOODIX_MAX_CONTACTS (10) contacts. The only runtime check bounds the per-interrupt count against ts->max_touch_num, but that value is taken verbatim from a 4-bit field of the device configuration block and is never clamped: ts->max_touch_num = ts->config[MAX_CONTACTS_LOC] & 0x0f; The nibble can be 0..15, so a malfunctioning, malicious or counterfeit controller (or an attacker tampering with the I2C bus) can advertise up to 15 contacts. goodix_ts_read_input_report() then accepts a touch_num of up to 15 and the second goodix_i2c_read() writes ts->contact_size * (touch_num - 1) bytes past the one-contact header into point_data - up to 30 bytes (45 with the 9-byte report format) beyond the 92-byte buffer: a stack out-of-bounds write. Clamp max_touch_num to GOODIX_MAX_CONTACTS, the number of contacts point_data[] is sized for, when reading it from the configuration. | |||||
| CVE-2026-64314 | 1 Linux | 1 Linux Kernel | 2026-10-24 | N/A | 5.5 MEDIUM |
| In the Linux kernel, the following vulnerability has been resolved: crypto: chacha20poly1305 - validate poly1305 template argument chachapoly_create() still accepts the compatibility poly1305 parameter in the template name, but it assumes the second template argument is always present and immediately passes it to strcmp(). When the argument is missing, crypto_attr_alg_name() returns an error pointer. Check for that before comparing the name so malformed template instantiations fail with an error instead of dereferencing the error pointer in strcmp(). This matches the surrounding Crypto API template pattern where crypto_attr_alg_name() results are validated before string-specific use. | |||||
| CVE-2026-24252 | 2 Linux, Nvidia | 2 Linux Kernel, Nemo | 2026-10-24 | N/A | 7.8 HIGH |
| NVIDIA NeMo for Linux contains a vulnerability where an attacker may cause OS command injection. A successful exploit of this vulnerability may lead to code execution, data tampering, escalation of privileges and information disclosure. | |||||
| CVE-2026-64276 | 1 Linux | 1 Linux Kernel | 2026-10-24 | N/A | 7.8 HIGH |
| In the Linux kernel, the following vulnerability has been resolved: Input: synaptics-rmi4 - bound the F30 keymap to the GPIO/LED count rmi_f30_map_gpios() allocates gpioled_key_map with min(gpioled_count, TRACKSTICK_RANGE_END) == at most 6 entries, but rmi_f30_attention() iterates the full f30->gpioled_count (device query register, range 0..31) and dereferences gpioled_key_map[i], and input->keycodemax is set to the full gpioled_count while input->keycode points at the 6-entry allocation. A device that reports gpioled_count > 6 with GPIO support enabled therefore causes an out-of-bounds read on the attention interrupt and out-of-bounds read/write through the EVIOCGKEYCODE/EVIOCSKEYCODE ioctls, which bound the index only against keycodemax. This is the same defect as the F3A handler, which was copied from F30. Size the keymap for the full gpioled_count; the mapping loop still assigns only the first min(gpioled_count, TRACKSTICK_RANGE_END) entries. | |||||
| CVE-2026-49745 | 3 Google, Imaginationtech, Linux | 3 Android, Ddk, Linux Kernel | 2026-10-24 | N/A | 7.8 HIGH |
| Kernel software installed and running inside a Guest VM may post improper commands to the GPU Firmware to trigger a write of data outside the Guest's virtualised GPU memory. Software installed and run under a Guest VM can send commands to the GPU which result in out of bounds memory accesses. These can be used to escalate privileges. | |||||
| CVE-2026-49744 | 3 Google, Imaginationtech, Linux | 3 Android, Ddk, Linux Kernel | 2026-10-24 | N/A | 7.8 HIGH |
| Kernel software installed and running inside a Guest VM may post improper commands to the GPU Firmware to trigger a write of data outside the Guest's virtualised GPU memory. Out of bounds accesses triggered by malware introduced to a Guest KMD could allow privilege escalation which escapes virtualization boundaries. | |||||
| CVE-2026-64311 | 1 Linux | 1 Linux Kernel | 2026-10-24 | N/A | 7.8 HIGH |
| In the Linux kernel, the following vulnerability has been resolved: crypto: loongson - Remove broken and unused loongson-rng The loongson-rng rng_alg has several vulnerabilities, including not providing forward security, and a use-after-free bug due to the use of wait_for_completion_interruptible(). Meanwhile, the rng_alg framework doesn't really have any purpose in the first place other than to access the software algorithms crypto/drbg.c and crypto/jitterentropy.c. Hardware-specific rng_algs have no in-kernel user, and unlike hwrng there's no feed into the actual Linux RNG. As such, there's really no point to this code. There are of course other rng_alg drivers that are similarly unused, but they're similarly in the process of being phased out, e.g. https://lore.kernel.org/r/20260529193648.18172-1-ebiggers@kernel.org and https://lore.kernel.org/r/20260529220430.34135-1-ebiggers@kernel.org Given that, there's no point in fixing forward these vulnerabilities, and it makes much more sense to simply roll back the addition of this driver. If this platform provides TRNG (not PRNG) functionality, it could make sense to add a hwrng driver, but it would be quite different. | |||||
| CVE-2026-64277 | 1 Linux | 1 Linux Kernel | 2026-10-24 | N/A | 7.8 HIGH |
| In the Linux kernel, the following vulnerability has been resolved: Input: synaptics-rmi4 - bound the F3A keymap to the GPIO count rmi_f3a_initialize() takes the GPIO count from the device query register (f3a->gpio_count = buf & RMI_F3A_GPIO_COUNT, range 0..127). rmi_f3a_map_gpios() then allocates gpio_key_map with min(gpio_count, TRACKSTICK_RANGE_END) == at most 6 entries, but rmi_f3a_attention() iterates the full gpio_count and dereferences gpio_key_map[i], and input->keycodemax is set to the full gpio_count while input->keycode points at the 6-entry allocation. A device that reports gpio_count > 6 therefore causes an out-of-bounds read of gpio_key_map[] on every attention interrupt, and out-of-bounds accesses through the input core's default keymap ioctls: EVIOCGKEYCODE reads past the buffer (leaking adjacent slab memory to user space) and EVIOCSKEYCODE writes a caller-controlled value past it, for any process able to open the evdev node, since input_default_getkeycode() and input_default_setkeycode() only bound the index against keycodemax. Size the keymap for the full gpio_count. The mapping loop is unchanged: it still assigns only the first min(gpio_count, TRACKSTICK_RANGE_END) entries; the remaining slots stay KEY_RESERVED (devm_kcalloc zero-fills) and are skipped when reporting. | |||||
| CVE-2026-64273 | 1 Linux | 1 Linux Kernel | 2026-10-24 | N/A | 7.8 HIGH |
| In the Linux kernel, the following vulnerability has been resolved: Input: iforce - bound the device-reported force-feedback effect index iforce_process_packet() handles a status report (packet id 0x02) by taking a force-feedback effect index straight from the device wire and using it to address the per-effect state array: i = data[1] & 0x7f; if (data[1] & 0x80) { if (!test_and_set_bit(FF_CORE_IS_PLAYED, iforce->core_effects[i].flags)) ... } else if (test_and_clear_bit(FF_CORE_IS_PLAYED, iforce->core_effects[i].flags)) { ... } The index is masked only with 0x7f, so it ranges 0..127, but core_effects[] holds only IFORCE_EFFECTS_MAX (32) entries. For an index of 32..127 the test_and_set_bit()/test_and_clear_bit() is an out-of-bounds single-bit read-modify-write past the array. core_effects[] is the second-to-last member of struct iforce, so the write lands in the trailing members and beyond the embedding kzalloc()'d iforce_serio / iforce_usb object. data[1] is unvalidated device payload on both transports (the USB interrupt endpoint and serio), and the status path is not gated on force feedback being present, so a malicious or counterfeit device can set or clear a bit at an attacker-chosen offset past the object. Reject an out-of-range index instead of indexing with it. Bound against the array dimension IFORCE_EFFECTS_MAX rather than dev->ff->max_effects so the check guarantees memory safety regardless of how many effects the device registered. A legitimate "effect started/stopped" status always carries an index below IFORCE_EFFECTS_MAX, so well-formed devices are unaffected; the neighbouring mark_core_as_ready() loop is already bounded and is left untouched. | |||||
| CVE-2026-12702 | 3 Linux, Microsoft, Octopus | 3 Linux Kernel, Windows, Octopus Server | 2026-10-24 | N/A | 4.9 MEDIUM |
| In affected versions of Octopus Deploy Insufficient checks on the project trigger actions allows an unauthorized user to trigger a deployment. | |||||
| CVE-2026-64315 | 1 Linux | 1 Linux Kernel | 2026-10-24 | N/A | 7.0 HIGH |
| In the Linux kernel, the following vulnerability has been resolved: crypto: caam - use print_hex_dump_devel to guard key hex dumps Use print_hex_dump_devel() for dumping sensitive key material in *_setkey() to avoid leaking secrets at runtime when CONFIG_DYNAMIC_DEBUG is enabled. | |||||