Page 247 of 5895 results (0.012 seconds)

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

29 Feb 2024 — In the Linux kernel, the following vulnerability has been resolved: HID: logitech-hidpp: Fix kernel crash on receiver USB disconnect hidpp_connect_event() has *four* time-of-check vs time-of-use (TOCTOU) races when it races with itself. hidpp_connect_event() primarily runs from a workqueue but it also runs on probe() and if a "device-connected" packet is received by the hw when the thread running hidpp_connect_event() from probe() is waiting on the hw, then a second thread running hidpp_connect_event() will... • https://git.kernel.org/stable/c/ca0c4cc1d215dc22ab0e738c9f017c650f3183f5 • CWE-362: Concurrent Execution using Shared Resource with Improper Synchronization ('Race Condition') •

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

29 Feb 2024 — In the Linux kernel, the following vulnerability has been resolved: usb: hub: Guard against accesses to uninitialized BOS descriptors Many functions in drivers/usb/core/hub.c and drivers/usb/core/hub.h access fields inside udev->bos without checking if it was allocated and initialized. If usb_get_bos_descriptor() fails for whatever reason, udev->bos will be NULL and those accesses will result in a crash: BUG: kernel NULL pointer dereference, address: 0000000000000018 PGD 0 P4D 0 Oops: 0000 [#1] PREEMPT SMP ... • https://git.kernel.org/stable/c/c64e4dca9aefd232b17ac4c779b608b286654e81 • CWE-476: NULL Pointer Dereference •

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

29 Feb 2024 — In the Linux kernel, the following vulnerability has been resolved: perf/x86/lbr: Filter vsyscall addresses We found that a panic can occur when a vsyscall is made while LBR sampling is active. If the vsyscall is interrupted (NMI) for perf sampling, this call sequence can occur (most recent at top): __insn_get_emulate_prefix() insn_get_emulate_prefix() insn_get_prefixes() insn_get_opcode() decode_branch_type() get_branch_type() intel_pmu_lbr_filter() intel_pmu_handle_irq() perf_event_nmi_handler() Within __... • https://git.kernel.org/stable/c/403d201d1fd144cb249836dafb222f6375871c6c • CWE-404: Improper Resource Shutdown or Release •

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

29 Feb 2024 — In the Linux kernel, the following vulnerability has been resolved: Input: powermate - fix use-after-free in powermate_config_complete syzbot has found a use-after-free bug [1] in the powermate driver. This happens when the device is disconnected, which leads to a memory free from the powermate_device struct. When an asynchronous control message completes after the kfree and its callback is invoked, the lock does not exist anymore and hence the bug. Use usb_kill_urb() on pm->config to cancel any in-progress... • https://git.kernel.org/stable/c/8677575c4f39d65bf0d719b5d20e8042e550ccb9 • CWE-416: Use After Free •

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

28 Feb 2024 — In the Linux kernel, the following vulnerability has been resolved: spi: fsl-lpspi: Fix PM reference leak in lpspi_prepare_xfer_hardware() pm_runtime_get_sync will increment pm usage counter even it failed. Forgetting to putting operation will result in reference leak here. Fix it by replacing it with pm_runtime_resume_and_get to keep usage counter balanced. En el kernel de Linux, se resolvió la siguiente vulnerabilidad: spi: fsl-lpspi: corrige la fuga de referencia de PM en lpspi_prepare_xfer_hardware() pm... • https://git.kernel.org/stable/c/944c01a889d97dc08e1b71f4ed868f4023fd6034 •

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

28 Feb 2024 — In the Linux kernel, the following vulnerability has been resolved: memory: renesas-rpc-if: fix possible NULL pointer dereference of resource The platform_get_resource_byname() can return NULL which would be immediately dereferenced by resource_size(). Instead dereference it after validating the resource. Addresses-Coverity: Dereference null return value En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: memoria: renesas-rpc-if: corrige posible desreferencia del puntero NULL del recurso Plat... • https://git.kernel.org/stable/c/ca7d8b980b67f133317525c4273e144116ee1ae5 •

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

28 Feb 2024 — In the Linux kernel, the following vulnerability has been resolved: Drivers: hv: vmbus: Use after free in __vmbus_open() The "open_info" variable is added to the &vmbus_connection.chn_msg_list, but the error handling frees "open_info" without removing it from the list. This will result in a use after free. First remove it from the list, and then free it. En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: Controladores: hv: vmbus: Usar después de liberar en __vmbus_open() La variable "open_in... • https://git.kernel.org/stable/c/6f3d791f300618caf82a2be0c27456edd76d5164 •

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

28 Feb 2024 — In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Fix off by one in hdmi_14_process_transaction() The hdcp_i2c_offsets[] array did not have an entry for HDCP_MESSAGE_ID_WRITE_CONTENT_STREAM_TYPE so it led to an off by one read overflow. I added an entry and copied the 0x0 value for the offset from similar code in drivers/gpu/drm/amd/display/modules/hdcp/hdcp_ddc.c. I also declared several of these arrays as having HDCP_MESSAGE_ID_MAX entries. This doesn't change the code, ... • https://git.kernel.org/stable/c/4c283fdac08abf3211533f70623c90a34f41d08d •

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

28 Feb 2024 — In the Linux kernel, the following vulnerability has been resolved: media: venus: core: Fix some resource leaks in the error path of 'venus_probe()' If an error occurs after a successful 'of_icc_get()' call, it must be undone. Use 'devm_of_icc_get()' instead of 'of_icc_get()' to avoid the leak. Update the remove function accordingly and axe the now unneeded 'icc_put()' calls. En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: media: venus: core: corrige algunas fugas de recursos en la ruta d... • https://git.kernel.org/stable/c/32f0a6ddc8c98a1aade2bf3d07c79d5d2c6ceb9a •

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

28 Feb 2024 — In the Linux kernel, the following vulnerability has been resolved: nvmet-tcp: fix incorrect locking in state_change sk callback We are not changing anything in the TCP connection state so we should not take a write_lock but rather a read lock. This caused a deadlock when running nvmet-tcp and nvme-tcp on the same system, where state_change callbacks on the host and on the controller side have causal relationship and made lockdep report on this with blktests: ================================ WARNING: incons... • https://git.kernel.org/stable/c/872d26a391da92ed8f0c0f5cb5fef428067b7f30 •