netdev - Re: [Bugme-new] [Bug 8107] New: dev->header_cache

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]

Message-Id: <20070302.112325.39160082.davem@davemloft.net>
Date:	Fri, 02 Mar 2007 11:23:25 -0800 (PST)
From:	David Miller <davem@...emloft.net>
To:	khc@...waw.pl
Cc:	akpm@...ux-foundation.org, netdev@...r.kernel.org,
	bugme-daemon@...zilla.kernel.org, loveminix@...oo.com.cn
Subject: Re: [Bugme-new] [Bug 8107] New: dev->header_cache_update has a
 random value

From: Krzysztof Halasa <khc@...waw.pl>
Date: Fri, 02 Mar 2007 16:29:06 +0100

> Andrew Morton <akpm@...ux-foundation.org> writes:
> 
> >> However, in 
> >> drivers/net/wan/hdlc_cisco.c, in function static int cisco_ioctl(struct 
> >> net_device *dev, struct ifreq *ifr), where dev->hard_header is assigned a valid 
> >> function, and dev->hard_header_cache is assigned a known value (NULL), dev-
> >> >header_cache_update is not set to a known value:
> 
> Right, it seems I was never aware of dev->header_cache_update existence.
> I wonder where does the non-NULL value come from? Nevermind.
> 
> > diff -puN drivers/net/wan/hdlc_cisco.c~cisco_ioctl-initialise-header_cache_update drivers/net/wan/hdlc_cisco.c
> > --- a/drivers/net/wan/hdlc_cisco.c~cisco_ioctl-initialise-header_cache_update
> > +++ a/drivers/net/wan/hdlc_cisco.c
> > @@ -366,6 +366,7 @@ static int cisco_ioctl(struct net_device
> >  		dev->hard_start_xmit = hdlc->xmit;
> >  		dev->hard_header = cisco_hard_header;
> >  		dev->hard_header_cache = NULL;
> > +		dev->header_cache_update = NULL;
> >  		dev->type = ARPHRD_CISCO;
> >  		dev->flags = IFF_POINTOPOINT | IFF_NOARP;
> >  		dev->addr_len = 0;
> > _
> 
> ACK, I think it's the best place.

I disagree, you can't leave dangling references to functions
which are potentially inside of unloaded modules, as this code
does.

Rather, HDLC Cisco should implement a proper protocol destructor
method to clean up these function pointers.

-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html