[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-Id: <20090723142603.4ba09c5a.akpm@linux-foundation.org>
Date: Thu, 23 Jul 2009 14:26:03 -0700
From: Andrew Morton <akpm@...ux-foundation.org>
To: Michael Buesch <mb@...sch.de>
Cc: linux-kernel@...r.kernel.org
Subject: Re: [PATCH] DAC960: Fix undefined behavior on empty string
On Sun, 19 Jul 2009 15:05:47 +0200
Michael Buesch <mb@...sch.de> wrote:
> This patch fixes undefined behavior due to buffer underrun,
> if an empty string is written to the proc file.
>
> Signed-off-by: Michael Buesch <mb@...sch.de>
> Cc: stable@...nel.org
>
> ---
>
> This patch is untested, because I do not have the hardware.
>
> ---
> drivers/block/DAC960.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> --- linux-2.6.orig/drivers/block/DAC960.c
> +++ linux-2.6/drivers/block/DAC960.c
> @@ -6555,21 +6555,21 @@ static int DAC960_ProcWriteUserCommand(s
> const char __user *Buffer,
> unsigned long Count, void *Data)
> {
> DAC960_Controller_T *Controller = (DAC960_Controller_T *) Data;
> unsigned char CommandBuffer[80];
> int Length;
> if (Count > sizeof(CommandBuffer)-1) return -EINVAL;
> if (copy_from_user(CommandBuffer, Buffer, Count)) return -EFAULT;
> CommandBuffer[Count] = '\0';
> Length = strlen(CommandBuffer);
> - if (CommandBuffer[Length-1] == '\n')
> + if (Length > 0 && CommandBuffer[Length-1] == '\n')
> CommandBuffer[--Length] = '\0';
> if (Controller->FirmwareType == DAC960_V1_Controller)
> return (DAC960_V1_ExecuteUserCommand(Controller, CommandBuffer)
> ? Count : -EBUSY);
> else
> return (DAC960_V2_ExecuteUserCommand(Controller, CommandBuffer)
> ? Count : -EBUSY);
> }
I suspect this is NotABug, as it requires that
DAC960_ProcWriteUserCommand() be called in response to a zero-length
write, and various bits of code will terminate early if they see such a
write go past. But we shouldn't rely on that here.
Surely we have a library function somewhere which will remove any
terminating whitespace from a C string? Sigh.
I note that you cc'ed stable@...nel.org on this patch. Why was that?
I assume that this pseudo-file is root-only, in which case the fix
isn't particularly urgent?
Thanks.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists