[SRU][CVE-2019-14283][X/B/D][PATCH 1/1] floppy: fix out-of-bounds read in copy_buffer
khalid.elmously at canonical.com
Wed Aug 7 03:36:32 UTC 2019
On 2019-08-01 10:45:17 , Connor Kuehl wrote:
> From: Denis Efremov <efremov at ispras.ru>
> This fixes a global out-of-bounds read access in the copy_buffer
> function of the floppy driver.
> The FDDEFPRM ioctl allows one to set the geometry of a disk. The sect
> and head fields (unsigned int) of the floppy_drive structure are used to
> compute the max_sector (int) in the make_raw_rw_request function. It is
> possible to overflow the max_sector. Next, max_sector is passed to the
> copy_buffer function and used in one of the memcpy calls.
> An unprivileged user could trigger the bug if the device is accessible,
> but requires a floppy disk to be inserted.
> The patch adds the check for the .sect * .head multiplication for not
> overflowing in the set_geometry function.
> The bug was found by syzkaller.
> Signed-off-by: Denis Efremov <efremov at ispras.ru>
> Tested-by: Willy Tarreau <w at 1wt.eu>
> Signed-off-by: Linus Torvalds <torvalds at linux-foundation.org>
> (cherry picked from commit da99466ac243f15fbba65bd261bfc75ffa1532b6)
> Signed-off-by: Connor Kuehl <connor.kuehl at canonical.com>
> drivers/block/floppy.c | 6 ++++--
> 1 file changed, 4 insertions(+), 2 deletions(-)
> diff --git a/drivers/block/floppy.c b/drivers/block/floppy.c
> index 42ae1d2d8243..7516fed84ae9 100644
> --- a/drivers/block/floppy.c
> +++ b/drivers/block/floppy.c
> @@ -3236,8 +3236,10 @@ static int set_geometry(unsigned int cmd, struct floppy_struct *g,
> int cnt;
> /* sanity checking for parameters. */
> - if (g->sect <= 0 ||
> - g->head <= 0 ||
> + if ((int)g->sect <= 0 ||
> + (int)g->head <= 0 ||
> + /* check for overflow in max_sector */
> + (int)(g->sect * g->head) <= 0 ||
> /* check for zero in F_SECT_PER_TRACK */
> (unsigned char)((g->sect << 2) >> FD_SIZECODE(g)) == 0 ||
> g->track <= 0 || g->track > UDP->tracks >> STRETCH(g) ||
Hmm...This patch doesn't seem to apply to any of X or B or D.
Looks like this patch is the upstream patch exactly but it appears the upstream patch actually needs some (minor?) backport work.
Connor, could you please double check?
More information about the kernel-team