linux-kernel - running hrtimer_start on an already active hrtimer?

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]

Date:	Tue, 5 May 2015 15:30:54 +0200
From:	Jiri Bohac <jbohac@...e.cz>
To:	linux-kernel@...r.kernel.org
Cc:	tglx@...utronix.de, mhocko@...e.cz
Subject: running hrtimer_start on an already active hrtimer?

Hi,


I came across a strange bug (in a very old kernel) that triggers
the
	BUG_ON(timer->state != HRTIMER_STATE_CALLBACK);
in __run_hrtimer().

The code runs hrtimer_start() on an already started hrtimer. 
Looking at the description of hrtimer_start() it looks
like something that is allowed:
	/**
	 * hrtimer_start - (re)start an hrtimer on the current CPU
	...
	 * Returns:
	 *  0 on success
	 *  1 when the timer was active

Is this really supposed to work?

I think it's not immune to this race condition:

CPU0						CPU1
__run_hrtimer()
   __remove_hrtimer(...HRTIMER_STATE_CALLBACK)
      //clears HRTIMER_STATE_ENQUEUED
   ...
   raw_spin_unlock(&cpu_base->lock);
   restart = fn(timer);
						hrtimer_start()
						   __hrtimer_start_range_ns()
						      //remove_hrtimer() does nothing because
						      //  HRTIMER_STATE_ENQUEUED is not set
						      enqueue_hrtimer()
   raw_spin_lock(&cpu_base->lock);
   ...
   BUG_ON(timer->state != HRTIMER_STATE_CALLBACK);
   // state has HRTIMER_STATE_ENQUEUED set
   


Should __hrtimer_start_range_ns() do something like
hrtimer_cancel - i.e. explicitly check for ...
HRTIMER_STATE_CALLBACK?


Thanks,

-- 
Jiri Bohac <jbohac@...e.cz>
SUSE Labs, SUSE CZ

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/