Page 406 of 3285 results (0.022 seconds)

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 •

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

In the Linux kernel, the following vulnerability has been resolved: net/mlx5e: CT, Fix multiple allocations and memleak of mod acts CT clear action offload adds additional mod hdr actions to the flow's original mod actions in order to clear the registers which hold ct_state. When such flow also includes encap action, a neigh update event can cause the driver to unoffload the flow and then reoffload it. Each time this happens, the ct clear handling adds that same set of mod hdr actions to reset ct_state until the max of mod hdr actions is reached. Also the driver never releases the allocated mod hdr actions and causing a memleak. Fix above two issues by moving CT clear mod acts allocation into the parsing actions phase and only use it when offloading the rule. The release of mod acts will be done in the normal flow_put(). backtrace: [<000000007316e2f3>] krealloc+0x83/0xd0 [<00000000ef157de1>] mlx5e_mod_hdr_alloc+0x147/0x300 [mlx5_core] [<00000000970ce4ae>] mlx5e_tc_match_to_reg_set_and_get_id+0xd7/0x240 [mlx5_core] [<0000000067c5fa17>] mlx5e_tc_match_to_reg_set+0xa/0x20 [mlx5_core] [<00000000d032eb98>] mlx5_tc_ct_entry_set_registers.isra.0+0x36/0xc0 [mlx5_core] [<00000000fd23b869>] mlx5_tc_ct_flow_offload+0x272/0x1f10 [mlx5_core] [<000000004fc24acc>] mlx5e_tc_offload_fdb_rules.part.0+0x150/0x620 [mlx5_core] [<00000000dc741c17>] mlx5e_tc_encap_flows_add+0x489/0x690 [mlx5_core] [<00000000e92e49d7>] mlx5e_rep_update_flows+0x6e4/0x9b0 [mlx5_core] [<00000000f60f5602>] mlx5e_rep_neigh_update+0x39a/0x5d0 [mlx5_core] • https://git.kernel.org/stable/c/1ef3018f5af3da6376fae546e4dfc3f05f063815 https://git.kernel.org/stable/c/486e8de6e233ff2999493533c6259d1cb538653b https://git.kernel.org/stable/c/806401c20a0f9c51b6c8fd7035671e6ca841f6c2 •