p PatchFirst

PatchFirst · Свежие уязвимости

Уязвимости linux-azure-nvidia · Страница 81

За последние 30 дней в linux-azure-nvidia опубликовано уязвимостей: 797; в каталоге KEV: 0.

RSS ↗ JSON ↗
Фильтры уязвимостей
Сбросить фильтры

Уязвимостей: 8708

  1. CVE-2026-90198

    Без оценкиEPSS 0,23%Нет опубликованного исправления

    ALSA: core: Fix use-after-free in snd_card_do_free()

    In the Linux kernel, the following vulnerability has been resolved: ALSA: core: Fix use-after-free in snd_card_do_free() A use-after-free was detected in snd_card_do_free() when a sound card managed by devres is unbound while a user-space application still holds an open file descriptor. For managed cards, the memory is allocated using devres_alloc(), and its release function is set to __snd_card_release(), which calls snd_card_free(). When the device is unbound, the unbind thread calls snd_card_free(), which drops a reference to the card's device. If the user thread still has an open file descriptor, the reference count does not reach zero

    linux-azure-nvidiaОперационные системы
    Опубликовано Обновлено
    Исходное сообщение 1 ↗Исходное сообщение 2 ↗Исходное сообщение 3 ↗

  2. CVE-2026-90196

    Без оценкиEPSS 0,21%Нет опубликованного исправления

    ASoC: SOF: validate topology volume range before allocation

    In the Linux kernel, the following vulnerability has been resolved: ASoC: SOF: validate topology volume range before allocation SOF treats the topology mixer min and max values as non-negative indices into its volume table. It stores them in signed fields, allocates max + 1 entries through an int argument, and later indexes the table with the stored range. An inverted range is invalid, while a maximum at or above INT_MAX cannot be represented safely after the increment or in the signed fields. Validate the complete range before storing it or allocating the table.

    linux-azure-nvidiaОперационные системы
    Опубликовано Обновлено
    Исходное сообщение 1 ↗Исходное сообщение 2 ↗Исходное сообщение 3 ↗

  3. CVE-2026-90194

    Без оценкиEPSS 0,21%Нет опубликованного исправления

    ACPI: scan: fix bus ID cleanup on device_add() failures

    In the Linux kernel, the following vulnerability has been resolved: ACPI: scan: fix bus ID cleanup on device_add() failures When device_add() fails after acpi_device_set_name() has allocated an instance ID and a new acpi_device_bus_id has been linked into acpi_bus_id_list, the rollback path only removes wakeup_list and detaches the ACPI handle data. That leaves the bus-ID bookkeeping behind and keeps the allocated instance number consumed. Move the bus-ID cleanup and wakeup-list removal into a single helper. Use it from both the normal device teardown path and the device_add() rollback path. The wakeup list node is initialized before reg

    linux-azure-nvidiaОперационные системы
    Опубликовано Обновлено
    Исходное сообщение 1 ↗Исходное сообщение 2 ↗Исходное сообщение 3 ↗

  4. CVE-2026-90190

    Без оценкиEPSS 0,21%Нет опубликованного исправления

    null_blk: use DEFINE_MUTEX for the file-scope mutex

    In the Linux kernel, the following vulnerability has been resolved: null_blk: use DEFINE_MUTEX for the file-scope mutex In null_init(), mutex_init(&lock) currently happens after configfs_register_subsystem(), which exposes the nullb subsystem to userspace. A racing mkdir() into /sys/kernel/config/nullb/ can reach null_find_dev_by_name() -> mutex_lock(&lock) before the mutex is initialized, trigger warning: [ 123.137788] DEBUG_LOCKS_WARN_ON(lock->magic != lock) [ 123.137796] WARNING: kernel/locking/mutex.c:159 at mutex_lock+0x171/0x1c0, CPU#13: mkdir/1301 [ 123.140090] Modules linked in: null_blk(+) nft_fib_inet nft_fib_ipv4 ...... [ 12

    linux-azure-nvidiaОперационные системы
    Опубликовано Обновлено
    Исходное сообщение 1 ↗Исходное сообщение 2 ↗Исходное сообщение 3 ↗

  5. CVE-2026-90189

    Без оценкиEPSS 0,17%Нет опубликованного исправления

    null_blk: register configfs subsystem after creating default devices

    In the Linux kernel, the following vulnerability has been resolved: null_blk: register configfs subsystem after creating default devices In null_init(), configfs_register_subsystem() currently runs before register_blkdev(), so when null_blk is built as a module, a racing mkdir() + poweron from userspace can reach null_add_dev() while null_major is still 0. __add_disk() then hits WARN_ON(disk->minors) (major=0 with minors!=0) and fails: [root@fedora ~]# [ 2366.521436] WARNING: block/genhd.c:476 at __add_disk+0x8a7/0xde0, [ 2366.523552] Modules linked in: null_blk(+) nft_fib_inet nft_fib_ipv4 nft_fib_ipv6 nft_fib [ 2366.529081] CPU: 26 UID:

    linux-azure-nvidiaОперационные системы
    Опубликовано Обновлено
    Исходное сообщение 1 ↗Исходное сообщение 2 ↗Исходное сообщение 3 ↗

  6. CVE-2026-90188

    Без оценкиEPSS 0,21%Нет опубликованного исправления

    null_blk: free global tag_set on init error path

    In the Linux kernel, the following vulnerability has been resolved: null_blk: free global tag_set on init error path If shared_tags is enabled, null_setup_tagset() allocates the global tag_set via null_init_global_tag_set(). If device creation later fails, err_dev destroys the default devices and calls unregister_blkdev(), but never frees the global tag_set. Since module init failed, null_exit() is never invoked, so the global tag_set's tags and maps are permanently leaked. Free the global tag_set in err_dev, matching null_exit() which does if (tag_set.ops) blk_mq_free_tag_set(&tag_set).

    linux-azure-nvidiaОперационные системы
    Опубликовано Обновлено
    Исходное сообщение 1 ↗Исходное сообщение 2 ↗Исходное сообщение 3 ↗

  7. CVE-2026-90187

    Без оценкиEPSS 0,21%Нет опубликованного исправления

    null_blk: free zones array on device power-off

    In the Linux kernel, the following vulnerability has been resolved: null_blk: free zones array on device power-off null_init_zoned_dev() allocates dev->zones when a zoned device is powered on, but null_del_dev() never frees it on power-off; dev->zones is only freed later in null_free_dev(), when the configfs directory is removed. If the device is powered off and then on again, null_init_zoned_dev() allocates a new array and overwrites the dev->zones pointer, leaking the previous allocation each power cycle. Free dev->zones in null_del_dev() via null_free_zoned_dev() to solve it. And calling null_free_zoned_dev() in null_free_dev() is no lo

    linux-azure-nvidiaОперационные системы
    Опубликовано Обновлено
    Исходное сообщение 1 ↗Исходное сообщение 2 ↗Исходное сообщение 3 ↗

  8. CVE-2026-90186

    Без оценкиEPSS 0,21%Нет опубликованного исправления

    null_blk: reject per-device queue resize for shared tag set

    In the Linux kernel, the following vulnerability has been resolved: null_blk: reject per-device queue resize for shared tag set When shared_tags is enabled, null_setup_tagset() makes the device use the global tag_set, whose driver_data stays NULL. null_map_queues() therefore falls back to the module-wide g_submit_queues/g_poll_queues instead of any per-device value. Resizing submit_queues or poll_queues via configfs on such a device calls blk_mq_update_nr_hw_queues() on the shared set, shrinking set->nr_hw_queues. __blk_mq_realloc_hw_ctxs() only grows the q->queue_hw_ctx[] allocation, so on shrink it merely exits and NULLs the now-excess

    linux-azure-nvidiaОперационные системы
    Опубликовано Обновлено
    Исходное сообщение 1 ↗Исходное сообщение 2 ↗Исходное сообщение 3 ↗

  9. CVE-2026-90185

    Без оценкиEPSS 0,21%Нет опубликованного исправления

    null_blk: serialize configfs attribute stores with the lock

    In the Linux kernel, the following vulnerability has been resolved: null_blk: serialize configfs attribute stores with the lock The NULLB_DEVICE_ATTR _store takes no lock: apply_fn attributes (submit_queues, poll_queues) get dev->NAME written again after apply_fn returns, outside its lock; APPLY=NULL attributes are entirely lockless. configfs only serializes stores per-open-file, so concurrent stores on separate fds race. For apply_fn attributes, once one store's apply_fn has reconfigured the hardware, a second (losing) store can still overwrite dev->NAME afterwards. This leaves dev->submit_queues out of sync with the live queue count, whi

    linux-azure-nvidiaОперационные системы
    Опубликовано Обновлено
    Исходное сообщение 1 ↗Исходное сообщение 2 ↗Исходное сообщение 3 ↗

  10. CVE-2026-90184

    Без оценкиEPSS 0,21%Нет опубликованного исправления

    null_blk: serialize configfs attribute updates with device setup

    In the Linux kernel, the following vulnerability has been resolved: null_blk: serialize configfs attribute updates with device setup The attribute store methods generated with NULLB_DEVICE_ATTR() refuse to change the configuration of a live device by testing NULLB_DEV_FL_CONFIGURED, but that flag is only set by nullb_device_power_store() after null_add_dev() has returned, and the store methods take no lock at all. configfs only serializes writes to the same open file (buffer->mutex), so a write to any attribute can run concurrently with null_add_dev() and change the device configuration while it is being used. null_add_dev() reads the conf

    linux-azure-nvidiaОперационные системы
    Опубликовано Обновлено
    Исходное сообщение 1 ↗Исходное сообщение 2 ↗Исходное сообщение 3 ↗

  11. CVE-2026-90183

    Средний · CVSS 6.8EPSS 0,21%Нет опубликованного исправления

    blk-iolatency: clear delay state when freeing policy data

    In the Linux kernel, the following vulnerability has been resolved: blk-iolatency: clear delay state when freeing policy data io.latency can throttle a group which has no latency target of its own. When a sibling misses its target, check_scale_change() scales down its peers, and a peer that reaches queue depth one gets blkcg_use_delay() called on it on every further scale-down, even with min_lat_nsec == 0. iolatency_pd_offline() resets the target through iolatency_set_min_lat_nsec(), which clears the delay only on a nonzero to zero transition, so it never clears such a peer. Freeing the policy data then leaves blkg->use_delay set and blkc

    linux-azure-nvidiaОперационные системы
    Опубликовано Обновлено
    Исходное сообщение 1 ↗Исходное сообщение 2 ↗Исходное сообщение 3 ↗

  12. CVE-2026-90182

    Низкий · CVSS 2EPSS 0,21%Нет опубликованного исправления

    blk-iocost: clear delay state when freeing policy data

    In the Linux kernel, the following vulnerability has been resolved: blk-iocost: clear delay state when freeing policy data iocg_kick_delay() turns sufficiently large debt into an explicit block-cgroup delay with blkcg_set_delay(), setting blkg->use_delay to -1 and incrementing blkcg->congestion_count. Clearing it again depends on iocg_kick_delay() running from the period timer, the waitq timer or the issue path. ioc_pd_free() removes the iocg from active_iocgs and cancels its waitq timer, and no further bios can arrive, so once it has run nothing is left which can reduce the debt and clear the delay. The blkcg stays marked congested for

    linux-azure-nvidiaОперационные системы
    Опубликовано Обновлено
    Исходное сообщение 1 ↗Исходное сообщение 2 ↗Исходное сообщение 3 ↗

  13. CVE-2026-90180

    Без оценкиEPSS 0,21%Нет опубликованного исправления

    block: mtip32xx: synchronize ioctls with device removal

    In the Linux kernel, the following vulnerability has been resolved: block: mtip32xx: synchronize ioctls with device removal The ioctl handlers only test REMOVE_PENDING before entering mtip_hw_ioctl(). Removal can set that bit immediately afterwards and free dd->port in mtip_hw_exit() while an ioctl still dereferences it. An already open block device can reach the handlers while del_gendisk() is in progress. Serialize both native and compat ioctls with removal. Set REMOVE_PENDING before taking the mutex so new callers fail after an in-flight ioctl has drained, and hold the mutex until the port has been torn down.

    linux-azure-nvidiaОперационные системы
    Опубликовано Обновлено
    Исходное сообщение 1 ↗Исходное сообщение 2 ↗Исходное сообщение 3 ↗

  14. CVE-2026-90178

    Без оценкиEPSS 0,17%Нет опубликованного исправления

    hwmon: (coretemp) Fix core_data leak on CPUs without PTS

    In the Linux kernel, the following vulnerability has been resolved: hwmon: (coretemp) Fix core_data leak on CPUs without PTS pdata->core_data is allocated in init_temp_data() when the first core temp_data of a package is created, but it is only released from destroy_temp_data(), and only in the branch that handles the package temp_data. Package temp_data is created solely when the CPU supports X86_FEATURE_PTS. On a CPU without it, coretemp_cpu_online() never calls coretemp_add_core() with pkg_flag set, so pdata->pkg_data stays NULL. coretemp_cpu_offline() then skips the removal of the package interface, destroy_temp_data() is never called

    linux-azure-nvidiaОперационные системы
    Опубликовано Обновлено
    Исходное сообщение 1 ↗Исходное сообщение 2 ↗Исходное сообщение 3 ↗

  15. CVE-2026-90176

    Высокий · CVSS 8.1EPSS 0,5%Нет опубликованного исправления

    ksmbd: Do not skip lock checks for single-byte ranges

    In the Linux kernel, the following vulnerability has been resolved: ksmbd: Do not skip lock checks for single-byte ranges check_lock_range() uses inclusive ranges. Its callers pass the end offset as start + length - 1, so start == end represents a valid single-byte range rather than an empty range. The start == end shortcut therefore skips mandatory byte-range lock checks for one-byte reads, writes, copychunk operations and one-byte truncate ranges. A conflicting lock covering that byte is not checked and the operation is allowed to proceed. Remove the shortcut. The truncate size == inode->i_size case is already handled by only calling ch

    linux-azure-nvidiaОперационные системы
    Опубликовано Обновлено
    Исходное сообщение 1 ↗Исходное сообщение 2 ↗Исходное сообщение 3 ↗

  16. CVE-2026-90175

    Без оценкиEPSS 0,2%Нет опубликованного исправления

    smb: server: fix leak of ksmbd_ipc_login_request_ext() returned buffer

    In the Linux kernel, the following vulnerability has been resolved: smb: server: fix leak of ksmbd_ipc_login_request_ext() returned buffer Free it unconditionally after ksmbd_alloc_user() calls. kmemleak splat: unreferenced object 0xffff888103b83540 (size 192): comm "pool-0", pid 16970, jiffies 4377290937 hex dump (first 32 bytes): 00 00 00 00 01 00 00 00 00 00 00 00 00 00 00 00 ................ 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ backtrace (crc 408ccc66): __kvmalloc_node_noprof+0x730/0x920 handle_generic_event+0xec/0x1a0 [ksmbd] genl_family_rcv_msg_doit+0xe0/0x130

    linux-azure-nvidiaОперационные системы
    Опубликовано Обновлено
    Исходное сообщение 1 ↗Исходное сообщение 2 ↗Исходное сообщение 3 ↗

  17. CVE-2026-90174

    Высокий · CVSS 7.1EPSS 0,17%Нет опубликованного исправления

    ksmbd: fix slab-out-of-bounds read in ksmbd_alloc_user()

    In the Linux kernel, the following vulnerability has been resolved: ksmbd: fix slab-out-of-bounds read in ksmbd_alloc_user() ksmbd_alloc_user() copies resp->hash_sz bytes out of the mountd IPC login response with user->passkey_sz = resp->hash_sz; user->passkey = kmalloc(resp->hash_sz, KSMBD_DEFAULT_GFP); if (user->passkey) memcpy(user->passkey, resp->hash, resp->hash_sz); resp->hash_sz is a __u16 supplied by the response, but resp->hash[] is only KSMBD_REQ_MAX_HASH_SZ bytes. A malformed or malicious login response can set hash_sz well beyond that (up to 65535), so the memcpy() reads past the end of the response object. ipc_validate

    linux-azure-nvidiaОперационные системы
    Опубликовано Обновлено
    Исходное сообщение 1 ↗Исходное сообщение 2 ↗Исходное сообщение 3 ↗

  18. CVE-2026-90170

    Без оценкиEPSS 0,2%Нет опубликованного исправления

    ksmbd: validate ipc response length before dereferencing its fields

    In the Linux kernel, the following vulnerability has been resolved: ksmbd: validate ipc response length before dereferencing its fields ipc_validate_msg() computes the expected message size by reading length fields out of the response buffer supplied by the userspace ksmbd daemon (payload_sz, session_key_len, ngroups, ...). Those fields are read before the buffer is verified to be large enough to contain the struct they belong to, so a short response makes the read land past the end of the allocation. handle_response() sizes entry->response purely from the netlink attribute length (nla_len()) and only guards the leading handle read, so th

    linux-azure-nvidiaОперационные системы
    Опубликовано Обновлено
    Исходное сообщение 1 ↗Исходное сообщение 2 ↗Исходное сообщение 3 ↗

  19. CVE-2026-90169

    Высокий · CVSS 7.1EPSS 0,25%Нет опубликованного исправления

    ksmbd: free preauth sessions on connection teardown

    In the Linux kernel, the following vulnerability has been resolved: ksmbd: free preauth sessions on connection teardown SMB3.1.1 multichannel binding preserves the preauthentication hash in a preauth_session between the NTLM negotiate and authenticate requests. The binding NTLM negotiate allocates this object and returns STATUS_MORE_PROCESSING_REQUIRED. If the client disconnects before it sends the authenticate request, neither the authenticate nor error cleanup paths free the object. Release any remaining preauthentication sessions when tearing down the connection. Initialize the list when allocating the connection so that this cleanup is

    linux-azure-nvidiaОперационные системы
    Опубликовано Обновлено
    Исходное сообщение 1 ↗Исходное сообщение 2 ↗Исходное сообщение 3 ↗

  20. CVE-2026-90167

    Высокий · CVSS 7.7EPSS 0,21%Нет опубликованного исправления

    ksmbd: serialize oplock close with pending break ownership

    In the Linux kernel, the following vulnerability has been resolved: ksmbd: serialize oplock close with pending break ownership close may abort an in-flight oplock break while another breaker already holds an opinfo reference. Releasing pending_break wakes that waiter, but without serializing the close transition with bit acquisition it can become a new break owner through the test_and_set_bit() fast path. It can then overwrite OPLOCK_CLOSING with OPLOCK_ACK_WAIT and continue a break for a dying opinfo. Make OPLOCK_CLOSING terminal once the opinfo is removed from the inode list. Serialize that transition, pending_break acquisition, and OPLO

    linux-azure-nvidiaОперационные системы
    Опубликовано Обновлено
    Исходное сообщение 1 ↗Исходное сообщение 2 ↗Исходное сообщение 3 ↗

Проверьте свой сервер

Сопоставьте установленный стек и версии со свежими базами уязвимостей.

Проверьте свой сервер →