p PatchFirst

PatchFirst · Vulnerabilidades recientes

Vulnerabilidades de linux-aws-5.13 · Página 66

Vulnerabilidades publicadas para linux-aws-5.13 en los últimos 30 días: 1054. Incluidas en el catálogo KEV: 0.

Filtrar vulnerabilidades
Borrar filtros

Vulnerabilidades: 19230

  1. CVE-2026-97926

    Alta · CVSS 7EPSS 0,15%Sin corrección publicada

    ufs: validate cylinder group metadata before caching it

    In the Linux kernel, the following vulnerability has been resolved: ufs: validate cylinder group metadata before caching it ufs_read_cylinder() copies the cylinder group index and the rotor positions straight from the on-disk group and caches them without any check: ucpi->c_cgx = fs32_to_cpu(sb, ucg->cg_cgx); ucpi->c_rotor = fs32_to_cpu(sb, ucg->cg_rotor); ucpi->c_frotor = fs32_to_cpu(sb, ucg->cg_frotor); ucpi->c_irotor = fs32_to_cpu(sb, ucg->cg_irotor); They are then used as indices during allocation and free: - c_cgx indexes the cylinder summary array as UFS_SB(sb)->fs_cs(ucpi->c_cgx), so a value past s_ncg writes a 32

    Publicación Actualización
  2. CVE-2026-97925

    Sin evaluarEPSS 0,21%Sin corrección publicada

    tick/broadcast: Plug clockevents replacement race

    In the Linux kernel, the following vulnerability has been resolved: tick/broadcast: Plug clockevents replacement race 朱恺乾 reported and decoded the following race condition when a broadcast device is replaced: CPUA CPUB __tick_broadcast_oneshot_control() bc = tick_broadcast_device.evtdev; tick_install_broadcast_device(dev) clockevents_exchange_device(cur, dev) shutdown(cur); detach(cur); cur->handler = noop; tick_broadcast_device.evtdev = dev; tick_broadcast_set_event(bc, next_event); <- FAIL: arms a detached device. If the original broadcast device has a restricted interrupt affi

    Publicación Actualización
  3. CVE-2026-97924

    Sin evaluarEPSS 0,21%Sin corrección publicada

    tracing/user_events: Don't destroy fields when event removal fails

    In the Linux kernel, the following vulnerability has been resolved: tracing/user_events: Don't destroy fields when event removal fails destroy_user_event() destroys the event's fields before attempting to remove the trace event call. If user_event_set_call_visible() fails, e.g. because the event is still enabled and trace_remove_event_call() returns -EBUSY, the event is left registered with an irreversibly destroyed field list. Any subsequent interaction with the event then operates on an empty field list while it is still fully visible in tracefs. Move the field destruction after the call removal, and splice the field list back onto the e

    Publicación Actualización
  4. CVE-2026-97923

    Sin evaluarEPSS 0,21%Sin corrección publicada

    tracing: Free histogram the var ref when its initialization fails

    In the Linux kernel, the following vulnerability has been resolved: tracing: Free histogram the var ref when its initialization fails create_var_ref() allocates a VAR_REF hist_field and then calls init_var_ref() to fill it in. When that fails the field is leaked. commit 656fe2ba85e8 ("tracing: Use hist trigger's var_ref array to destroy var_refs") made destroy_hist_field() return early for HIST_FIELD_FL_VAR_REF, since var refs are freed by walking the trigger's var_refs[] array instead. create_var_ref() adds the field to that array only after init_var_ref() has succeeded, so on this path the field is in neither place and nothing frees it.

    Publicación Actualización
  5. CVE-2026-97922

    Sin evaluarEPSS 0,21%Sin corrección publicada

    tracing: Free histogram var refs regardless of how often they are referenced

    In the Linux kernel, the following vulnerability has been resolved: tracing: Free histogram var refs regardless of how often they are referenced Using the same variable three or more times in one hist trigger leaks the variable reference and its strings when the trigger is removed. commit 656fe2ba85e8 ("tracing: Use hist trigger's var_ref array to destroy var_refs") made a trigger's var_refs[] array the only owner of a var ref: destroy_hist_field() returns early for HIST_FIELD_FL_VAR_REF, so the field expressions never destroy one. One entry, freed once, no count needed. commit 8bcebc77e85f ("tracing: Fix histogram code when expression ha

    Publicación Actualización
  6. CVE-2026-97921

    Sin evaluarEPSS 0,21%Sin corrección publicada

    tracing: Free histogram the field rejected for a bad modifier

    In the Linux kernel, the following vulnerability has been resolved: tracing: Free histogram the field rejected for a bad modifier Writing a hist trigger whose value or variable carries a modifier that is not allowed there leaks the fields that were built for it. __create_val_field() takes the field from parse_expr() and stores it in hist_data->fields[] only after the modifier checks have run: hist_field = parse_expr(hist_data, file, field_str, flags, var_name, &n_subexprs); ... if (hist_field->flags & HIST_FIELD_FL_VAR) { if (hist_field->flags & (...)) goto err; } else { if (hist_field->flags & (...)) goto err; } hist

    Publicación Actualización
  7. CVE-2026-97920

    Sin evaluarEPSS 0,21%Sin corrección publicada

    tracing: Keep the entry count when the histogram stats allocation fails

    In the Linux kernel, the following vulnerability has been resolved: tracing: Keep the entry count when the histogram stats allocation fails print_entries() uses n_entries both as the number of sort entries and as its own return value, so the -ENOMEM it stores when the stats allocation fails overwrites the count that the cleanup still needs: n_entries = tracing_map_sort_entries(map, ...); if (n_entries < 0) return n_entries; ... if (!stats) { n_entries = -ENOMEM; goto out; } ... out: tracing_map_destroy_sort_entries(sort_entries, n_entries); tracing_map_destroy_sort_entries() takes an unsigned int and loops up to it,

    Publicación Actualización
  8. CVE-2026-97919

    Sin evaluarEPSS 0,21%Sin corrección publicada

    tracing: Take the reference before publishing the named histogram trigger

    In the Linux kernel, the following vulnerability has been resolved: tracing: Take the reference before publishing the named histogram trigger event_hist_trigger_named_init() puts the trigger on the global named_triggers list and only then takes the reference on the trigger it shares its histogram with: data->ref++; save_named_trigger(data->named_data->name, data); ret = event_hist_trigger_init(data->named_data); if (ret < 0) { kfree(data->cmd_ops); data->cmd_ops = &trigger_hist_cmd; } return ret; event_hist_trigger_init() fails when alloc_hist_pad() cannot allocate, and nothing takes the trigger back off the list on the way o

    Publicación Actualización
  9. CVE-2026-97918

    Sin evaluarEPSS 0,21%Sin corrección publicada

    tracing: Undo the registration when enabling the histogram trigger fails

    In the Linux kernel, the following vulnerability has been resolved: tracing: Undo the registration when enabling the histogram trigger fails Commit 6f86bdeab633 ("tracing: Fix bad hist from corrupting named_triggers list") described how a trigger that is registered but not on file->triggers ends up freed while still on the global named_triggers list, and moved the registration down so that hist_trigger_enable() follows it immediately. One path still gets there. hist_trigger_enable() adds the trigger and takes it straight back out when the event cannot be enabled: list_add_tail_rcu(&data->list, &file->triggers); update_cond_flag(file);

    Publicación Actualización
  10. CVE-2026-97917

    Sin evaluarEPSS 0,2%Sin corrección publicada

    accel/ivpu: Validate full buffer range in ivpu_to_cpu_addr

    In the Linux kernel, the following vulnerability has been resolved: accel/ivpu: Validate full buffer range in ivpu_to_cpu_addr Add a size parameter to ivpu_to_cpu_addr() and validate that the whole [vpu_addr, vpu_addr + size) range stays within the BO.

    Publicación Actualización
  11. CVE-2026-97916

    Sin evaluarEPSS 0,2%Sin corrección publicada

    accel/ivpu: Validate firmware log buffer metadata

    In the Linux kernel, the following vulnerability has been resolved: accel/ivpu: Validate firmware log buffer metadata The tracing log headers parsed by fw_log_print_buffer() reside in DMA-shared BOs that the NPU firmware can write to. fw_log_from_bo() validated log->header_size and log->size, but fw_log_print_buffer() re-read those same fields from shared memory afterwards, allowing a TOCTOU where firmware changes them between the check and the use, and making the host dereference out-of-bounds addresses while printing logs. Snapshot the validated values once with READ_ONCE() and pass them down explicitly in a new struct ivpu_fw_log_desc

    Publicación Actualización
  12. CVE-2026-97915

    Sin evaluarEPSS 0,2%Sin corrección publicada

    accel/ivpu: Limit firmware log name prints to field size

    In the Linux kernel, the following vulnerability has been resolved: accel/ivpu: Limit firmware log name prints to field size The name in struct vpu_tracing_buffer_header is a fixed-size array populated by the NPU firmware. It is expected to be NUL-terminated, but nothing on the host side enforces this, so printing it with an unbounded string conversion would read past the field if the terminator is ever missing and expose adjacent bytes of the shared tracing BO through dmesg and the debugfs FW log output. Print at most as many characters as the name field holds, so the output never runs past it even if the string is not NUL-terminated.

    Publicación Actualización
  13. CVE-2026-97914

    Sin evaluarEPSS 0,19%Sin corrección publicada

    accel: ethosu: Fix ethosu_job_open() return value

    In the Linux kernel, the following vulnerability has been resolved: accel: ethosu: Fix ethosu_job_open() return value A WARN_ON() returns a 0 or 1, not the original negative errno. Just drop the WARN_ON() as the FD open will pass the return code to userspace and there's only one possible source of the error (drm_sched_entity_init()).

    Publicación Actualización
  14. CVE-2026-97913

    Sin evaluarEPSS 0,19%Sin corrección publicada

    accel: ethosu: Ensure cmd stream ends with a stop op

    In the Linux kernel, the following vulnerability has been resolved: accel: ethosu: Ensure cmd stream ends with a stop op While the QSIZE register setting should prevent an out of bounds access of the command stream, it is not clear whether the h/w generates an interrupt in this case as is required (to prevent a timeout). As a stop op is expected end of the command stream, let's just ensure it is present. A stop op in the middle of the command stream also makes no sense.

    Publicación Actualización
  15. CVE-2026-97912

    Sin evaluarEPSS 0,19%Sin corrección publicada

    accel: ethosu: Ensure SRAM size is 0 on mapping failure

    In the Linux kernel, the following vulnerability has been resolved: accel: ethosu: Ensure SRAM size is 0 on mapping failure On a mapping failure of the SRAM, the SRAM size is left as non-zero. The probe will succeed as the error return is not checked since having SRAM is not a hard requirement. The non-zero size allows jobs to access SRAM which is left pointing to physical base address 0x0.

    Publicación Actualización
  16. CVE-2026-97911

    Alta · CVSS 7.8EPSS 0,15%Sin corrección publicada

    accel: ethosu: Ensure SRAM region size matches job

    In the Linux kernel, the following vulnerability has been resolved: accel: ethosu: Ensure SRAM region size matches job It is possible for userspace to set the job SRAM size to 0, but then still have SRAM accesses in the command stream. When the job SRAM size is 0, setting the region base register is skipped and a stale base address from a prior job is used. Check the region size against the job's SRAM size instead of just the size of the SRAM. The job's SRAM size was already checked against the total SRAM size.

    Publicación Actualización
  17. CVE-2026-97910

    Alta · CVSS 7.8EPSS 0,16%Sin corrección publicada

    ASoC: sprd: validate compress buffer sizes against fixed allocations

    In the Linux kernel, the following vulnerability has been resolved: ASoC: sprd: validate compress buffer sizes against fixed allocations sprd_platform_compr_open() allocates the stage 0 IRAM buffer (32K data area) and the stage 1 DDR buffer (2M data area) with fixed sizes, but sprd_platform_compr_copy() derives all copy lengths from the user controlled runtime->fragment_size and the write() count, never comparing them against the physical buffer sizes. The compress core only checks fragment_size * fragments for an u32 overflow in snd_compress_check_input(), so a local user can configure a logical buffer of up to ~4GB via SNDRV_COMPRESS_SET_

    Publicación Actualización
  18. CVE-2026-97909

    Sin evaluarEPSS 0,21%Sin corrección publicada

    ASoC: sti: initialize IRQ lock before requesting IRQ

    In the Linux kernel, the following vulnerability has been resolved: ASoC: sti: initialize IRQ lock before requesting IRQ uni_reader_init() registers the shared IRQ before initializing reader->irq_lock. A pending interrupt can invoke the handler while the lock is still uninitialized. Initialize the lock before registering the IRQ so the interrupt path always sees valid lock state.

    Publicación Actualización
  19. CVE-2026-97908

    Sin evaluarEPSS 0,21%Sin corrección publicada

    Bluetooth: btqcomsmd: destroy RPMsg endpoints before freeing hci_dev

    In the Linux kernel, the following vulnerability has been resolved: Bluetooth: btqcomsmd: destroy RPMsg endpoints before freeing hci_dev The command and ACL RPMsg endpoints store struct btqcomsmd as their callback private data. The receive callbacks dereference btq->hdev without taking an hci_dev reference. The current teardown order frees the hci_dev before destroying the RPMsg endpoints in both the hci_register_dev() error path and the driver remove path. If WCNSS delivers data in that window, the endpoint callback can run with an already freed hci_dev and pass it to the Bluetooth core. For qcom_smd endpoints, rpmsg_destroy_ept() closes

    Publicación Actualización
  20. CVE-2026-97907

    Sin evaluarEPSS 0,2%Sin corrección publicada

    Bluetooth: btrtl: Don't leak return code when parsing firmware format v2

    In the Linux kernel, the following vulnerability has been resolved: Bluetooth: btrtl: Don't leak return code when parsing firmware format v2 When key_id from chip is zero, rtlbt_parse_firmware_v2() intentionally ignores all security headers. However, the implementation simply breaks from a switch statement and leaks uninitialized return code `rc' (if the first section is a security one) or the previous section's `rc'. Fix it by really skipping a loop with `continue'. For consistency and readability, also do the same for the default case.

    Publicación Actualización

Comprueba tu servidor

Compara tu pila y las versiones instaladas con las bases actuales de vulnerabilidades.

Comprueba tu servidor →