Vulnerabilities

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 /> 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 /> 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 /> 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 /> 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 /> 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")

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 /> 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 /> 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 /> 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 /> 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 /> mm: vmscan: account for free pages to prevent infinite Loop in throttle_direct_reclaim()<br /> <br /> The task sometimes continues looping in throttle_direct_reclaim() because<br /> allow_direct_reclaim(pgdat) keeps returning false. <br /> <br /> #0 [ffff80002cb6f8d0] __switch_to at ffff8000080095ac<br /> #1 [ffff80002cb6f900] __schedule at ffff800008abbd1c<br /> #2 [ffff80002cb6f990] schedule at ffff800008abc50c<br /> #3 [ffff80002cb6f9b0] throttle_direct_reclaim at ffff800008273550<br /> #4 [ffff80002cb6fa20] try_to_free_pages at ffff800008277b68<br /> #5 [ffff80002cb6fae0] __alloc_pages_nodemask at ffff8000082c4660<br /> #6 [ffff80002cb6fc50] alloc_pages_vma at ffff8000082e4a98<br /> #7 [ffff80002cb6fca0] do_anonymous_page at ffff80000829f5a8<br /> #8 [ffff80002cb6fce0] __handle_mm_fault at ffff8000082a5974<br /> #9 [ffff80002cb6fd90] handle_mm_fault at ffff8000082a5bd4<br /> <br /> At this point, the pgdat contains the following two zones:<br /> <br /> NODE: 4 ZONE: 0 ADDR: ffff00817fffe540 NAME: "DMA32"<br /> SIZE: 20480 MIN/LOW/HIGH: 11/28/45<br /> VM_STAT:<br /> NR_FREE_PAGES: 359<br /> NR_ZONE_INACTIVE_ANON: 18813<br /> NR_ZONE_ACTIVE_ANON: 0<br /> NR_ZONE_INACTIVE_FILE: 50<br /> NR_ZONE_ACTIVE_FILE: 0<br /> NR_ZONE_UNEVICTABLE: 0<br /> NR_ZONE_WRITE_PENDING: 0<br /> NR_MLOCK: 0<br /> NR_BOUNCE: 0<br /> NR_ZSPAGES: 0<br /> NR_FREE_CMA_PAGES: 0<br /> <br /> NODE: 4 ZONE: 1 ADDR: ffff00817fffec00 NAME: "Normal"<br /> SIZE: 8454144 PRESENT: 98304 MIN/LOW/HIGH: 68/166/264<br /> VM_STAT:<br /> NR_FREE_PAGES: 146<br /> NR_ZONE_INACTIVE_ANON: 94668<br /> NR_ZONE_ACTIVE_ANON: 3<br /> NR_ZONE_INACTIVE_FILE: 735<br /> NR_ZONE_ACTIVE_FILE: 78<br /> NR_ZONE_UNEVICTABLE: 0<br /> NR_ZONE_WRITE_PENDING: 0<br /> NR_MLOCK: 0<br /> NR_BOUNCE: 0<br /> NR_ZSPAGES: 0<br /> NR_FREE_CMA_PAGES: 0<br /> <br /> In allow_direct_reclaim(), while processing ZONE_DMA32, the sum of<br /> inactive/active file-backed pages calculated in zone_reclaimable_pages()<br /> based on the result of zone_page_state_snapshot() is zero. <br /> <br /> Additionally, since this system lacks swap, the calculation of inactive/<br /> active anonymous pages is skipped.<br /> <br /> crash&gt; p nr_swap_pages<br /> nr_swap_pages = $1937 = {<br /> counter = 0<br /> }<br /> <br /> As a result, ZONE_DMA32 is deemed unreclaimable and skipped, moving on to<br /> the processing of the next zone, ZONE_NORMAL, despite ZONE_DMA32 having<br /> free pages significantly exceeding the high watermark.<br /> <br /> The problem is that the pgdat-&gt;kswapd_failures hasn&amp;#39;t been incremented.<br /> <br /> crash&gt; px ((struct pglist_data *) 0xffff00817fffe540)-&gt;kswapd_failures<br /> $1935 = 0x0<br /> <br /> This is because the node deemed balanced. The node balancing logic in<br /> balance_pgdat() evaluates all zones collectively. If one or more zones<br /> (e.g., ZONE_DMA32) have enough free pages to meet their watermarks, the<br /> entire node is deemed balanced. This causes balance_pgdat() to exit early<br /> before incrementing the kswapd_failures, as it considers the overall<br /> memory state acceptable, even though some zones (like ZONE_NORMAL) remain<br /> under significant pressure.<br /> <br /> <br /> The patch ensures that zone_reclaimable_pages() includes free pages<br /> (NR_FREE_PAGES) in its calculation when no other reclaimable pages are<br /> available (e.g., file-backed or anonymous pages). This change prevents<br /> zones like ZONE_DMA32, which have sufficient free pages, from being<br /> mistakenly deemed unreclaimable. By doing so, the patch ensures proper<br /> node balancing, avoids masking pressure on other zones like ZONE_NORMAL,<br /> and prevents infinite loops in throttle_direct_reclaim() caused by<br /> allow_direct_reclaim(pgdat) repeatedly returning false.<br /> <br /> <br /> The kernel hangs due to a task stuck in throttle_direct_reclaim(), caused<br /> by a node being incorrectly deemed balanced despite pressure in certain<br /> zones, such as ZONE_NORMAL. This issue arises from<br /> zone_reclaimable_pages<br /> ---truncated---