Vulnerabilities

Use after free in Dawn in Google Chrome prior to 123.0.6312.122 allowed a remote attacker to potentially exploit heap corruption via a crafted HTML page. (Chromium security severity: High)

Heap buffer overflow in ANGLE in Google Chrome prior to 123.0.6312.122 allowed a remote attacker to potentially exploit heap corruption via a crafted HTML page. (Chromium security severity: High)

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

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

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> iavf: free q_vectors before queues in iavf_disable_vf<br /> <br /> iavf_free_queues() clears adapter-&gt;num_active_queues, which<br /> iavf_free_q_vectors() relies on, so swap the order of these two function<br /> calls in iavf_disable_vf(). This resolves a panic encountered when the<br /> interface is disabled and then later brought up again after PF<br /> communication is restored.

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

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

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: dpaa2-eth: fix use-after-free in dpaa2_eth_remove<br /> <br /> Access to netdev after free_netdev() will cause use-after-free bug.<br /> Move debug log before free_netdev() call to avoid it.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> clk: sunxi-ng: Unregister clocks/resets when unbinding<br /> <br /> Currently, unbinding a CCU driver unmaps the device&amp;#39;s MMIO region, while<br /> leaving its clocks/resets and their providers registered. This can cause<br /> a page fault later when some clock operation tries to perform MMIO. Fix<br /> this by separating the CCU initialization from the memory allocation,<br /> and then using a devres callback to unregister the clocks and resets.<br /> <br /> This also fixes a memory leak of the `struct ccu_reset`, and uses the<br /> correct owner (the specific platform driver) for the clocks and resets.<br /> <br /> Early OF clock providers are never unregistered, and limited error<br /> handling is possible, so they are mostly unchanged. The error reporting<br /> is made more consistent by moving the message inside of_sunxi_ccu_probe.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> usb: host: ohci-tmio: check return value after calling platform_get_resource()<br /> <br /> It will cause null-ptr-deref if platform_get_resource() returns NULL,<br /> we need check the return value.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ALSA: gus: fix null pointer dereference on pointer block<br /> <br /> The pointer block return from snd_gf1_dma_next_block could be<br /> null, so there is a potential null pointer dereference issue.<br /> Fix this by adding a null check before dereference.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> sched/fair: Prevent dead task groups from regaining cfs_rq&amp;#39;s<br /> <br /> Kevin is reporting crashes which point to a use-after-free of a cfs_rq<br /> in update_blocked_averages(). Initial debugging revealed that we&amp;#39;ve<br /> live cfs_rq&amp;#39;s (on_list=1) in an about to be kfree()&amp;#39;d task group in<br /> free_fair_sched_group(). However, it was unclear how that can happen.<br /> <br /> His kernel config happened to lead to a layout of struct sched_entity<br /> that put the &amp;#39;my_q&amp;#39; member directly into the middle of the object<br /> which makes it incidentally overlap with SLUB&amp;#39;s freelist pointer.<br /> That, in combination with SLAB_FREELIST_HARDENED&amp;#39;s freelist pointer<br /> mangling, leads to a reliable access violation in form of a #GP which<br /> made the UAF fail fast.<br /> <br /> Michal seems to have run into the same issue[1]. He already correctly<br /> diagnosed that commit a7b359fc6a37 ("sched/fair: Correctly insert<br /> cfs_rq&amp;#39;s to list on unthrottle") is causing the preconditions for the<br /> UAF to happen by re-adding cfs_rq&amp;#39;s also to task groups that have no<br /> more running tasks, i.e. also to dead ones. His analysis, however,<br /> misses the real root cause and it cannot be seen from the crash<br /> backtrace only, as the real offender is tg_unthrottle_up() getting<br /> called via sched_cfs_period_timer() via the timer interrupt at an<br /> inconvenient time.<br /> <br /> When unregister_fair_sched_group() unlinks all cfs_rq&amp;#39;s from the dying<br /> task group, it doesn&amp;#39;t protect itself from getting interrupted. If the<br /> timer interrupt triggers while we iterate over all CPUs or after<br /> unregister_fair_sched_group() has finished but prior to unlinking the<br /> task group, sched_cfs_period_timer() will execute and walk the list of<br /> task groups, trying to unthrottle cfs_rq&amp;#39;s, i.e. re-add them to the<br /> dying task group. These will later -- in free_fair_sched_group() -- be<br /> kfree()&amp;#39;ed while still being linked, leading to the fireworks Kevin<br /> and Michal are seeing.<br /> <br /> To fix this race, ensure the dying task group gets unlinked first.<br /> However, simply switching the order of unregistering and unlinking the<br /> task group isn&amp;#39;t sufficient, as concurrent RCU walkers might still see<br /> it, as can be seen below:<br /> <br /> CPU1: CPU2:<br /> : timer IRQ:<br /> : do_sched_cfs_period_timer():<br /> : :<br /> : distribute_cfs_runtime():<br /> : rcu_read_lock();<br /> : :<br /> : unthrottle_cfs_rq():<br /> sched_offline_group(): :<br /> : walk_tg_tree_from(…,tg_unthrottle_up,…):<br /> list_del_rcu(&amp;tg-&gt;list); :<br /> (1) : list_for_each_entry_rcu(child, &amp;parent-&gt;children, siblings)<br /> : :<br /> (2) list_del_rcu(&amp;tg-&gt;siblings); :<br /> : tg_unthrottle_up():<br /> unregister_fair_sched_group(): struct cfs_rq *cfs_rq = tg-&gt;cfs_rq[cpu_of(rq)];<br /> : :<br /> list_del_leaf_cfs_rq(tg-&gt;cfs_rq[cpu]); :<br /> : :<br /> : if (!cfs_rq_is_decayed(cfs_rq) || cfs_rq-&gt;nr_running)<br /> (3) : list_add_leaf_cfs_rq(cfs_rq);<br /> : :<br /> : :<br /> : :<br /> : :<br /> : <br /> ---truncated---