Page 283 of 3964 results (0.016 seconds)

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

04 Apr 2024 — In the Linux kernel, the following vulnerability has been resolved: Both cadence-quadspi ->runtime_suspend() and ->runtime_resume() implementations start with: struct cqspi_st *cqspi = dev_get_drvdata(dev); struct spi_controller *host = dev_get_drvdata(dev); This obviously cannot be correct, unless "struct cqspi_st" is the first member of " struct spi_controller", or the other way around, but it is not the case. "struct spi_controller" is allocated by devm_spi_alloc_host(), which allocates an extra amount o... • https://git.kernel.org/stable/c/2087e85bb66ee3652dafe732bb9b9b896229eafc •

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

04 Apr 2024 — In the Linux kernel, the following vulnerability has been resolved: netlink: Fix kernel-infoleak-after-free in __skb_datagram_iter syzbot reported the following uninit-value access issue [1]: netlink_to_full_skb() creates a new `skb` and puts the `skb->data` passed as a 1st arg of netlink_to_full_skb() onto new `skb`. The data size is specified as `len` and passed to skb_put_data(). This `len` is based on `skb->end` that is not data offset but buffer offset. The `skb->end` contains data and tailroom. Since ... • https://git.kernel.org/stable/c/1853c949646005b5959c483becde86608f548f24 •

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

04 Apr 2024 — In the Linux kernel, the following vulnerability has been resolved: net: ip_tunnel: prevent perpetual headroom growth syzkaller triggered following kasan splat: BUG: KASAN: use-after-free in __skb_flow_dissect+0x19d1/0x7a50 net/core/flow_dissector.c:1170 Read of size 1 at addr ffff88812fb4000e by task syz-executor183/5191 [..] kasan_report+0xda/0x110 mm/kasan/report.c:588 __skb_flow_dissect+0x19d1/0x7a50 net/core/flow_dissector.c:1170 skb_flow_dissect_flow_keys include/linux/skbuff.h:1514 [inline] ___skb_ge... • https://git.kernel.org/stable/c/243aad830e8a4cdda261626fbaeddde16b08d04a • CWE-416: Use After Free •

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

04 Apr 2024 — In the Linux kernel, the following vulnerability has been resolved: net: veth: clear GRO when clearing XDP even when down veth sets NETIF_F_GRO automatically when XDP is enabled, because both features use the same NAPI machinery. The logic to clear NETIF_F_GRO sits in veth_disable_xdp() which is called both on ndo_stop and when XDP is turned off. To avoid the flag from being cleared when the device is brought down, the clearing is skipped when IFF_UP is not set. Bringing the device down should indeed not mo... • https://git.kernel.org/stable/c/d3256efd8e8b234a6251e4d4580bd2c3c31fdc4c •

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

04 Apr 2024 — In the Linux kernel, the following vulnerability has been resolved: stmmac: Clear variable when destroying workqueue Currently when suspending driver and stopping workqueue it is checked whether workqueue is not NULL and if so, it is destroyed. Function destroy_workqueue() does drain queue and does clear variable, but it does not set workqueue variable to NULL. This can cause kernel/module panic if code attempts to clear workqueue that was not initialized. This scenario is possible when resuming suspended d... • https://git.kernel.org/stable/c/5a5586112b929546e16029261a987c9197bfdfa2 • CWE-416: Use After Free •

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

04 Apr 2024 — In the Linux kernel, the following vulnerability has been resolved: Bluetooth: Avoid potential use-after-free in hci_error_reset While handling the HCI_EV_HARDWARE_ERROR event, if the underlying BT controller is not responding, the GPIO reset mechanism would free the hci_dev and lead to a use-after-free in hci_error_reset. Here's the call trace observed on a ChromeOS device with Intel AX201: queue_work_on+0x3e/0x6c __hci_cmd_sync_sk+0x2ee/0x4c0 [bluetooth ] ? init_wait_entry+0x31/0x31 __hci_cmd_... • https://git.kernel.org/stable/c/c7741d16a57cbf97eebe53f27e8216b1ff20e20c •

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

04 Apr 2024 — In the Linux kernel, the following vulnerability has been resolved: tls: fix use-after-free on failed backlog decryption When the decrypt request goes to the backlog and crypto_aead_decrypt returns -EBUSY, tls_do_decryption will wait until all async decryptions have completed. If one of them fails, tls_do_decryption will return -EBADMSG and tls_decrypt_sg jumps to the error path, releasing all the pages. But the pages have been passed to the async callback, and have already been released by tls_decrypt_done... • https://git.kernel.org/stable/c/13eca403876bbea3716e82cdfe6f1e6febb38754 •

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

04 Apr 2024 — In the Linux kernel, the following vulnerability has been resolved: ASoC: qcom: Fix uninitialized pointer dmactl In the case where __lpass_get_dmactl_handle is called and the driver id dai_id is invalid the pointer dmactl is not being assigned a value, and dmactl contains a garbage value since it has not been initialized and so the null check may not work. Fix this to initialize dmactl to NULL. One could argue that modern compilers will set this to zero, but it is useful to keep this initialized as per the ... • https://git.kernel.org/stable/c/b81af585ea54ee9f749391e594ee9cbd44061eae •

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

04 Apr 2024 — In the Linux kernel, the following vulnerability has been resolved: fbcon: always restore the old font data in fbcon_do_set_font() Commit a5a923038d70 (fbdev: fbcon: Properly revert changes when vc_resize() failed) started restoring old font data upon failure (of vc_resize()). But it performs so only for user fonts. It means that the "system"/internal fonts are not restored at all. So in result, the very first call to fbcon_do_set_font() performs no restore at all upon failing vc_resize(). This can be repro... • https://git.kernel.org/stable/c/ebd6f886aa2447fcfcdce5450c9e1028e1d681bb •

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

04 Apr 2024 — In the Linux kernel, the following vulnerability has been resolved: riscv: Sparse-Memory/vmemmap out-of-bounds fix Offset vmemmap so that the first page of vmemmap will be mapped to the first page of physical memory in order to ensure that vmemmap’s bounds will be respected during pfn_to_page()/page_to_pfn() operations. The conversion macros will produce correct SV39/48/57 addresses for every possible/valid DRAM_BASE inside the physical memory limits. v2:Address Alex's comments En el kernel de Linux, se res... • https://git.kernel.org/stable/c/d95f1a542c3df396137afa217ef9bd39cb8931ca •