Page 25 of 6321 results (0.015 seconds)

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

In the Linux kernel, the following vulnerability has been resolved: phy: qcom: qmp-usb-legacy: fix NULL-deref on runtime suspend Commit 413db06c05e7 ("phy: qcom-qmp-usb: clean up probe initialisation") removed most users of the platform device driver data from the qcom-qmp-usb driver, but mistakenly also removed the initialisation despite the data still being used in the runtime PM callbacks. This bug was later reproduced when the driver was copied to create the qmp-usb-legacy driver. Restore the driver data initialisation at probe to avoid a NULL-pointer dereference on runtime suspend. Apparently no one uses runtime PM, which currently needs to be enabled manually through sysfs, with these drivers. • https://git.kernel.org/stable/c/e464a3180a43b6596bd267f9f274e1793bfb8150 https://git.kernel.org/stable/c/7e8066811a2c43fbb5f53c2c26d389e4bab9da34 https://git.kernel.org/stable/c/b1cffd00daa9cf499b49a0da698eff5032914f6e https://git.kernel.org/stable/c/29240130ab77c80bea1464317ae2a5fd29c16a0c •

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

In the Linux kernel, the following vulnerability has been resolved: phy: qcom: qmp-usbc: fix NULL-deref on runtime suspend Commit 413db06c05e7 ("phy: qcom-qmp-usb: clean up probe initialisation") removed most users of the platform device driver data from the qcom-qmp-usb driver, but mistakenly also removed the initialisation despite the data still being used in the runtime PM callbacks. This bug was later reproduced when the driver was copied to create the qmp-usbc driver. Restore the driver data initialisation at probe to avoid a NULL-pointer dereference on runtime suspend. Apparently no one uses runtime PM, which currently needs to be enabled manually through sysfs, with these drivers. • https://git.kernel.org/stable/c/19281571a4d5b6049dad9318db081af48818b1d2 https://git.kernel.org/stable/c/bdb35fcff34af08fc7a7cb92f99ff1442e975cb1 https://git.kernel.org/stable/c/c7086dc0539b1b2b61c8c735186698bca4858246 https://git.kernel.org/stable/c/34c21f94fa1e147a19b54b6adf0c93a623b70dd8 •

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

In the Linux kernel, the following vulnerability has been resolved: wifi: mac80211: do not pass a stopped vif to the driver in .get_txpower Avoid potentially crashing in the driver because of uninitialized private data • https://git.kernel.org/stable/c/5b3dc42b1b0db0264bbbe4ae44c15ab97bfd1e93 https://git.kernel.org/stable/c/b0b862aa3dbcd16b3c4715259a825f48ca540088 https://git.kernel.org/stable/c/78b698fbf37208ee921ee4cedea75b5d33d6ea9f https://git.kernel.org/stable/c/c21efba8b5a86537ccdf43f77536bad02f82776c https://git.kernel.org/stable/c/b2bcbe5450b20641f512d6b26c6b256a5a4f847f https://git.kernel.org/stable/c/8f6cd4d5bb7406656835a90e4f1a2192607f0c21 https://git.kernel.org/stable/c/ee35c423042c9e04079fdee3db545135d609d6ea https://git.kernel.org/stable/c/3ccf525a73d48e814634847f6d4a6150c •

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

In the Linux kernel, the following vulnerability has been resolved: wifi: ath10k: Fix memory leak in management tx In the current logic, memory is allocated for storing the MSDU context during management packet TX but this memory is not being freed during management TX completion. Similar leaks are seen in the management TX cleanup logic. Kmemleak reports this problem as below, unreferenced object 0xffffff80b64ed250 (size 16): comm "kworker/u16:7", pid 148, jiffies 4294687130 (age 714.199s) hex dump (first 16 bytes): 00 2b d8 d8 80 ff ff ff c4 74 e9 fd 07 00 00 00 .+.......t...... backtrace: [<ffffffe6e7b245dc>] __kmem_cache_alloc_node+0x1e4/0x2d8 [<ffffffe6e7adde88>] kmalloc_trace+0x48/0x110 [<ffffffe6bbd765fc>] ath10k_wmi_tlv_op_gen_mgmt_tx_send+0xd4/0x1d8 [ath10k_core] [<ffffffe6bbd3eed4>] ath10k_mgmt_over_wmi_tx_work+0x134/0x298 [ath10k_core] [<ffffffe6e78d5974>] process_scheduled_works+0x1ac/0x400 [<ffffffe6e78d60b8>] worker_thread+0x208/0x328 [<ffffffe6e78dc890>] kthread+0x100/0x1c0 [<ffffffe6e78166c0>] ret_from_fork+0x10/0x20 Free the memory during completion and cleanup to fix the leak. Protect the mgmt_pending_tx idr_remove() operation in ath10k_wmi_tlv_op_cleanup_mgmt_tx_send() using ar->data_lock similar to other instances. Tested-on: WCN3990 hw1.0 SNOC WLAN.HL.2.0-01387-QCAHLSWMTPLZ-1 • https://git.kernel.org/stable/c/dc405152bb64d4ae01c9ac669de25b2d1fb6fc2d https://git.kernel.org/stable/c/aea35bd40d64eff19f287b58e5c4a15a305f6607 https://git.kernel.org/stable/c/2bc8b1816cf4908ae0a04c3e87e167d2dcb60f38 https://git.kernel.org/stable/c/eff818238bedb9c2484c251ec46f9f160911cdc0 https://git.kernel.org/stable/c/6fc9af3df6ca7f3c94774d20f62dc7b49616026d https://git.kernel.org/stable/c/4112450da7d67b59ccedc2208bae622db17dbcb8 https://git.kernel.org/stable/c/705be2dc45c7f852e211e16bc41a916fab741983 https://git.kernel.org/stable/c/6cc23898e6ba47e976050d3c080b4d2c1 •

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

In the Linux kernel, the following vulnerability has been resolved: wifi: cfg80211: clear wdev->cqm_config pointer on free When we free wdev->cqm_config when unregistering, we also need to clear out the pointer since the same wdev/netdev may get re-registered in another network namespace, then destroyed later, running this code again, which results in a double-free. • https://git.kernel.org/stable/c/c797498e860e9a435a651bbf0789433684ce6dd8 https://git.kernel.org/stable/c/37c20b2effe987b806c8de6d12978e4ffeff026f https://git.kernel.org/stable/c/32fb9b7d98c3e586bddfb978d383aa8d2b1211bc https://git.kernel.org/stable/c/ba392e1355ba74b1d4fa11b85f71ab6ed7ecc058 https://git.kernel.org/stable/c/6c44abb2d4c3262737d5d67832daebc8cf48b8c9 https://git.kernel.org/stable/c/64e4c45d23cd7f6167f69cc2d2877bc7f54292e5 https://git.kernel.org/stable/c/d5fee261dfd9e17b08b1df8471ac5d5736070917 •