Page 399 of 3087 results (0.005 seconds)

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

In the Linux kernel, the following vulnerability has been resolved: net: dpaa2-eth: fix use-after-free in dpaa2_eth_remove Access to netdev after free_netdev() will cause use-after-free bug. Move debug log before free_netdev() call to avoid it. • https://git.kernel.org/stable/c/7472dd9f649958be6a8880ed439233c8414a7b34 https://git.kernel.org/stable/c/d74ff10ed2d93dc9b67e99a74b36fb9a83273d8a https://git.kernel.org/stable/c/1c4099dc0d6a01e76e4f7dd98e4b3e0d55d80ad9 https://git.kernel.org/stable/c/32d4686224744819ddcae58b666c21d2a4ef4c88 https://git.kernel.org/stable/c/9b5a333272a48c2f8b30add7a874e46e8b26129c •

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

In the Linux kernel, the following vulnerability has been resolved: scsi: lpfc: Fix list_add() corruption in lpfc_drain_txq() When parsing the txq list in lpfc_drain_txq(), the driver attempts to pass the requests to the adapter. If such an attempt fails, a local "fail_msg" string is set and a log message output. The job is then added to a completions list for cancellation. Processing of any further jobs from the txq list continues, but since "fail_msg" remains set, jobs are added to the completions list regardless of whether a wqe was passed to the adapter. If successfully added to txcmplq, jobs are added to both lists resulting in list corruption. Fix by clearing the fail_msg string after adding a job to the completions list. This stops the subsequent jobs from being added to the completions list unless they had an appropriate failure. • https://git.kernel.org/stable/c/ad4776b5eb2e58af1226847fcd3b4f6d051674dd https://git.kernel.org/stable/c/ec70d80a8642900086447ba0cdc79e3f44d42e8f https://git.kernel.org/stable/c/f05a0191b90156e539cccc189b9d87ca2a4d9305 https://git.kernel.org/stable/c/b291d147d0268e93ad866f8bc820ea14497abc9b https://git.kernel.org/stable/c/16bcbfb56d759c25665f786e33ec633b9508a08f https://git.kernel.org/stable/c/c097bd5a59162156d9c2077a2f58732ffbaa9fca https://git.kernel.org/stable/c/814d3610c4ce86e8cf285b2cdac0057a42e82de5 https://git.kernel.org/stable/c/99154581b05c8fb22607afb7c3d66c1ba •

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

In the Linux kernel, the following vulnerability has been resolved: thermal: Fix NULL pointer dereferences in of_thermal_ functions of_parse_thermal_zones() parses the thermal-zones node and registers a thermal_zone device for each subnode. However, if a thermal zone is consuming a thermal sensor and that thermal sensor device hasn't probed yet, an attempt to set trip_point_*_temp for that thermal zone device can cause a NULL pointer dereference. Fix it. console:/sys/class/thermal/thermal_zone87 # echo 120000 > trip_point_0_temp ... Unable to handle kernel NULL pointer dereference at virtual address 0000000000000020 ... Call trace: of_thermal_set_trip_temp+0x40/0xc4 trip_point_temp_store+0xc0/0x1dc dev_attr_store+0x38/0x88 sysfs_kf_write+0x64/0xc0 kernfs_fop_write_iter+0x108/0x1d0 vfs_write+0x2f4/0x368 ksys_write+0x7c/0xec __arm64_sys_write+0x20/0x30 el0_svc_common.llvm.7279915941325364641+0xbc/0x1bc do_el0_svc+0x28/0xa0 el0_svc+0x14/0x24 el0_sync_handler+0x88/0xec el0_sync+0x1c0/0x200 While at it, fix the possible NULL pointer dereference in other functions as well: of_thermal_get_temp(), of_thermal_set_emul_temp(), of_thermal_get_trend(). • https://git.kernel.org/stable/c/828f4c31684da94ecf0b44a2cbd35bbede04f0bd https://git.kernel.org/stable/c/6a315471cb6a07f651e1d3adc8962730f4fcccac https://git.kernel.org/stable/c/0750f769b95841b34a9fe8c418dd792ff526bf86 https://git.kernel.org/stable/c/ef2590a5305e0b8e9342f84c2214aa478ee7f28e https://git.kernel.org/stable/c/96cfe05051fd8543cdedd6807ec59a0e6c409195 •

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

In the Linux kernel, the following vulnerability has been resolved: iavf: free q_vectors before queues in iavf_disable_vf iavf_free_queues() clears adapter->num_active_queues, which iavf_free_q_vectors() relies on, so swap the order of these two function calls in iavf_disable_vf(). This resolves a panic encountered when the interface is disabled and then later brought up again after PF communication is restored. • https://git.kernel.org/stable/c/65c7006f234c9ede887d468f595f259a5c5cc552 https://git.kernel.org/stable/c/926e8c83d4c1c2dac0026637eb0d492df876489e https://git.kernel.org/stable/c/78638b47132244e3934dc5dc79f6372d5ce8e98c https://git.kernel.org/stable/c/9ef6589cac9a8c47f5544ccdf4c498093733bb3f https://git.kernel.org/stable/c/89f22f129696ab53cfbc608e0a2184d0fea46ac1 •

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

In the Linux kernel, the following vulnerability has been resolved: drm/prime: Fix use after free in mmap with drm_gem_ttm_mmap drm_gem_ttm_mmap() drops a reference to the gem object on success. If the gem object's refcount == 1 on entry to drm_gem_prime_mmap(), that drop will free the gem object, and the subsequent drm_gem_object_get() will be a UAF. Fix by grabbing a reference before calling the mmap helper. This issue was forseen when the reference dropping was adding in commit 9786b65bc61ac ("drm/ttm: fix mmap refcounting"): "For that to work properly the drm_gem_object_get() call in drm_gem_ttm_mmap() must be moved so it happens before calling obj->funcs->mmap(), otherwise the gem refcount would go down to zero." • https://git.kernel.org/stable/c/9786b65bc61acec63f923978c75e707afbb74bc7 https://git.kernel.org/stable/c/4f8e469a2384dfa4047145b0093126462cbb6dc0 https://git.kernel.org/stable/c/8244a3bc27b3efd057da154b8d7e414670d5044f •