summaryrefslogtreecommitdiffstats
path: root/fs/fhandle.c
diff options
context:
space:
mode:
authorThomas Gleixner <tglx@linutronix.de>2015-12-31 16:30:51 +0000
committerThomas Gleixner <tglx@linutronix.de>2016-01-15 13:44:01 +0100
commitc1684f5035b60e9f98566493e869496fb5de1d89 (patch)
treecf57565f3857050c8827837d6ab2c04683d417e2 /fs/fhandle.c
parent847667ef10356b824a11c853fc8a8b1b437b6a8d (diff)
downloadlinux-c1684f5035b60e9f98566493e869496fb5de1d89.tar.bz2
x86/irq: Clear move_in_progress before sending cleanup IPI
send_cleanup_vector() fiddles with the old_domain mask unprotected because it relies on the protection by the move_in_progress flag. But this is fatal, as the flag is reset after the IPI has been sent. So a cpu which receives the IPI can still see the flag set and therefor ignores the cleanup request. If no other cleanup request happens then the vector stays stale on that cpu and in case of an irq removal the vector still persists. That can lead to use after free when the next cleanup IPI happens. Protect the code with vector_lock and clear move_in_progress before sending the IPI. This does not plug the race which Joe reported because: CPU0 CPU1 CPU2 lock_vector() data->move_in_progress=0 sendIPI() unlock_vector() set_affinity() assign_irq_vector() lock_vector() handle_IPI move_in_progress = 1 lock_vector() unlock_vector() move_in_progress == 1 The full fix comes with a later patch. Reported-and-tested-by: Joe Lawrence <joe.lawrence@stratus.com> Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Tested-by: Borislav Petkov <bp@alien8.de> Cc: Jiang Liu <jiang.liu@linux.intel.com> Cc: Jeremiah Mahler <jmmahler@gmail.com> Cc: andy.shevchenko@gmail.com Cc: Guenter Roeck <linux@roeck-us.net> Cc: stable@vger.kernel.org #4.3+ Link: http://lkml.kernel.org/r/20151231160106.892412198@linutronix.de Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Diffstat (limited to 'fs/fhandle.c')
0 files changed, 0 insertions, 0 deletions