linux-kernel - Re: [PATCH] rtc-cmos: Reject unsupported alarm values

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-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <51495377-fcf7-df2c-bac4-ef32334158a3@gmail.com>
Date:   Thu, 1 Sep 2016 01:41:18 +0200
From:   Gabriele Mazzotta <gabriele.mzt@...il.com>
To:     a.zummo@...ertech.it, alexandre.belloni@...e-electrons.com
Cc:     rtc-linux@...glegroups.com, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] rtc-cmos: Reject unsupported alarm values

On 01/09/2016 00:59, Gabriele Mazzotta wrote:
> Return an error if the user tries to set an alarm that isn't
> supported by the hardware.
> 
> Signed-off-by: Gabriele Mazzotta <gabriele.mzt@...il.com>
> ---
>  drivers/rtc/rtc-cmos.c | 20 ++++++++++++++++++++
>  1 file changed, 20 insertions(+)
> 
> diff --git a/drivers/rtc/rtc-cmos.c b/drivers/rtc/rtc-cmos.c
> index 4cdb335..b3f9298 100644
> --- a/drivers/rtc/rtc-cmos.c
> +++ b/drivers/rtc/rtc-cmos.c
> @@ -336,6 +336,26 @@ static int cmos_set_alarm(struct device *dev, struct rtc_wkalrm *t)
>  	if (!is_valid_irq(cmos->irq))
>  		return -EIO;
>  
> +	if (!cmos->mon_alrm || !cmos->day_alrm) {
> +		struct rtc_time now;
> +		time64_t t_now;
> +		time64_t t_alrm;
> +
> +		cmos_read_time(dev, &now);
> +		t_now = rtc_tm_to_time64(&now);
> +		t_alrm = rtc_tm_to_time64(&t->time);
> +		if (!cmos->day_alrm && (t_alrm - t_now) > (24 * 60 * 60)) {
> +			dev_err(dev,
> +				"Alarms can be up to one day in the future\n");
> +			return -EINVAL;
> +		}
> +		if (!cmos->mon_alrm && (t_alrm - t_now) > (31 * 24 * 60 * 60)) {

I actually realized this is wrong. It's possible for this to let some
invalid dates go through. The driver writes a date in the registers,
so if mon_alrm is missing, I need to do something better than
adding 31 days. Sorry, I was thinking about time deltas rather
than well defined dates.

> +			dev_err(dev,
> +				"Alarms can be up to 31 days in the future\n");
> +			return -EINVAL;
> +		}
> +	}
> +
>  	mon = t->time.tm_mon + 1;
>  	mday = t->time.tm_mday;
>  	hrs = t->time.tm_hour;
>