>
> > > The f_pos races are in fact exploitable, we've already been there. See
> > > for example
http://www.isec.pl/vulnerabilities/isec-0016-procleaks.txt
> > Well, this race is more subtle - the window is just one instruction
> > wide (stores to f_pos from CPU2 must come between the store of lower and
> > upper 32-bits of f_pos on CPU1). And the only result is that f_pos has
> > 32-bits from one file pointer and 32-bits from the other one. So I can
> > hardly imagine this would be exploitable...
>
> Supposing you are not holding any spinlock and are running with
> preemptible kernel (pretty common scenario nowadays), there is nothing
> that would prevent kernel from rescheduling between the two instructions,
> enlarging the race window to be more comfortable for attacker, right?