Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> netfilter: ipset: Fix suspicious rcu_dereference_protected()<br /> <br /> When destroying all sets, we are either in pernet exit phase or<br /> are executing a "destroy all sets command" from userspace. The latter<br /> was taken into account in ip_set_dereference() (nfnetlink mutex is held),<br /> but the former was not. The patch adds the required check to<br /> rcu_dereference_protected() in ip_set_dereference().

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ptp: fix integer overflow in max_vclocks_store<br /> <br /> On 32bit systems, the "4 * max" multiply can overflow. Use kcalloc()<br /> to do the allocation to prevent this.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net/sched: act_api: fix possible infinite loop in tcf_idr_check_alloc()<br /> <br /> syzbot found hanging tasks waiting on rtnl_lock [1]<br /> <br /> A reproducer is available in the syzbot bug.<br /> <br /> When a request to add multiple actions with the same index is sent, the<br /> second request will block forever on the first request. This holds<br /> rtnl_lock, and causes tasks to hang.<br /> <br /> Return -EAGAIN to prevent infinite looping, while keeping documented<br /> behavior.<br /> <br /> [1]<br /> <br /> INFO: task kworker/1:0:5088 blocked for more than 143 seconds.<br /> Not tainted 6.9.0-rc4-syzkaller-00173-g3cdb45594619 #0<br /> "echo 0 &gt; /proc/sys/kernel/hung_task_timeout_secs" disables this message.<br /> task:kworker/1:0 state:D stack:23744 pid:5088 tgid:5088 ppid:2 flags:0x00004000<br /> Workqueue: events_power_efficient reg_check_chans_work<br /> Call Trace:<br /> <br /> context_switch kernel/sched/core.c:5409 [inline]<br /> __schedule+0xf15/0x5d00 kernel/sched/core.c:6746<br /> __schedule_loop kernel/sched/core.c:6823 [inline]<br /> schedule+0xe7/0x350 kernel/sched/core.c:6838<br /> schedule_preempt_disabled+0x13/0x30 kernel/sched/core.c:6895<br /> __mutex_lock_common kernel/locking/mutex.c:684 [inline]<br /> __mutex_lock+0x5b8/0x9c0 kernel/locking/mutex.c:752<br /> wiphy_lock include/net/cfg80211.h:5953 [inline]<br /> reg_leave_invalid_chans net/wireless/reg.c:2466 [inline]<br /> reg_check_chans_work+0x10a/0x10e0 net/wireless/reg.c:2481

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> bpf: Avoid splat in pskb_pull_reason<br /> <br /> syzkaller builds (CONFIG_DEBUG_NET=y) frequently trigger a debug<br /> hint in pskb_may_pull.<br /> <br /> We&amp;#39;d like to retain this debug check because it might hint at integer<br /> overflows and other issues (kernel code should pull headers, not huge<br /> value).<br /> <br /> In bpf case, this splat isn&amp;#39;t interesting at all: such (nonsensical)<br /> bpf programs are typically generated by a fuzzer anyway.<br /> <br /> Do what Eric suggested and suppress such warning.<br /> <br /> For CONFIG_DEBUG_NET=n we don&amp;#39;t need the extra check because<br /> pskb_may_pull will do the right thing: return an error without the<br /> WARN() backtrace.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> platform/x86: x86-android-tablets: Unregister devices in reverse order<br /> <br /> Not all subsystems support a device getting removed while there are<br /> still consumers of the device with a reference to the device.<br /> <br /> One example of this is the regulator subsystem. If a regulator gets<br /> unregistered while there are still drivers holding a reference<br /> a WARN() at drivers/regulator/core.c:5829 triggers, e.g.:<br /> <br /> WARNING: CPU: 1 PID: 1587 at drivers/regulator/core.c:5829 regulator_unregister<br /> Hardware name: Intel Corp. VALLEYVIEW C0 PLATFORM/BYT-T FFD8, BIOS BLADE_21.X64.0005.R00.1504101516 FFD8_X64_R_2015_04_10_1516 04/10/2015<br /> RIP: 0010:regulator_unregister<br /> Call Trace:<br /> <br /> regulator_unregister<br /> devres_release_group<br /> i2c_device_remove<br /> device_release_driver_internal<br /> bus_remove_device<br /> device_del<br /> device_unregister<br /> x86_android_tablet_remove<br /> <br /> On the Lenovo Yoga Tablet 2 series the bq24190 charger chip also provides<br /> a 5V boost converter output for powering USB devices connected to the micro<br /> USB port, the bq24190-charger driver exports this as a Vbus regulator.<br /> <br /> On the 830 (8") and 1050 ("10") models this regulator is controlled by<br /> a platform_device and x86_android_tablet_remove() removes platform_device-s<br /> before i2c_clients so the consumer gets removed first.<br /> <br /> But on the 1380 (13") model there is a lc824206xa micro-USB switch<br /> connected over I2C and the extcon driver for that controls the regulator.<br /> The bq24190 i2c-client *must* be registered first, because that creates<br /> the regulator with the lc824206xa listed as its consumer. If the regulator<br /> has not been registered yet the lc824206xa driver will end up getting<br /> a dummy regulator.<br /> <br /> Since in this case both the regulator provider and consumer are I2C<br /> devices, the only way to ensure that the consumer is unregistered first<br /> is to unregister the I2C devices in reverse order of in which they were<br /> created.<br /> <br /> For consistency and to avoid similar problems in the future change<br /> x86_android_tablet_remove() to unregister all device types in reverse<br /> order.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> wifi: ath12k: fix kernel crash during resume<br /> <br /> Currently during resume, QMI target memory is not properly handled, resulting<br /> in kernel crash in case DMA remap is not supported:<br /> <br /> BUG: Bad page state in process kworker/u16:54 pfn:36e80<br /> page: refcount:1 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x36e80<br /> page dumped because: nonzero _refcount<br /> Call Trace:<br /> bad_page<br /> free_page_is_bad_report<br /> __free_pages_ok<br /> __free_pages<br /> dma_direct_free<br /> dma_free_attrs<br /> ath12k_qmi_free_target_mem_chunk<br /> ath12k_qmi_msg_mem_request_cb<br /> <br /> The reason is:<br /> Once ath12k module is loaded, firmware sends memory request to host. In case<br /> DMA remap not supported, ath12k refuses the first request due to failure in<br /> allocating with large segment size:<br /> <br /> ath12k_pci 0000:04:00.0: qmi firmware request memory request<br /> ath12k_pci 0000:04:00.0: qmi mem seg type 1 size 7077888<br /> ath12k_pci 0000:04:00.0: qmi mem seg type 4 size 8454144<br /> ath12k_pci 0000:04:00.0: qmi dma allocation failed (7077888 B type 1), will try later with small size<br /> ath12k_pci 0000:04:00.0: qmi delays mem_request 2<br /> ath12k_pci 0000:04:00.0: qmi firmware request memory request<br /> <br /> Later firmware comes back with more but small segments and allocation<br /> succeeds:<br /> <br /> ath12k_pci 0000:04:00.0: qmi mem seg type 1 size 524288<br /> ath12k_pci 0000:04:00.0: qmi mem seg type 1 size 524288<br /> ath12k_pci 0000:04:00.0: qmi mem seg type 1 size 524288<br /> ath12k_pci 0000:04:00.0: qmi mem seg type 1 size 524288<br /> ath12k_pci 0000:04:00.0: qmi mem seg type 1 size 524288<br /> ath12k_pci 0000:04:00.0: qmi mem seg type 1 size 524288<br /> ath12k_pci 0000:04:00.0: qmi mem seg type 1 size 524288<br /> ath12k_pci 0000:04:00.0: qmi mem seg type 1 size 262144<br /> ath12k_pci 0000:04:00.0: qmi mem seg type 1 size 524288<br /> ath12k_pci 0000:04:00.0: qmi mem seg type 1 size 524288<br /> ath12k_pci 0000:04:00.0: qmi mem seg type 1 size 524288<br /> ath12k_pci 0000:04:00.0: qmi mem seg type 1 size 524288<br /> ath12k_pci 0000:04:00.0: qmi mem seg type 1 size 524288<br /> ath12k_pci 0000:04:00.0: qmi mem seg type 4 size 524288<br /> ath12k_pci 0000:04:00.0: qmi mem seg type 4 size 524288<br /> ath12k_pci 0000:04:00.0: qmi mem seg type 4 size 524288<br /> ath12k_pci 0000:04:00.0: qmi mem seg type 4 size 524288<br /> ath12k_pci 0000:04:00.0: qmi mem seg type 4 size 524288<br /> ath12k_pci 0000:04:00.0: qmi mem seg type 4 size 524288<br /> ath12k_pci 0000:04:00.0: qmi mem seg type 4 size 524288<br /> ath12k_pci 0000:04:00.0: qmi mem seg type 4 size 524288<br /> ath12k_pci 0000:04:00.0: qmi mem seg type 4 size 524288<br /> ath12k_pci 0000:04:00.0: qmi mem seg type 4 size 524288<br /> ath12k_pci 0000:04:00.0: qmi mem seg type 4 size 524288<br /> ath12k_pci 0000:04:00.0: qmi mem seg type 4 size 524288<br /> ath12k_pci 0000:04:00.0: qmi mem seg type 4 size 524288<br /> ath12k_pci 0000:04:00.0: qmi mem seg type 4 size 524288<br /> ath12k_pci 0000:04:00.0: qmi mem seg type 4 size 524288<br /> ath12k_pci 0000:04:00.0: qmi mem seg type 4 size 524288<br /> ath12k_pci 0000:04:00.0: qmi mem seg type 4 size 65536<br /> ath12k_pci 0000:04:00.0: qmi mem seg type 1 size 524288<br /> <br /> Now ath12k is working. If suspend is triggered, firmware will be reloaded<br /> during resume. As same as before, firmware requests two large segments at<br /> first. In ath12k_qmi_msg_mem_request_cb() segment count and size are<br /> assigned:<br /> <br /> ab-&gt;qmi.mem_seg_count == 2<br /> ab-&gt;qmi.target_mem[0].size == 7077888<br /> ab-&gt;qmi.target_mem[1].size == 8454144<br /> <br /> Then allocation failed like before and ath12k_qmi_free_target_mem_chunk()<br /> is called to free all allocated segments. Note the first segment is skipped<br /> because its v.addr is cleared due to allocation failure:<br /> <br /> chunk-&gt;v.addr = dma_alloc_coherent()<br /> <br /> Also note that this leaks that segment because it has not been freed.<br /> <br /> While freeing the second segment, a size of 8454144 is passed to<br /> dma_free_coherent(). However remember that this segment is allocated at<br /> the first time firmware is loaded, before suspend. So its real size is<br /> 524288, much smaller than 8454144. As a result kernel found we are freeing<br /> some memory which is in use and thus cras<br /> ---truncated---

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/lima: mask irqs in timeout path before hard reset<br /> <br /> There is a race condition in which a rendering job might take just long<br /> enough to trigger the drm sched job timeout handler but also still<br /> complete before the hard reset is done by the timeout handler.<br /> This runs into race conditions not expected by the timeout handler.<br /> In some very specific cases it currently may result in a refcount<br /> imbalance on lima_pm_idle, with a stack dump such as:<br /> <br /> [10136.669170] WARNING: CPU: 0 PID: 0 at drivers/gpu/drm/lima/lima_devfreq.c:205 lima_devfreq_record_idle+0xa0/0xb0<br /> ...<br /> [10136.669459] pc : lima_devfreq_record_idle+0xa0/0xb0<br /> ...<br /> [10136.669628] Call trace:<br /> [10136.669634] lima_devfreq_record_idle+0xa0/0xb0<br /> [10136.669646] lima_sched_pipe_task_done+0x5c/0xb0<br /> [10136.669656] lima_gp_irq_handler+0xa8/0x120<br /> [10136.669666] __handle_irq_event_percpu+0x48/0x160<br /> [10136.669679] handle_irq_event+0x4c/0xc0<br /> <br /> We can prevent that race condition entirely by masking the irqs at the<br /> beginning of the timeout handler, at which point we give up on waiting<br /> for that job entirely.<br /> The irqs will be enabled again at the next hard reset which is already<br /> done as a recovery by the timeout handler.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> wifi: mt76: mt7921s: fix potential hung tasks during chip recovery<br /> <br /> During chip recovery (e.g. chip reset), there is a possible situation that<br /> kernel worker reset_work is holding the lock and waiting for kernel thread<br /> stat_worker to be parked, while stat_worker is waiting for the release of<br /> the same lock.<br /> It causes a deadlock resulting in the dumping of hung tasks messages and<br /> possible rebooting of the device.<br /> <br /> This patch prevents the execution of stat_worker during the chip recovery.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> scsi: qedi: Fix crash while reading debugfs attribute<br /> <br /> The qedi_dbg_do_not_recover_cmd_read() function invokes sprintf() directly<br /> on a __user pointer, which results into the crash.<br /> <br /> To fix this issue, use a small local stack buffer for sprintf() and then<br /> call simple_read_from_buffer(), which in turns make the copy_to_user()<br /> call.<br /> <br /> BUG: unable to handle page fault for address: 00007f4801111000<br /> PGD 8000000864df6067 P4D 8000000864df6067 PUD 864df7067 PMD 846028067 PTE 0<br /> Oops: 0002 [#1] PREEMPT SMP PTI<br /> Hardware name: HPE ProLiant DL380 Gen10/ProLiant DL380 Gen10, BIOS U30 06/15/2023<br /> RIP: 0010:memcpy_orig+0xcd/0x130<br /> RSP: 0018:ffffb7a18c3ffc40 EFLAGS: 00010202<br /> RAX: 00007f4801111000 RBX: 00007f4801111000 RCX: 000000000000000f<br /> RDX: 000000000000000f RSI: ffffffffc0bfd7a0 RDI: 00007f4801111000<br /> RBP: ffffffffc0bfd7a0 R08: 725f746f6e5f6f64 R09: 3d7265766f636572<br /> R10: ffffb7a18c3ffd08 R11: 0000000000000000 R12: 00007f4881110fff<br /> R13: 000000007fffffff R14: ffffb7a18c3ffca0 R15: ffffffffc0bfd7af<br /> FS: 00007f480118a740(0000) GS:ffff98e38af00000(0000) knlGS:0000000000000000<br /> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> CR2: 00007f4801111000 CR3: 0000000864b8e001 CR4: 00000000007706e0<br /> DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000<br /> DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400<br /> PKRU: 55555554<br /> Call Trace:<br /> <br /> ? __die_body+0x1a/0x60<br /> ? page_fault_oops+0x183/0x510<br /> ? exc_page_fault+0x69/0x150<br /> ? asm_exc_page_fault+0x22/0x30<br /> ? memcpy_orig+0xcd/0x130<br /> vsnprintf+0x102/0x4c0<br /> sprintf+0x51/0x80<br /> qedi_dbg_do_not_recover_cmd_read+0x2f/0x50 [qedi 6bcfdeeecdea037da47069eca2ba717c84a77324]<br /> full_proxy_read+0x50/0x80<br /> vfs_read+0xa5/0x2e0<br /> ? folio_add_new_anon_rmap+0x44/0xa0<br /> ? set_pte_at+0x15/0x30<br /> ? do_pte_missing+0x426/0x7f0<br /> ksys_read+0xa5/0xe0<br /> do_syscall_64+0x58/0x80<br /> ? __count_memcg_events+0x46/0x90<br /> ? count_memcg_event_mm+0x3d/0x60<br /> ? handle_mm_fault+0x196/0x2f0<br /> ? do_user_addr_fault+0x267/0x890<br /> ? exc_page_fault+0x69/0x150<br /> entry_SYSCALL_64_after_hwframe+0x72/0xdc<br /> RIP: 0033:0x7f4800f20b4d

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drop_monitor: replace spin_lock by raw_spin_lock<br /> <br /> trace_drop_common() is called with preemption disabled, and it acquires<br /> a spin_lock. This is problematic for RT kernels because spin_locks are<br /> sleeping locks in this configuration, which causes the following splat:<br /> <br /> BUG: sleeping function called from invalid context at kernel/locking/spinlock_rt.c:48<br /> in_atomic(): 1, irqs_disabled(): 1, non_block: 0, pid: 449, name: rcuc/47<br /> preempt_count: 1, expected: 0<br /> RCU nest depth: 2, expected: 2<br /> 5 locks held by rcuc/47/449:<br /> #0: ff1100086ec30a60 ((softirq_ctrl.lock)){+.+.}-{2:2}, at: __local_bh_disable_ip+0x105/0x210<br /> #1: ffffffffb394a280 (rcu_read_lock){....}-{1:2}, at: rt_spin_lock+0xbf/0x130<br /> #2: ffffffffb394a280 (rcu_read_lock){....}-{1:2}, at: __local_bh_disable_ip+0x11c/0x210<br /> #3: ffffffffb394a160 (rcu_callback){....}-{0:0}, at: rcu_do_batch+0x360/0xc70<br /> #4: ff1100086ee07520 (&amp;data-&gt;lock){+.+.}-{2:2}, at: trace_drop_common.constprop.0+0xb5/0x290<br /> irq event stamp: 139909<br /> hardirqs last enabled at (139908): [] _raw_spin_unlock_irqrestore+0x63/0x80<br /> hardirqs last disabled at (139909): [] trace_drop_common.constprop.0+0x26d/0x290<br /> softirqs last enabled at (139892): [] __local_bh_enable_ip+0x103/0x170<br /> softirqs last disabled at (139898): [] rcu_cpu_kthread+0x93/0x1f0<br /> Preemption disabled at:<br /> [] rt_mutex_slowunlock+0xab/0x2e0<br /> CPU: 47 PID: 449 Comm: rcuc/47 Not tainted 6.9.0-rc2-rt1+ #7<br /> Hardware name: Dell Inc. PowerEdge R650/0Y2G81, BIOS 1.6.5 04/15/2022<br /> Call Trace:<br /> <br /> dump_stack_lvl+0x8c/0xd0<br /> dump_stack+0x14/0x20<br /> __might_resched+0x21e/0x2f0<br /> rt_spin_lock+0x5e/0x130<br /> ? trace_drop_common.constprop.0+0xb5/0x290<br /> ? skb_queue_purge_reason.part.0+0x1bf/0x230<br /> trace_drop_common.constprop.0+0xb5/0x290<br /> ? preempt_count_sub+0x1c/0xd0<br /> ? _raw_spin_unlock_irqrestore+0x4a/0x80<br /> ? __pfx_trace_drop_common.constprop.0+0x10/0x10<br /> ? rt_mutex_slowunlock+0x26a/0x2e0<br /> ? skb_queue_purge_reason.part.0+0x1bf/0x230<br /> ? __pfx_rt_mutex_slowunlock+0x10/0x10<br /> ? skb_queue_purge_reason.part.0+0x1bf/0x230<br /> trace_kfree_skb_hit+0x15/0x20<br /> trace_kfree_skb+0xe9/0x150<br /> kfree_skb_reason+0x7b/0x110<br /> skb_queue_purge_reason.part.0+0x1bf/0x230<br /> ? __pfx_skb_queue_purge_reason.part.0+0x10/0x10<br /> ? mark_lock.part.0+0x8a/0x520<br /> ...<br /> <br /> trace_drop_common() also disables interrupts, but this is a minor issue<br /> because we could easily replace it with a local_lock.<br /> <br /> Replace the spin_lock with raw_spin_lock to avoid sleeping in atomic<br /> context.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> batman-adv: bypass empty buckets in batadv_purge_orig_ref()<br /> <br /> Many syzbot reports are pointing to soft lockups in<br /> batadv_purge_orig_ref() [1]<br /> <br /> Root cause is unknown, but we can avoid spending too much<br /> time there and perhaps get more interesting reports.<br /> <br /> [1]<br /> <br /> watchdog: BUG: soft lockup - CPU#0 stuck for 27s! [kworker/u4:6:621]<br /> Modules linked in:<br /> irq event stamp: 6182794<br /> hardirqs last enabled at (6182793): [] __local_bh_enable_ip+0x224/0x44c kernel/softirq.c:386<br /> hardirqs last disabled at (6182794): [] __el1_irq arch/arm64/kernel/entry-common.c:533 [inline]<br /> hardirqs last disabled at (6182794): [] el1_interrupt+0x24/0x68 arch/arm64/kernel/entry-common.c:551<br /> softirqs last enabled at (6182792): [] spin_unlock_bh include/linux/spinlock.h:396 [inline]<br /> softirqs last enabled at (6182792): [] batadv_purge_orig_ref+0x114c/0x1228 net/batman-adv/originator.c:1287<br /> softirqs last disabled at (6182790): [] spin_lock_bh include/linux/spinlock.h:356 [inline]<br /> softirqs last disabled at (6182790): [] batadv_purge_orig_ref+0x164/0x1228 net/batman-adv/originator.c:1271<br /> CPU: 0 PID: 621 Comm: kworker/u4:6 Not tainted 6.8.0-rc7-syzkaller-g707081b61156 #0<br /> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 02/29/2024<br /> Workqueue: bat_events batadv_purge_orig<br /> pstate: 80400005 (Nzcv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)<br /> pc : should_resched arch/arm64/include/asm/preempt.h:79 [inline]<br /> pc : __local_bh_enable_ip+0x228/0x44c kernel/softirq.c:388<br /> lr : __local_bh_enable_ip+0x224/0x44c kernel/softirq.c:386<br /> sp : ffff800099007970<br /> x29: ffff800099007980 x28: 1fffe00018fce1bd x27: dfff800000000000<br /> x26: ffff0000d2620008 x25: ffff0000c7e70de8 x24: 0000000000000001<br /> x23: 1fffe00018e57781 x22: dfff800000000000 x21: ffff80008aab71c4<br /> x20: ffff0001b40136c0 x19: ffff0000c72bbc08 x18: 1fffe0001a817bb0<br /> x17: ffff800125414000 x16: ffff80008032116c x15: 0000000000000001<br /> x14: 1fffe0001ee9d610 x13: 0000000000000000 x12: 0000000000000003<br /> x11: 0000000000000000 x10: 0000000000ff0100 x9 : 0000000000000000<br /> x8 : 00000000005e5789 x7 : ffff80008aab61dc x6 : 0000000000000000<br /> x5 : 0000000000000000 x4 : 0000000000000001 x3 : 0000000000000000<br /> x2 : 0000000000000006 x1 : 0000000000000080 x0 : ffff800125414000<br /> Call trace:<br /> __daif_local_irq_enable arch/arm64/include/asm/irqflags.h:27 [inline]<br /> arch_local_irq_enable arch/arm64/include/asm/irqflags.h:49 [inline]<br /> __local_bh_enable_ip+0x228/0x44c kernel/softirq.c:386<br /> __raw_spin_unlock_bh include/linux/spinlock_api_smp.h:167 [inline]<br /> _raw_spin_unlock_bh+0x3c/0x4c kernel/locking/spinlock.c:210<br /> spin_unlock_bh include/linux/spinlock.h:396 [inline]<br /> batadv_purge_orig_ref+0x114c/0x1228 net/batman-adv/originator.c:1287<br /> batadv_purge_orig+0x20/0x70 net/batman-adv/originator.c:1300<br /> process_one_work+0x694/0x1204 kernel/workqueue.c:2633<br /> process_scheduled_works kernel/workqueue.c:2706 [inline]<br /> worker_thread+0x938/0xef4 kernel/workqueue.c:2787<br /> kthread+0x288/0x310 kernel/kthread.c:388<br /> ret_from_fork+0x10/0x20 arch/arm64/kernel/entry.S:860<br /> Sending NMI from CPU 0 to CPUs 1:<br /> NMI backtrace for cpu 1<br /> CPU: 1 PID: 0 Comm: swapper/1 Not tainted 6.8.0-rc7-syzkaller-g707081b61156 #0<br /> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 02/29/2024<br /> pstate: 80400005 (Nzcv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)<br /> pc : arch_local_irq_enable+0x8/0xc arch/arm64/include/asm/irqflags.h:51<br /> lr : default_idle_call+0xf8/0x128 kernel/sched/idle.c:103<br /> sp : ffff800093a17d30<br /> x29: ffff800093a17d30 x28: dfff800000000000 x27: 1ffff00012742fb4<br /> x26: ffff80008ec9d000 x25: 0000000000000000 x24: 0000000000000002<br /> x23: 1ffff00011d93a74 x22: ffff80008ec9d3a0 x21: 0000000000000000<br /> x20: ffff0000c19dbc00 x19: ffff8000802d0fd8 x18: 1fffe00036804396<br /> x17: ffff80008ec9d000 x16: ffff8000802d089c x15: 0000000000000001<br /> ---truncated---