From patchwork Wed Aug 10 23:43:36 2011 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: John Stultz X-Patchwork-Id: 3389 Return-Path: X-Original-To: patchwork@peony.canonical.com Delivered-To: patchwork@peony.canonical.com Received: from fiordland.canonical.com (fiordland.canonical.com [91.189.94.145]) by peony.canonical.com (Postfix) with ESMTP id E86052406F for ; Wed, 10 Aug 2011 23:44:01 +0000 (UTC) Received: from mail-qw0-f52.google.com (mail-qw0-f52.google.com [209.85.216.52]) by fiordland.canonical.com (Postfix) with ESMTP id B7D31A1857E for ; Wed, 10 Aug 2011 23:44:01 +0000 (UTC) Received: by mail-qw0-f52.google.com with SMTP id 8so1216683qwb.11 for ; Wed, 10 Aug 2011 16:44:01 -0700 (PDT) Received: by 10.229.183.84 with SMTP id cf20mr6839433qcb.121.1313019839968; Wed, 10 Aug 2011 16:43:59 -0700 (PDT) X-Forwarded-To: linaro-patchwork@canonical.com X-Forwarded-For: patch@linaro.org linaro-patchwork@canonical.com Delivered-To: patches@linaro.org Received: by 10.229.190.71 with SMTP id dh7cs97166qcb; Wed, 10 Aug 2011 16:43:59 -0700 (PDT) Received: from mr.google.com ([10.101.160.22]) by 10.101.160.22 with SMTP id m22mr10010099ano.52.1313019839772 (num_hops = 1); Wed, 10 Aug 2011 16:43:59 -0700 (PDT) Received: by 10.101.160.22 with SMTP id m22mr7011938ano.52.1313019839575; Wed, 10 Aug 2011 16:43:59 -0700 (PDT) Received: from e2.ny.us.ibm.com (e2.ny.us.ibm.com [32.97.182.142]) by mx.google.com with ESMTPS id u12si3024121wfl.102.2011.08.10.16.43.54 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 10 Aug 2011 16:43:55 -0700 (PDT) Received-SPF: pass (google.com: domain of jstultz@us.ibm.com designates 32.97.182.142 as permitted sender) client-ip=32.97.182.142; Authentication-Results: mx.google.com; spf=pass (google.com: domain of jstultz@us.ibm.com designates 32.97.182.142 as permitted sender) smtp.mail=jstultz@us.ibm.com Received: from d01relay03.pok.ibm.com (d01relay03.pok.ibm.com [9.56.227.235]) by e2.ny.us.ibm.com (8.14.4/8.13.1) with ESMTP id p7ANMHIh027304; Wed, 10 Aug 2011 19:22:17 -0400 Received: from d01av03.pok.ibm.com (d01av03.pok.ibm.com [9.56.224.217]) by d01relay03.pok.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id p7ANhqZv260076; Wed, 10 Aug 2011 19:43:52 -0400 Received: from d01av03.pok.ibm.com (loopback [127.0.0.1]) by d01av03.pok.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id p7AJhdBC025617; Wed, 10 Aug 2011 16:43:39 -0300 Received: from kernel.beaverton.ibm.com ([9.47.67.96]) by d01av03.pok.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with ESMTP id p7AJhcjl025593; Wed, 10 Aug 2011 16:43:38 -0300 Received: by kernel.beaverton.ibm.com (Postfix, from userid 1056) id 209981E7510; Wed, 10 Aug 2011 16:43:50 -0700 (PDT) From: John Stultz To: LKML Cc: John Stultz , Thomas Gleixner , stable@kernel.org Subject: [PATCH 3/3] alarmtimers: Avoid possible denial of service with high freq periodic timers Date: Wed, 10 Aug 2011 16:43:36 -0700 Message-Id: <1313019816-32519-4-git-send-email-john.stultz@linaro.org> X-Mailer: git-send-email 1.7.3.2.146.gca209 In-Reply-To: <1313019816-32519-1-git-send-email-john.stultz@linaro.org> References: <1313019816-32519-1-git-send-email-john.stultz@linaro.org> Its possible to jam up the alarm timers by setting very small interval timers, which will cause the alarmtimer subsystem to spend all of its time firing and restarting timers. This can effectivly lock up a box. A deeper fix is needed, closely mimicking the hrtimer code, but for now just cap the interval to 100us to avoid userland hanging the system. CC: Thomas Gleixner CC: stable@kernel.org Signed-off-by: John Stultz --- kernel/time/alarmtimer.c | 9 +++++++++ 1 files changed, 9 insertions(+), 0 deletions(-) diff --git a/kernel/time/alarmtimer.c b/kernel/time/alarmtimer.c index 0e9263f..ea5e1a9 100644 --- a/kernel/time/alarmtimer.c +++ b/kernel/time/alarmtimer.c @@ -481,6 +481,15 @@ static int alarm_timer_set(struct k_itimer *timr, int flags, if (!rtcdev) return -ENOTSUPP; + /* + * XXX HACK! Currently we can DOS a system if the interval + * period on alarmtimers is too small. Cap the interval here + * to 100us and solve this properly in a future patch! -jstultz + */ + if ((new_setting->it_interval.tv_sec == 0) && + (new_setting->it_interval.tv_nsec < 100000)) + new_setting->it_interval.tv_nsec = 100000; + if (old_setting) alarm_timer_get(timr, old_setting);