p PatchFirst

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

Уязвимости linux-lts-xenial · Страница 3

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

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

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

  1. CVE-2026-99039

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

    memstick: core: wait for request completion before freeing card

    In the Linux kernel, the following vulnerability has been resolved: memstick: core: wait for request completion before freeing card In memstick_alloc_card() and memstick_set_rw_addr(), wait_for_completion_timeout() is used to wait for device identification and address configuration requests to complete. The memstick subsystem does not provide an abort or cancellation callback in struct memstick_host for in-flight requests. If wait_for_completion_timeout() expires (for instance, when a USB transfer or command retry is delayed), memstick_alloc_card() returns an error and frees the memstick_dev structure via kfree(card). However, the host co

    Опубликовано Обновлено
  2. CVE-2026-99038

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

    memstick: rtsx_usb_ms: complete requests after eject instead of dropping them

    In the Linux kernel, the following vulnerability has been resolved: memstick: rtsx_usb_ms: complete requests after eject instead of dropping them memstick_check() can pass its host->removing check just before rtsx_usb_ms_drv_remove() sets eject/removing. Its next request is then silently dropped: rtsx_usb_ms_request() skips schedule_work() once eject is set, and drv_remove's cancel_work_sync() can also cancel a queued handle_req before it picks the request up. Nobody completes card->mrq_complete. Once memstick core waits for requests without a timeout ("memstick: core: wait for request completion before freeing card"), this hangs removal:

    Опубликовано Обновлено
  3. CVE-2026-99036

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

    dm: fix reading free memory in do_resume

    In the Linux kernel, the following vulnerability has been resolved: dm: fix reading free memory in do_resume When do_resume calls dm_table_get_mode(new_map), the call is done without holding any locks (it only holds a reference to the md). It may be possible that another concurrent ioctl on the same device will swap table after dm_swap_table and before dm_table_get_mode. In this case, dm_table_get_mode(new_map) reads freed memory. This race condition was triggered by syzbot. This commit fixes the race by reading mode of the new table before dm_swap_table. Note that new_map is also passed to dm_ima_need_measure, but this function doesn't a

    Опубликовано Обновлено
  4. CVE-2026-99035

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

    mmc: mtk-sd: Cancel request timeout work on remove

    In the Linux kernel, the following vulnerability has been resolved: mmc: mtk-sd: Cancel request timeout work on remove The driver queues req_timeout while a request is active. msdc_request_done() uses cancel_delayed_work(), which does not wait for a timeout callback that has already started. The timeout callback calls mmc_request_done(), which wakes the request waiter, and then continues to use host->dev_comp and check the SDIO IRQ. During unbind, msdc_drv_remove() can return and the managed mmc_host can be freed before the callback finishes. KASAN reported use-after-free accesses in msdc_request_done() and msdc_recheck_sdio_irq() in each

    Опубликовано Обновлено
  5. CVE-2026-99027

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

    net: team: stop reusing skb after queue override

    In the Linux kernel, the following vulnerability has been resolved: net: team: stop reusing skb after queue override A nonzero dev_queue_xmit() result does not return ownership of the skb. When an override port's qdisc drops it, the queue override helper used to try another port or the mode transmit op with the freed skb. Return the handoff decision separately from transmit success. Select only the first override port under RCU and stop after handing it the skb, regardless of the lower transmit result. Keep the existing success and drop accounting. BUG: KASAN: slab-use-after-free in sk_skb_reason_drop Write of size 4 by task poc/5040

    Опубликовано Обновлено
  6. CVE-2026-99026

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

    net: team: free skb when broadcast has no txable port

    In the Linux kernel, the following vulnerability has been resolved: net: team: free skb when broadcast has no txable port bc_transmit() sends the original skb through the last txable port. When no port is txable, it returns false without consuming the skb, but team_xmit() still returns NETDEV_TX_OK. AF_PACKET sends then retain the skb and its socket write-memory charge. A TX-enabled, link-down port keeps the broadcast transmit op installed. Carrier can stay up through a second link-up, TX-disabled port or be forced on by userspace. Free the original skb on the no-port path while leaving the existing drop accounting intact. Discovered by S

    Опубликовано Обновлено
  7. CVE-2026-99025

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

    openvswitch: fix soft lockup in the netlink flow dump

    In the Linux kernel, the following vulnerability has been resolved: openvswitch: fix soft lockup in the netlink flow dump A production compute node carrying a few thousand datapath flows hit a soft lockup inside a single netlink flow dump and panicked. ovs_flow_cmd_dump() calls ovs_flow_stats_get() for every flow it emits, and that releases stats->lock with spin_unlock_bh() once per CPU that has touched the flow. Every release is a local_bh_enable(), and each one runs the pending softirq backlog in the dumping thread's own context. The skb bounds the flows one callback emits, but not the softirq work it absorbs. On a CPU that carries the

    Опубликовано Обновлено
  8. CVE-2026-99019

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

    scsi: ch: Do not keep references to data transfer element devices

    In the Linux kernel, the following vulnerability has been resolved: scsi: ch: Do not keep references to data transfer element devices ch_readconfig() looks up the scsi_device of every data transfer element whose SCSI id the changer reports in READ ELEMENT STATUS, and stores it in ch->dt[]. scsi_device_lookup() takes a reference, and nothing ever drops it: ch_destroy() frees the array with kfree(). ch->dt[] is read nowhere else - it only supplies the vendor, model and revision printed in the same loop. Once such a drive is removed, its scsi_device can never be released. It stays on the host's device list at its address, so a new device ther

    Опубликовано Обновлено
  9. CVE-2026-99015

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

    Bluetooth: hci_sock: Serialize dead-device detachment

    In the Linux kernel, the following vulnerability has been resolved: Bluetooth: hci_sock: Serialize dead-device detachment Rebinding an HCI socket after its controller is unregistered can race monitor control replay and crash the kernel. hci_sock_bind() clears hci_pi(sk)->hdev and drops the device reference under only the socket lock, whereas send_monitor_control_replay() holds hci_sk_list.lock for reading. Replay can observe a non-NULL hdev, then bind can clear it and drop the last reference before create_monitor_ctrl_open() reads hdev->id. This can cause a NULL pointer dereference if the pointer is reloaded, or a use-after-free if the old

    Опубликовано Обновлено
  10. CVE-2026-99010

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

    Bluetooth: RFCOMM: free the skb when the DLC has no owner

    In the Linux kernel, the following vulnerability has been resolved: Bluetooth: RFCOMM: free the skb when the DLC has no owner rfcomm_recv_data() hands the skb to d->data_ready() and returns 0 without freeing it, so the callback owns the skb from that point on. The tty implementation frees it when the DLC has been detached from its device: static void rfcomm_dev_data_ready(struct rfcomm_dlc *dlc, struct sk_buff *skb) { struct rfcomm_dev *dev = dlc->owner; if (!dev) { kfree_skb(skb); return; } The socket implementation returns without

    Опубликовано Обновлено
  11. CVE-2026-99008

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

    Bluetooth: RFCOMM: Fix NULL tty_dev dereference in rfcomm_dev_shutdown

    In the Linux kernel, the following vulnerability has been resolved: Bluetooth: RFCOMM: Fix NULL tty_dev dereference in rfcomm_dev_shutdown syzbot hit a NULL pointer dereference in rfcomm_dev_shutdown() when an RFCOMM tty is closed. rfcomm_dev_add() puts the new device on rfcomm_dev_list first and only then registers the tty device and saves it in dev->tty_dev. If that registration fails, dev->tty_dev is never set at all. The device can be looked up in the meantime, so an open() of /dev/rfcommN gets through rfcomm_tty_install() and attaches to it. When that tty is closed again, rfcomm_dev_shutdown() uses dev->tty_dev without checking it:

    Опубликовано Обновлено
  12. CVE-2026-99002

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

    drm/vmwgfx: validate pitch coming from userspace

    In the Linux kernel, the following vulnerability has been resolved: drm/vmwgfx: validate pitch coming from userspace Validate the pitch, alongside the box dimensions before trying to copy data from the underlying surface. Fixes possible out of bounds reads with cursor snooping.

    Опубликовано Обновлено
  13. CVE-2026-98996

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

    fs: don't silently unmount busy mounts

    In the Linux kernel, the following vulnerability has been resolved: fs: don't silently unmount busy mounts The propagate_mount_busy() helper exists to decide whether a synchronous can suceed. It does that by looking at the copies of the victims in the mounts its parent propagates to. One of those functions from propagation hell. It skips a copy that has child mounts except for the case of a single child mount covering the copy's root. That algorithm used to be exact. It isn't anymore. Originally only childless copies were unmounted during propagation. And 1064f874abc0 ("mnt: Tuck mounts under others instead of creating shadow/side mounts.

    Опубликовано Обновлено
  14. CVE-2026-98993

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

    namespace: don't inherit MNT_UMOUNT in clone_mnt()

    In the Linux kernel, the following vulnerability has been resolved: namespace: don't inherit MNT_UMOUNT in clone_mnt() MNT_UMOUNT gets raised on a mount that umount_tree() or umount_one() has taken out of its namespace. It's never cleared. __detach_mounts() unhooks a mount that carries it instead of unmounting it. disconnect_mount() lets an unmounted child stay attached only if its parent carries it. propagate_umount() takes it as the sign that a mount is going to be unmounted when it decides what else can be unmounted, where a chain of locked mounts ends and where a for reparenting an overmount. clone_mnt() copies the flags of the source

    Опубликовано Обновлено
  15. CVE-2026-98992

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

    namespace: don't copy an unmounted mount tree

    In the Linux kernel, the following vulnerability has been resolved: namespace: don't copy an unmounted mount tree may_copy_tree() accepts a mount whose root is an nsfs or pidfs file before it checks whether that mount is mounted. This exception exists for nsfs and pidfs mounts. They are part of no mount namespace so neither check_mnt() nor is_mounted() would let them through and bind-mounting a nsfsfd or a pidfd wouldn't work. Problem is that exception also admits a bind mount of such a file when it was lazily unmounted and is only kept alive by a file descriptor: mount --bind /proc/self/ns/net /tmp/x exec 3< /tmp/x umount -l /tmp/x

    Опубликовано Обновлено
  16. CVE-2026-98990

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

    namespace: check a submount for references right before unmounting it

    In the Linux kernel, the following vulnerability has been resolved: namespace: check a submount for references right before unmounting it shrink_submounts() and mark_mounts_for_expiry() first collect all the mounts they are allowed to unmount and then unmount them. Whether a mount is busy is decided by propagate_mount_busy() on the tree. But unmounting the first mount changes the tree that the second one propagates into. propagate_umount() moves a surviving overmount off a copy it unmounts and mounts it where the copy was mounted. If that's where the propagated copy of the second victim is looked up the overmount becomes a candidate of the

    Опубликовано Обновлено
  17. CVE-2026-98989

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

    namespace: check a recursive bind mount for mount namespace loops

    In the Linux kernel, the following vulnerability has been resolved: namespace: check a recursive bind mount for mount namespace loops do_loopback() refuses to bind mount the file of a mount namespace that is as old as the caller's or older because a mount namespace that holds a mount of its own file, or of an ancestor's, would cause a cycle. But it only checks the dentry the bind mount starts from. With MS_REC everything below it is copied and do_loopback() passes CL_COPY_MNT_NS_FILE so mount namespace files below the source are copied. That's fine for a source in the caller's own mount namespace. Every mount namespace file in there passed

    Опубликовано Обновлено
  18. CVE-2026-98985

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

    namespace: check the mounts before reading their parents in pivot_root()

    In the Linux kernel, the following vulnerability has been resolved: namespace: check the mounts before reading their parents in pivot_root() path_pivot_root() reads the parents of new_root and of the caller's root and checks whether they are shared before it checks that either mount is in the caller's mount namespace. Only namespace_sem is held. That's fine for a mount that is in the caller's mount namespace. But new_root can be a file descriptor to a mount that has been unmounted and that only the file descriptor keeps alive. If that mount stayed attached to its parent when it was unmounted nothing pins the parent for it. The final mntput

    Опубликовано Обновлено
  19. CVE-2026-98984

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

    dcache: don't put a mountpoint on a dentry that's being removed

    In the Linux kernel, the following vulnerability has been resolved: dcache: don't put a mountpoint on a dentry that's being removed rmdir(), unlink() and rename() call dont_mount() on the victim and then detach_mounts() with the victim's inode locked. do_lock_mount() takes the inode lock of the mountpoint and checks cant_mount() so a mount can't show up after detach_mounts(). But attach_recursive_mnt() makes a second mountpoint for the root of the source mount so that the mounts already located at the destination can be put on top of it. No inode is locked for that one and d_set_mounted() only refuses a dentry that is unlinked. Between det

    Опубликовано Обновлено
  20. CVE-2026-98981

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

    namespace: unhash a dentry before detaching the mounts on it

    In the Linux kernel, the following vulnerability has been resolved: namespace: unhash a dentry before detaching the mounts on it unlink(), rmdir() and rename() remove the entry from the filesystem, call detach_mounts() on the entry with the inode locked and then call d_delete() once the inode is unlocked. The thing is that between detach_mounts() and d_delete() the dentry is still hashed and positive. But after detach_mounts() nothing covers the dentry anymore. A lookup that finds this dentry in the dcache can uncover what the mounts hid. That's a problem when unlinking files or directories that are mountpoints in other mount namespaces.

    Опубликовано Обновлено

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

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

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