linux-kernel - Re: [PATCH] Btrfs: avoid buffer overrun in mount option handling

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]

Date:	Wed, 25 Apr 2012 16:03:32 -0400
From:	Josef Bacik <josef@...hat.com>
To:	Jim Meyering <jim@...ering.net>
Cc:	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	Josef Bacik <josef@...hat.com>
Subject: Re: [PATCH] Btrfs: avoid buffer overrun in mount option handling

On Wed, Apr 25, 2012 at 09:51:53PM +0200, Jim Meyering wrote:
> 
> There is an off-by-one error: allocating room for a maximal result
> string but without room for a trailing NUL.  That, can lead to
> returning a transformed string that is not NUL-terminated, and then
> to a caller reading beyond end of the malloc'd buffer.
> 
> Worse still, we could write one non-NUL byte beyond the end of that
> malloc'd result buffer when given a mount option of "subvol=," (i.e.,
> no arg after the "=") because here the replacement "subvolid=0" is 3
> bytes longer, not just 2.

So this can't happen, since it would be caught by btrfs_parse_early_options
which expects subvolid=%d, and if it doesn't get that it would just error out,
so while adding another byte isn't bad, it's not correct either, so fix that and
I'd say it's good to go.  Thanks,

Josef
--
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/