Page 112 of 3048 results (0.015 seconds)

CVSS: 5.5EPSS: 0%CPEs: 5EXPL: 0

21 Aug 2024 — In the Linux kernel, the following vulnerability has been resolved: PCI: endpoint: Clean up error handling in vpci_scan_bus() Smatch complains about inconsistent NULL checking in vpci_scan_bus(): drivers/pci/endpoint/functions/pci-epf-vntb.c:1024 vpci_scan_bus() error: we previously assumed 'vpci_bus' could be null (see line 1021) Instead of printing an error message and then crashing we should return an error code and clean up. Also the NULL check is reversed so it prints an error for success instead of fa... • https://git.kernel.org/stable/c/e2b6ef72b7aea9d7d480d2df499bcd1c93247abb •

CVSS: 7.8EPSS: 0%CPEs: 5EXPL: 0

21 Aug 2024 — In the Linux kernel, the following vulnerability has been resolved: vhost/vsock: always initialize seqpacket_allow There are two issues around seqpacket_allow: 1. seqpacket_allow is not initialized when socket is created. Thus if features are never set, it will be read uninitialized. 2. if VIRTIO_VSOCK_F_SEQPACKET is set and then cleared, then seqpacket_allow will not be cleared appropriately (existing apps I know about don't usually do this but it's legal and there's no way to be sure no one relies on this... • https://git.kernel.org/stable/c/ced7b713711fdd8f99d8d04dc53451441d194c60 •

CVSS: 5.5EPSS: 0%CPEs: 2EXPL: 0

21 Aug 2024 — In the Linux kernel, the following vulnerability has been resolved: RDMA/hns: Fix soft lockup under heavy CEQE load CEQEs are handled in interrupt handler currently. This may cause the CPU core staying in interrupt context too long and lead to soft lockup under heavy load. Handle CEQEs in BH workqueue and set an upper limit for the number of CEQE handled by a single call of work handler. In the Linux kernel, the following vulnerability has been resolved: RDMA/hns: Fix soft lockup under heavy CEQE load CEQEs... • https://git.kernel.org/stable/c/a5073d6054f75d7c94b3354206eec4b804d2fbd4 •

CVSS: 5.5EPSS: 0%CPEs: 8EXPL: 0

21 Aug 2024 — In the Linux kernel, the following vulnerability has been resolved: devres: Fix memory leakage caused by driver API devm_free_percpu() It will cause memory leakage when use driver API devm_free_percpu() to free memory allocated by devm_alloc_percpu(), fixed by using devres_release() instead of devres_destroy() within devm_free_percpu(). In the Linux kernel, the following vulnerability has been resolved: devres: Fix memory leakage caused by driver API devm_free_percpu() It will cause memory leakage when use ... • https://git.kernel.org/stable/c/ff86aae3b4112b85d2231c23bccbc49589df1c06 • CWE-402: Transmission of Private Resources into a New Sphere ('Resource Leak') •

CVSS: 5.5EPSS: 0%CPEs: 6EXPL: 0

21 Aug 2024 — In the Linux kernel, the following vulnerability has been resolved: perf: Fix event leak upon exit When a task is scheduled out, pending sigtrap deliveries are deferred to the target task upon resume to userspace via task_work. However failures while adding an event's callback to the task_work engine are ignored. And since the last call for events exit happen after task work is eventually closed, there is a small window during which pending sigtrap can be queued though ignored, leaking the event refcount ad... • https://git.kernel.org/stable/c/8bffa95ac19ff27c8261904f89d36c7fcf215d59 • CWE-404: Improper Resource Shutdown or Release •

CVSS: 7.2EPSS: 0%CPEs: 6EXPL: 0

21 Aug 2024 — In the Linux kernel, the following vulnerability has been resolved: perf: Fix event leak upon exec and file release The perf pending task work is never waited upon the matching event release. In the case of a child event, released via free_event() directly, this can potentially result in a leaked event, such as in the following scenario that doesn't even require a weak IRQ work implementation to trigger: schedule() prepare_task_switch() =======> perf_event_overflow() event->pending_sigtrap = ... irq_w... • https://git.kernel.org/stable/c/8bffa95ac19ff27c8261904f89d36c7fcf215d59 • CWE-402: Transmission of Private Resources into a New Sphere ('Resource Leak') •

CVSS: 5.5EPSS: 0%CPEs: 4EXPL: 0

20 Aug 2024 — In the Linux kernel, the following vulnerability has been resolved: riscv/purgatory: align riscv_kernel_entry When alignment handling is delegated to the kernel, everything must be word-aligned in purgatory, since the trap handler is then set to the kexec one. Without the alignment, hitting the exception would ultimately crash. On other occasions, the kernel's handler would take care of exceptions. This has been tested on a JH7110 SoC with oreboot and its SBI delegating unaligned access exceptions and the k... • https://git.kernel.org/stable/c/736e30af583fb6e0e2b8211b894ff99dea0f1ee7 •

CVSS: 5.5EPSS: 0%CPEs: 7EXPL: 0

20 Aug 2024 — In the Linux kernel, the following vulnerability has been resolved: drm/nouveau: prime: fix refcount underflow Calling nouveau_bo_ref() on a nouveau_bo without initializing it (and hence the backing ttm_bo) leads to a refcount underflow. Instead of calling nouveau_bo_ref() in the unwind path of drm_gem_object_init(), clean things up manually. (cherry picked from commit 1b93f3e89d03cfc576636e195466a0d728ad8de5) In the Linux kernel, the following vulnerability has been resolved: drm/nouveau: prime: fix refcou... • https://git.kernel.org/stable/c/ab9ccb96a6e6f95bcde6b8b2a524370efdbfdcd6 •

CVSS: 5.5EPSS: 0%CPEs: 5EXPL: 0

20 Aug 2024 — In the Linux kernel, the following vulnerability has been resolved: net/mlx5: Always drain health in shutdown callback There is no point in recovery during device shutdown. if health work started need to wait for it to avoid races and NULL pointer access. Hence, drain health WQ on shutdown callback. In the Linux kernel, the following vulnerability has been resolved: net/mlx5: Always drain health in shutdown callback There is no point in recovery during device shutdown. if health work started need to wait fo... • https://git.kernel.org/stable/c/d2aa060d40fa060e963f9a356d43481e43ba3dac • CWE-476: NULL Pointer Dereference •

CVSS: 5.5EPSS: 0%CPEs: 3EXPL: 0

20 Aug 2024 — In the Linux kernel, the following vulnerability has been resolved: net/mlx5e: Fix CT entry update leaks of modify header context The cited commit allocates a new modify header to replace the old one when updating CT entry. But if failed to allocate a new one, eg. exceed the max number firmware can support, modify header will be an error pointer that will trigger a panic when deallocating it. And the old modify header point is copied to old attr. When the old attr is freed, the old modify header is lost. Fi... • https://git.kernel.org/stable/c/94ceffb48eac7692677d8093dcde6965b70c4b35 •