Protect the might cancel mechanism proper in kernel-timerfd CVE-2017-10661 [released]

Tracked by Jolla (In release)

asked 2017-08-10 11:18:05 +0200

this post is marked as community wiki

This post is a wiki. Anyone with karma >75 is welcome to improve it.

updated 2017-08-10 11:18:05 +0200

lpr gravatar image

Description
The handling of the might_cancel queueing is not properly protected, so parallel operations on the file descriptor can race with each other and lead to list corruptions or use after free. Protect the context for these operations with a seperate lock. The wait queue lock cannot be reused for this because that would create a lock inversion scenario vs. the cancel lock. Replacing might_cancel with an atomic (atomic_t or atomic bit) does not help either because it still can race vs. the actual list operation.

Elevation of Privilege vulnerability CVSS rating: High local

Upstream Patch is available.

File affected: kernel-adaptation-sbj-3.4.108.20161101.1/fs/timerfd.c lines 35-39; 86-92; 96-101; 106-108 (differs in '|| ctx->clockid == CLOCK_REALTIME_ALARM' line 109-110); 114-120; 268-271

edit retag flag offensive reopen delete

The question has been closed for the following reason "released in a software update" by lpr
close date 2018-11-01 12:26:41.688628

Comments

released in SFOS 3.0.0.5 with kernel update to kernel-adaptation-sbj-3.4.108.20181002.1

lpr ( 2018-11-01 12:26:25 +0200 )edit