Vulnerabilities

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---

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> usb: typec: tipd: Remove WARN_ON in tps6598x_block_read<br /> <br /> Calling tps6598x_block_read with a higher than allowed len can be<br /> handled by just returning an error. There&amp;#39;s no need to crash systems<br /> with panic-on-warn enabled.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ALSA: usb-audio: fix null pointer dereference on pointer cs_desc<br /> <br /> The pointer cs_desc return from snd_usb_find_clock_source could<br /> be 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 /> net/mlx5: Update error handler for UCTX and UMEM<br /> <br /> In the fast unload flow, the device state is set to internal error,<br /> which indicates that the driver started the destroy process.<br /> In this case, when a destroy command is being executed, it should return<br /> MLX5_CMD_STAT_OK.<br /> Fix MLX5_CMD_OP_DESTROY_UCTX and MLX5_CMD_OP_DESTROY_UMEM to return OK<br /> instead of EIO.<br /> <br /> This fixes a call trace in the umem release process -<br /> [ 2633.536695] Call Trace:<br /> [ 2633.537518] ib_uverbs_remove_one+0xc3/0x140 [ib_uverbs]<br /> [ 2633.538596] remove_client_context+0x8b/0xd0 [ib_core]<br /> [ 2633.539641] disable_device+0x8c/0x130 [ib_core]<br /> [ 2633.540615] __ib_unregister_device+0x35/0xa0 [ib_core]<br /> [ 2633.541640] ib_unregister_device+0x21/0x30 [ib_core]<br /> [ 2633.542663] __mlx5_ib_remove+0x38/0x90 [mlx5_ib]<br /> [ 2633.543640] auxiliary_bus_remove+0x1e/0x30 [auxiliary]<br /> [ 2633.544661] device_release_driver_internal+0x103/0x1f0<br /> [ 2633.545679] bus_remove_device+0xf7/0x170<br /> [ 2633.546640] device_del+0x181/0x410<br /> [ 2633.547606] mlx5_rescan_drivers_locked.part.10+0x63/0x160 [mlx5_core]<br /> [ 2633.548777] mlx5_unregister_device+0x27/0x40 [mlx5_core]<br /> [ 2633.549841] mlx5_uninit_one+0x21/0xc0 [mlx5_core]<br /> [ 2633.550864] remove_one+0x69/0xe0 [mlx5_core]<br /> [ 2633.551819] pci_device_remove+0x3b/0xc0<br /> [ 2633.552731] device_release_driver_internal+0x103/0x1f0<br /> [ 2633.553746] unbind_store+0xf6/0x130<br /> [ 2633.554657] kernfs_fop_write+0x116/0x190<br /> [ 2633.555567] vfs_write+0xa5/0x1a0<br /> [ 2633.556407] ksys_write+0x4f/0xb0<br /> [ 2633.557233] do_syscall_64+0x5b/0x1a0<br /> [ 2633.558071] entry_SYSCALL_64_after_hwframe+0x65/0xca<br /> [ 2633.559018] RIP: 0033:0x7f9977132648<br /> [ 2633.559821] Code: 89 02 48 c7 c0 ff ff ff ff eb b3 0f 1f 80 00 00 00 00 f3 0f 1e fa 48 8d 05 55 6f 2d 00 8b 00 85 c0 75 17 b8 01 00 00 00 0f 05 3d 00 f0 ff ff 77 58 c3 0f 1f 80 00 00 00 00 41 54 49 89 d4 55<br /> [ 2633.562332] RSP: 002b:00007fffb1a83888 EFLAGS: 00000246 ORIG_RAX: 0000000000000001<br /> [ 2633.563472] RAX: ffffffffffffffda RBX: 000000000000000c RCX: 00007f9977132648<br /> [ 2633.564541] RDX: 000000000000000c RSI: 000055b90546e230 RDI: 0000000000000001<br /> [ 2633.565596] RBP: 000055b90546e230 R08: 00007f9977406860 R09: 00007f9977a54740<br /> [ 2633.566653] R10: 0000000000000000 R11: 0000000000000246 R12: 00007f99774056e0<br /> [ 2633.567692] R13: 000000000000000c R14: 00007f9977400880 R15: 000000000000000c<br /> [ 2633.568725] ---[ end trace 10b4fe52945e544d ]---

Rejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> hugetlb, userfaultfd: fix reservation restore on userfaultfd error<br /> <br /> Currently in the is_continue case in hugetlb_mcopy_atomic_pte(), if we<br /> bail out using "goto out_release_unlock;" in the cases where idx &gt;=<br /> size, or !huge_pte_none(), the code will detect that new_pagecache_page<br /> == false, and so call restore_reserve_on_error(). In this case I see<br /> restore_reserve_on_error() delete the reservation, and the following<br /> call to remove_inode_hugepages() will increment h-&gt;resv_hugepages<br /> causing a 100% reproducible leak.<br /> <br /> We should treat the is_continue case similar to adding a page into the<br /> pagecache and set new_pagecache_page to true, to indicate that there is<br /> no reservation to restore on the error path, and we need not call<br /> restore_reserve_on_error(). Rename new_pagecache_page to<br /> page_in_pagecache to make that clear.