linux-kernel - WARNING in do_timer

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [thread-next>] [day] [month] [year] [list]

Message-ID: <ZCFDGrz5mJXLLC49@dragonet>
Date:   Mon, 27 Mar 2023 16:17:46 +0900
From:   "Dae R. Jeong" <threeearcat@...il.com>
To:     tglx@...utronix.de, linux-kernel@...r.kernel.org
Subject: WARNING in do_timer_settime

Hi,

I'm looking an issue detected during fuzzing "WARNING in
do_timer_settime". Its report is attached at the end of this email.

I think this does not cause any serious issue, but my rough sketch of
a scenario causing the warning is a race condition caused by two
timer_settime() system calls for CLOCK_PROCESS_CPUTIME_ID.

CPU1                                       CPU2
-----                                      -----
do_timer_settime(CLOCK_PROCESS_CPUTIME_ID)
  posix_cpu_timer_set()
    arm_timer(timer, p);

timer interrupt handler
  run_posix_cpu_timers()
    handle_posix_cpu_timers()
      lock_task_sighand()
      check_process_timers()
        collect_posix_cpu_timers()         do_timer_settime(CLOCK_PROCESS_CPUTIME_ID)
          ctmr->firing = 1; - (1)            posix_cpu_timer_set()
      unlock_task_sighand() - (2)
                                               lock_task_sighand() // can acquire the sighand
                                                                   // lock because of (2)
                                               if (timer->it.cpu.firing)) // true because of (1) and (3)
                                                 ret = TIMER_RETRY;
                                                 ..
                                                 return tret;
                                             timer_wait_running()
                                               WARN_ON(!kc->timer_was_running);
                                               // kc->timer_was_running is NULL in clock_posix_cpu
     timer->it.cpu.firing = 0; - (3)

But regardless of the scenario, I wonder if the commit ec8f954a40d
("posix-timers: Use a callback for cancel synchronization on
PREEMPT_RT") missed initializations to the timer_was_running field in
clock_posix_cpu. I can see that the commit initialized the
timer_was_running field of all other clocks but clock_posix_cpu.  So I
think the warning does not occur if the timer_was_running field of
clock_posix_cpu is initialized to, for example,
common_timer_wait_running. Could you please check this?

Thank you in advance.

Best regards,
Dae R. Jeong

-----
- Kernel version:
  6.2.0-rc7

- Report:
WARNING: CPU: 1 PID: 13389 at kernel/time/posix-timers.c:849 do_timer_settime+0x193/0x200 kernel/time/posix-timers.c:929
Modules linked in:
CPU: 1 PID: 13389 Comm: syz-executor.0 Not tainted 6.2.0-rc7-32171-g7f09e8f6ebfb #5
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.14.0-0-g155821a1990b-prebuilt.qemu.org 04/01/2014
<- omitting registers ->
Call Trace:
 <TASK>
 __do_sys_timer_settime kernel/time/posix-timers.c:952 [inline]
 __se_sys_timer_settime kernel/time/posix-timers.c:938 [inline]
 __x64_sys_timer_settime+0xa3/0x110 kernel/time/posix-timers.c:938
 do_syscall_x64 arch/x86/entry/common.c:51 [inline]
 do_syscall_64+0x4e/0xa0 arch/x86/entry/common.c:82
 entry_SYSCALL_64_after_hwframe+0x63/0xcd
RIP: 0033:0x478d29
<- omitting registers ->
 </TASK>
---[ end trace 0000000000000000 ]---