Re: [PATCH] DAC960: Fix undefined behavior on empty string
From: Andrew Morton
Date: Thu Jul 23 2009 - 17:26:49 EST
On Sun, 19 Jul 2009 15:05:47 +0200
Michael Buesch <mb@xxxxxxxxx> 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@xxxxxxxxx>
> Cc: stable@xxxxxxxxxx
>
> ---
>
> 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@xxxxxxxxxx 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@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/