Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mm/damon/core: fix new damon_target objects leaks on damon_commit_targets()<br /> <br /> Patch series "mm/damon/core: fix memory leaks and ignored inputs from<br /> damon_commit_ctx()".<br /> <br /> Due to two bugs in damon_commit_targets() and damon_commit_schemes(),<br /> which are called from damon_commit_ctx(), some user inputs can be ignored,<br /> and some mmeory objects can be leaked. Fix those.<br /> <br /> Note that only DAMON sysfs interface users are affected. Other DAMON core<br /> API user modules that more focused more on simple and dedicated production<br /> usages, including DAMON_RECLAIM and DAMON_LRU_SORT are not using the buggy<br /> function in the way, so not affected.<br /> <br /> <br /> This patch (of 2):<br /> <br /> When new DAMON targets are added via damon_commit_targets(), the newly<br /> created targets are not deallocated when updating the internal data<br /> (damon_commit_target()) is failed. Worse yet, even if the setup is<br /> successfully done, the new target is not linked to the context. Hence,<br /> the new targets are always leaked regardless of the internal data setup<br /> failure. Fix the leaks.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm: adv7511: Fix use-after-free in adv7533_attach_dsi()<br /> <br /> The host_node pointer was assigned and freed in adv7533_parse_dt(), and<br /> later, adv7533_attach_dsi() uses the same. Fix this use-after-free issue<br /> by dropping of_node_put() in adv7533_parse_dt() and calling of_node_put()<br /> in error path of probe() and also in the remove().

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> workqueue: Do not warn when cancelling WQ_MEM_RECLAIM work from !WQ_MEM_RECLAIM worker<br /> <br /> After commit<br /> 746ae46c1113 ("drm/sched: Mark scheduler work queues with WQ_MEM_RECLAIM")<br /> amdgpu started seeing the following warning:<br /> <br /> [ ] workqueue: WQ_MEM_RECLAIM sdma0:drm_sched_run_job_work [gpu_sched] is flushing !WQ_MEM_RECLAIM events:amdgpu_device_delay_enable_gfx_off [amdgpu]<br /> ...<br /> [ ] Workqueue: sdma0 drm_sched_run_job_work [gpu_sched]<br /> ...<br /> [ ] Call Trace:<br /> [ ] <br /> ...<br /> [ ] ? check_flush_dependency+0xf5/0x110<br /> ...<br /> [ ] cancel_delayed_work_sync+0x6e/0x80<br /> [ ] amdgpu_gfx_off_ctrl+0xab/0x140 [amdgpu]<br /> [ ] amdgpu_ring_alloc+0x40/0x50 [amdgpu]<br /> [ ] amdgpu_ib_schedule+0xf4/0x810 [amdgpu]<br /> [ ] ? drm_sched_run_job_work+0x22c/0x430 [gpu_sched]<br /> [ ] amdgpu_job_run+0xaa/0x1f0 [amdgpu]<br /> [ ] drm_sched_run_job_work+0x257/0x430 [gpu_sched]<br /> [ ] process_one_work+0x217/0x720<br /> ...<br /> [ ] <br /> <br /> The intent of the verifcation done in check_flush_depedency is to ensure<br /> forward progress during memory reclaim, by flagging cases when either a<br /> memory reclaim process, or a memory reclaim work item is flushed from a<br /> context not marked as memory reclaim safe.<br /> <br /> This is correct when flushing, but when called from the<br /> cancel(_delayed)_work_sync() paths it is a false positive because work is<br /> either already running, or will not be running at all. Therefore<br /> cancelling it is safe and we can relax the warning criteria by letting the<br /> helper know of the calling context.<br /> <br /> References: 746ae46c1113 ("drm/sched: Mark scheduler work queues with WQ_MEM_RECLAIM")

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> pinctrl: mcp23s08: Fix sleeping in atomic context due to regmap locking<br /> <br /> If a device uses MCP23xxx IO expander to receive IRQs, the following<br /> bug can happen:<br /> <br /> BUG: sleeping function called from invalid context<br /> at kernel/locking/mutex.c:283<br /> in_atomic(): 1, irqs_disabled(): 1, non_block: 0, ...<br /> preempt_count: 1, expected: 0<br /> ...<br /> Call Trace:<br /> ...<br /> __might_resched+0x104/0x10e<br /> __might_sleep+0x3e/0x62<br /> mutex_lock+0x20/0x4c<br /> regmap_lock_mutex+0x10/0x18<br /> regmap_update_bits_base+0x2c/0x66<br /> mcp23s08_irq_set_type+0x1ae/0x1d6<br /> __irq_set_trigger+0x56/0x172<br /> __setup_irq+0x1e6/0x646<br /> request_threaded_irq+0xb6/0x160<br /> ...<br /> <br /> We observed the problem while experimenting with a touchscreen driver which<br /> used MCP23017 IO expander (I2C).<br /> <br /> The regmap in the pinctrl-mcp23s08 driver uses a mutex for protection from<br /> concurrent accesses, which is the default for regmaps without .fast_io,<br /> .disable_locking, etc.<br /> <br /> mcp23s08_irq_set_type() calls regmap_update_bits_base(), and the latter<br /> locks the mutex.<br /> <br /> However, __setup_irq() locks desc-&gt;lock spinlock before calling these<br /> functions. As a result, the system tries to lock the mutex whole holding<br /> the spinlock.<br /> <br /> It seems, the internal regmap locks are not needed in this driver at all.<br /> mcp-&gt;lock seems to protect the regmap from concurrent accesses already,<br /> except, probably, in mcp_pinconf_get/set.<br /> <br /> mcp23s08_irq_set_type() and mcp23s08_irq_mask/unmask() are called under<br /> chip_bus_lock(), which calls mcp23s08_irq_bus_lock(). The latter takes<br /> mcp-&gt;lock and enables regmap caching, so that the potentially slow I2C<br /> accesses are deferred until chip_bus_unlock().<br /> <br /> The accesses to the regmap from mcp23s08_probe_one() do not need additional<br /> locking.<br /> <br /> In all remaining places where the regmap is accessed, except<br /> mcp_pinconf_get/set(), the driver already takes mcp-&gt;lock.<br /> <br /> This patch adds locking in mcp_pinconf_get/set() and disables internal<br /> locking in the regmap config. Among other things, it fixes the sleeping<br /> in atomic context described above.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> RDMA/uverbs: Prevent integer overflow issue<br /> <br /> In the expression "cmd.wqe_size * cmd.wr_count", both variables are u32<br /> values that come from the user so the multiplication can lead to integer<br /> wrapping. Then we pass the result to uverbs_request_next_ptr() which also<br /> could potentially wrap. The "cmd.sge_count * sizeof(struct ib_uverbs_sge)"<br /> multiplication can also overflow on 32bit systems although it&amp;#39;s fine on<br /> 64bit systems.<br /> <br /> This patch does two things. First, I&amp;#39;ve re-arranged the condition in<br /> uverbs_request_next_ptr() so that the use controlled variable "len" is on<br /> one side of the comparison by itself without any math. Then I&amp;#39;ve modified<br /> all the callers to use size_mul() for the multiplications.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> sched_ext: Fix invalid irq restore in scx_ops_bypass()<br /> <br /> While adding outer irqsave/restore locking, 0e7ffff1b811 ("scx: Fix raciness<br /> in scx_ops_bypass()") forgot to convert an inner rq_unlock_irqrestore() to<br /> rq_unlock() which could re-enable IRQ prematurely leading to the following<br /> warning:<br /> <br /> raw_local_irq_restore() called with IRQs enabled<br /> WARNING: CPU: 1 PID: 96 at kernel/locking/irqflag-debug.c:10 warn_bogus_irq_restore+0x30/0x40<br /> ...<br /> Sched_ext: create_dsq (enabling)<br /> pstate: 60400005 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)<br /> pc : warn_bogus_irq_restore+0x30/0x40<br /> lr : warn_bogus_irq_restore+0x30/0x40<br /> ...<br /> Call trace:<br /> warn_bogus_irq_restore+0x30/0x40 (P)<br /> warn_bogus_irq_restore+0x30/0x40 (L)<br /> scx_ops_bypass+0x224/0x3b8<br /> scx_ops_enable.isra.0+0x2c8/0xaa8<br /> bpf_scx_reg+0x18/0x30<br /> ...<br /> irq event stamp: 33739<br /> hardirqs last enabled at (33739): [] scx_ops_bypass+0x174/0x3b8<br /> hardirqs last disabled at (33738): [] _raw_spin_lock_irqsave+0xb4/0xd8<br /> <br /> Drop the stray _irqrestore().

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ocfs2: fix slab-use-after-free due to dangling pointer dqi_priv<br /> <br /> When mounting ocfs2 and then remounting it as read-only, a<br /> slab-use-after-free occurs after the user uses a syscall to<br /> quota_getnextquota. Specifically, sb_dqinfo(sb, type)-&gt;dqi_priv is the<br /> dangling pointer.<br /> <br /> During the remounting process, the pointer dqi_priv is freed but is never<br /> set as null leaving it to be accessed. Additionally, the read-only option<br /> for remounting sets the DQUOT_SUSPENDED flag instead of setting the<br /> DQUOT_USAGE_ENABLED flags. Moreover, later in the process of getting the<br /> next quota, the function ocfs2_get_next_id is called and only checks the<br /> quota usage flags and not the quota suspended flags.<br /> <br /> To fix this, I set dqi_priv to null when it is freed after remounting with<br /> read-only and put a check for DQUOT_SUSPENDED in ocfs2_get_next_id.<br /> <br /> [akpm@linux-foundation.org: coding-style cleanups]

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ALSA: seq: oss: Fix races at processing SysEx messages<br /> <br /> OSS sequencer handles the SysEx messages split in 6 bytes packets, and<br /> ALSA sequencer OSS layer tries to combine those. It stores the data<br /> in the internal buffer and this access is racy as of now, which may<br /> lead to the out-of-bounds access.<br /> <br /> As a temporary band-aid fix, introduce a mutex for serializing the<br /> process of the SysEx message packets.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> Bluetooth: hci_core: Fix sleeping function called from invalid context<br /> <br /> This reworks hci_cb_list to not use mutex hci_cb_list_lock to avoid bugs<br /> like the bellow:<br /> <br /> BUG: sleeping function called from invalid context at kernel/locking/mutex.c:585<br /> in_atomic(): 0, irqs_disabled(): 0, non_block: 0, pid: 5070, name: kworker/u9:2<br /> preempt_count: 0, expected: 0<br /> RCU nest depth: 1, expected: 0<br /> 4 locks held by kworker/u9:2/5070:<br /> #0: ffff888015be3948 ((wq_completion)hci0#2){+.+.}-{0:0}, at: process_one_work kernel/workqueue.c:3229 [inline]<br /> #0: ffff888015be3948 ((wq_completion)hci0#2){+.+.}-{0:0}, at: process_scheduled_works+0x8e0/0x1770 kernel/workqueue.c:3335<br /> #1: ffffc90003b6fd00 ((work_completion)(&amp;hdev-&gt;rx_work)){+.+.}-{0:0}, at: process_one_work kernel/workqueue.c:3230 [inline]<br /> #1: ffffc90003b6fd00 ((work_completion)(&amp;hdev-&gt;rx_work)){+.+.}-{0:0}, at: process_scheduled_works+0x91b/0x1770 kernel/workqueue.c:3335<br /> #2: ffff8880665d0078 (&amp;hdev-&gt;lock){+.+.}-{3:3}, at: hci_le_create_big_complete_evt+0xcf/0xae0 net/bluetooth/hci_event.c:6914<br /> #3: ffffffff8e132020 (rcu_read_lock){....}-{1:2}, at: rcu_lock_acquire include/linux/rcupdate.h:298 [inline]<br /> #3: ffffffff8e132020 (rcu_read_lock){....}-{1:2}, at: rcu_read_lock include/linux/rcupdate.h:750 [inline]<br /> #3: ffffffff8e132020 (rcu_read_lock){....}-{1:2}, at: hci_le_create_big_complete_evt+0xdb/0xae0 net/bluetooth/hci_event.c:6915<br /> CPU: 0 PID: 5070 Comm: kworker/u9:2 Not tainted 6.8.0-syzkaller-08073-g480e035fc4c7 #0<br /> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 03/27/2024<br /> Workqueue: hci0 hci_rx_work<br /> Call Trace:<br /> <br /> __dump_stack lib/dump_stack.c:88 [inline]<br /> dump_stack_lvl+0x241/0x360 lib/dump_stack.c:114<br /> __might_resched+0x5d4/0x780 kernel/sched/core.c:10187<br /> __mutex_lock_common kernel/locking/mutex.c:585 [inline]<br /> __mutex_lock+0xc1/0xd70 kernel/locking/mutex.c:752<br /> hci_connect_cfm include/net/bluetooth/hci_core.h:2004 [inline]<br /> hci_le_create_big_complete_evt+0x3d9/0xae0 net/bluetooth/hci_event.c:6939<br /> hci_event_func net/bluetooth/hci_event.c:7514 [inline]<br /> hci_event_packet+0xa53/0x1540 net/bluetooth/hci_event.c:7569<br /> hci_rx_work+0x3e8/0xca0 net/bluetooth/hci_core.c:4171<br /> process_one_work kernel/workqueue.c:3254 [inline]<br /> process_scheduled_works+0xa00/0x1770 kernel/workqueue.c:3335<br /> worker_thread+0x86d/0xd70 kernel/workqueue.c:3416<br /> kthread+0x2f0/0x390 kernel/kthread.c:388<br /> ret_from_fork+0x4b/0x80 arch/x86/kernel/process.c:147<br /> ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:243<br />

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: fix memory leak in tcp_conn_request()<br /> <br /> If inet_csk_reqsk_queue_hash_add() return false, tcp_conn_request() will<br /> return without free the dst memory, which allocated in af_ops-&gt;route_req.<br /> <br /> Here is the kmemleak stack:<br /> <br /> unreferenced object 0xffff8881198631c0 (size 240):<br /> comm "softirq", pid 0, jiffies 4299266571 (age 1802.392s)<br /> hex dump (first 32 bytes):<br /> 00 10 9b 03 81 88 ff ff 80 98 da bc ff ff ff ff ................<br /> 81 55 18 bb ff ff ff ff 00 00 00 00 00 00 00 00 .U..............<br /> backtrace:<br /> [] kmem_cache_alloc+0x60c/0xa80<br /> [] dst_alloc+0x55/0x250<br /> [] rt_dst_alloc+0x46/0x1d0<br /> [] __mkroute_output+0x29a/0xa50<br /> [] ip_route_output_key_hash+0x10b/0x240<br /> [] ip_route_output_flow+0x1d/0x90<br /> [] inet_csk_route_req+0x2c5/0x500<br /> [] tcp_conn_request+0x691/0x12c0<br /> [] tcp_rcv_state_process+0x3c8/0x11b0<br /> [] tcp_v4_do_rcv+0x156/0x3b0<br /> [] tcp_v4_rcv+0x1cf8/0x1d80<br /> [] ip_protocol_deliver_rcu+0xf6/0x360<br /> [] ip_local_deliver_finish+0xe6/0x1e0<br /> [] ip_local_deliver+0xee/0x360<br /> [] ip_rcv+0xad/0x2f0<br /> [] __netif_receive_skb_one_core+0x123/0x140<br /> <br /> Call dst_release() to free the dst memory when<br /> inet_csk_reqsk_queue_hash_add() return false in tcp_conn_request().

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/xe: Fix fault on fd close after unbind<br /> <br /> If userspace holds an fd open, unbinds the device and then closes it,<br /> the driver shouldn&amp;#39;t try to access the hardware. Protect it by using<br /> drm_dev_enter()/drm_dev_exit(). This fixes the following page fault:<br /> <br /> [IGT] xe_wedged: exiting, ret=98<br /> BUG: unable to handle page fault for address: ffffc901bc5e508c<br /> #PF: supervisor read access in kernel mode<br /> #PF: error_code(0x0000) - not-present page<br /> ...<br /> xe_lrc_update_timestamp+0x1c/0xd0 [xe]<br /> xe_exec_queue_update_run_ticks+0x50/0xb0 [xe]<br /> xe_exec_queue_fini+0x16/0xb0 [xe]<br /> __guc_exec_queue_fini_async+0xc4/0x190 [xe]<br /> guc_exec_queue_fini_async+0xa0/0xe0 [xe]<br /> guc_exec_queue_fini+0x23/0x40 [xe]<br /> xe_exec_queue_destroy+0xb3/0xf0 [xe]<br /> xe_file_close+0xd4/0x1a0 [xe]<br /> drm_file_free+0x210/0x280 [drm]<br /> drm_close_helper.isra.0+0x6d/0x80 [drm]<br /> drm_release_noglobal+0x20/0x90 [drm]<br /> <br /> (cherry picked from commit 4ca1fd418338d4d135428a0eb1e16e3b3ce17ee8)

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> RDMA/siw: Remove direct link to net_device<br /> <br /> Do not manage a per device direct link to net_device. Rely<br /> on associated ib_devices net_device management, not doubling<br /> the effort locally. A badly managed local link to net_device<br /> was causing a &amp;#39;KASAN: slab-use-after-free&amp;#39; exception during<br /> siw_query_port() call.