{"id":"CVE-2023-53067","summary":"LoongArch: Only call get_timer_irq() once in constant_clockevent_init()","details":"In the Linux kernel, the following vulnerability has been resolved:\n\nLoongArch: Only call get_timer_irq() once in constant_clockevent_init()\n\nUnder CONFIG_DEBUG_ATOMIC_SLEEP=y and CONFIG_DEBUG_PREEMPT=y, we can see\nthe following messages on LoongArch, this is because using might_sleep()\nin preemption disable context.\n\n[    0.001127] smp: Bringing up secondary CPUs ...\n[    0.001222] Booting CPU#1...\n[    0.001244] 64-bit Loongson Processor probed (LA464 Core)\n[    0.001247] CPU1 revision is: 0014c012 (Loongson-64bit)\n[    0.001250] FPU1 revision is: 00000000\n[    0.001252] BUG: sleeping function called from invalid context at kernel/locking/mutex.c:283\n[    0.001255] in_atomic(): 1, irqs_disabled(): 1, non_block: 0, pid: 0, name: swapper/1\n[    0.001257] preempt_count: 1, expected: 0\n[    0.001258] RCU nest depth: 0, expected: 0\n[    0.001259] Preemption disabled at:\n[    0.001261] [\u003c9000000000223800\u003e] arch_dup_task_struct+0x20/0x110\n[    0.001272] CPU: 1 PID: 0 Comm: swapper/1 Not tainted 6.2.0-rc7+ #43\n[    0.001275] Hardware name: Loongson Loongson-3A5000-7A1000-1w-A2101/Loongson-LS3A5000-7A1000-1w-A2101, BIOS vUDK2018-LoongArch-V4.0.05132-beta10 12/13/202\n[    0.001277] Stack : 0072617764726148 0000000000000000 9000000000222f1c 90000001001e0000\n[    0.001286]         90000001001e3be0 90000001001e3be8 0000000000000000 0000000000000000\n[    0.001292]         90000001001e3be8 0000000000000040 90000001001e3cb8 90000001001e3a50\n[    0.001297]         9000000001642000 90000001001e3be8 be694d10ce4139dd 9000000100174500\n[    0.001303]         0000000000000001 0000000000000001 00000000ffffe0a2 0000000000000020\n[    0.001309]         000000000000002f 9000000001354116 00000000056b0000 ffffffffffffffff\n[    0.001314]         0000000000000000 0000000000000000 90000000014f6e90 9000000001642000\n[    0.001320]         900000000022b69c 0000000000000001 0000000000000000 9000000001736a90\n[    0.001325]         9000000100038000 0000000000000000 9000000000222f34 0000000000000000\n[    0.001331]         00000000000000b0 0000000000000004 0000000000000000 0000000000070000\n[    0.001337]         ...\n[    0.001339] Call Trace:\n[    0.001342] [\u003c9000000000222f34\u003e] show_stack+0x5c/0x180\n[    0.001346] [\u003c90000000010bdd80\u003e] dump_stack_lvl+0x60/0x88\n[    0.001352] [\u003c9000000000266418\u003e] __might_resched+0x180/0x1cc\n[    0.001356] [\u003c90000000010c742c\u003e] mutex_lock+0x20/0x64\n[    0.001359] [\u003c90000000002a8ccc\u003e] irq_find_matching_fwspec+0x48/0x124\n[    0.001364] [\u003c90000000002259c4\u003e] constant_clockevent_init+0x68/0x204\n[    0.001368] [\u003c900000000022acf4\u003e] start_secondary+0x40/0xa8\n[    0.001371] [\u003c90000000010c0124\u003e] smpboot_entry+0x60/0x64\n\nHere are the complete call chains:\n\nsmpboot_entry()\n  start_secondary()\n    constant_clockevent_init()\n      get_timer_irq()\n        irq_find_matching_fwnode()\n          irq_find_matching_fwspec()\n            mutex_lock()\n              might_sleep()\n                __might_sleep()\n                  __might_resched()\n\nIn order to avoid the above issue, we should break the call chains,\nusing timer_irq_installed variable as check condition to only call\nget_timer_irq() once in constant_clockevent_init() is a simple and\nproper way.","modified":"2026-08-12T03:51:43.146523395Z","published":"2025-05-02T15:55:20.477Z","database_specific":{"cna_assigner":"Linux","osv_generated_from":"https://github.com/CVEProject/cvelistV5/tree/main/cves/2023/53xxx/CVE-2023-53067.json"},"references":[{"type":"WEB","url":"https://git.kernel.org/stable/c/acadbd058fa12b510fbecca11eae22bd6f654250"},{"type":"WEB","url":"https://git.kernel.org/stable/c/b9c379e1d7e141b102f41858c9b8f6f36e7c89a4"},{"type":"WEB","url":"https://git.kernel.org/stable/c/bb7a78e343468873bf00b2b181fcfd3c02d8cb56"},{"type":"ADVISORY","url":"https://github.com/CVEProject/cvelistV5/tree/main/cves/2023/53xxx/CVE-2023-53067.json"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2023-53067"},{"type":"PACKAGE","url":"https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git"}],"affected":[{"ranges":[{"type":"GIT","repo":"https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git","events":[{"introduced":"fa96b57c149061f71a70bd6582d995f6424fbbf4"},{"fixed":"b9c379e1d7e141b102f41858c9b8f6f36e7c89a4"},{"fixed":"acadbd058fa12b510fbecca11eae22bd6f654250"},{"fixed":"bb7a78e343468873bf00b2b181fcfd3c02d8cb56"}]}],"database_specific":{"source":"https://storage.googleapis.com/cve-osv-conversion/osv-output/CVE-2023-53067.json"}},{"package":{"name":"Kernel","ecosystem":"Linux"},"ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"5.19.0"},{"fixed":"6.1.21"}]},{"type":"ECOSYSTEM","events":[{"introduced":"6.2.0"},{"fixed":"6.2.8"}]}],"database_specific":{"source":"https://storage.googleapis.com/cve-osv-conversion/osv-output/CVE-2023-53067.json"}}],"schema_version":"1.9.0"}