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  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:   Thu, 06 Feb 2020 14:13:00 +0100 (CET)
From:   David Miller <>
Subject: Re: [PATCH net] ipv6/addrconf: fix potential NULL deref in

From: Eric Dumazet <>
Date: Wed,  5 Feb 2020 08:55:44 -0800

> __in6_dev_get(dev) called from inet6_set_link_af() can return NULL.
> The needed check has been recently removed, let's add it back.

I am having trouble understanding this one.

When we have a do_setlink operation the flow is that we first validate
the AFs and then invoke setlink operations after that validation.

do_setlink() {
	err = validate_linkmsg(dev, tb);
	if (err < 0)
		return err;
	if (tb[IFLA_AF_SPEC]) {
			err = af_ops->set_link_af(dev, af);
			if (err < 0) {
				goto errout;

By definition, we only get to ->set_link_af() if there is an
IFLA_AF_SPEC nested attribute and if we look at the validation
performed by validate_linkmsg() it goes:

	if (tb[IFLA_AF_SPEC]) {
			if (af_ops->validate_link_af) {
				err = af_ops->validate_link_af(dev, af);

And validate_link_af in net/ipv6/addrconf.c clearly does the

static int inet6_validate_link_af(const struct net_device *dev,
				  const struct nlattr *nla)
	if (dev) {
		idev = __in6_dev_get(dev);
		if (!idev)
			return -EAFNOSUPPORT;

It checks the idev and makes sure it is not-NULL.

I therefore cannot find a path by which we arrive at inet6_set_link_af
with a NULL idev.  The above validation code should trap it.

Please explain.

Thank you.

Powered by blists - more mailing lists