Re: popo/popo2 linux kernel vulns

[RaziREKT via Fulldisclosure <fulldisclosure () seclists org>]

Hello KJ Jung,

neither of the mails you sent contain bugs.
The kernel code is sound and the vulnerabilities you reported don't seem 
to exist.

In your first mail (popo:: linux kernel vulns of it),
you point out a flaw in bond_do_ioctl() and bond_set_dev_addr().

>              // [4]:: x90: Trigger point: slave_dev->dev_addr,
> slave_dev->addr_len two variables controlled by user in memcpy
>                       API.
>   622        memcpy(bond_dev->dev_addr, slave_dev->dev_addr,
> slave_dev->addr_len);

It is impossible to set slave_dev->dev_addr to arbitrary values userspace.
The value will be chosen from a handful of fixed hardware address lengths.
None will exceed the length of the buffer that bond_dev->dev_addr points to,
which is always 32 (include/linux/netdevice.h MAX_ADDR_LEN).

In your second email, you report a vulnerability in tun_chr_ioctl()

> __tun_chr_ioctl function of ~/drivers/net/tun.c has a stack buffer
> overflow vulnerability. it get's arg, ifreq_len, and copy the arg(argp)
> to ifr(ifreq struct) and this steps are no bounds-checking.
> ...
> --
> 3352static long tun_chr_ioctl(struct file *file,
> 3353                          unsigned int cmd, unsigned long arg)
> 3354{
> 3355        return __tun_chr_ioctl(file, cmd, arg, sizeof (struct ifreq));
> 3356}
As you can clearly see, ifreq_len is set to the actual size of struct 
ifreq here.
>                      // x90:: vulnerable point::
> 3044                if (copy_from_user(&ifr, argp, ifreq_len)) // bug.
Which means that this piece of code is not exploitable.
There is no way to set ifreq_len from userspace.

Please refrain from sending invalid bug reports.

Regards,
RaziREKT


_______________________________________________
Sent through the Full Disclosure mailing list
https://nmap.org/mailman/listinfo/fulldisclosure
Web Archives & RSS: http://seclists.org/fulldisclosure/