netdev - Re: mac80211 truesize bugs

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: <20080503.180300.10562559.davem@davemloft.net>
Date:	Sat, 03 May 2008 18:03:00 -0700 (PDT)
From:	David Miller <davem@...emloft.net>
To:	johannes@...solutions.net
Cc:	herbert@...dor.apana.org.au, mb@...sch.de, netdev@...r.kernel.org,
	linux-wireless@...r.kernel.org
Subject: Re: mac80211 truesize bugs

From: Johannes Berg <johannes@...solutions.net>
Date: Sat, 03 May 2008 13:52:13 +0200

> 
> > We can't update skb->truesize during arbitray skb->data reallocations,
> > because it could corrupt the socket accounting.
> > 
> > On the other hand, if we provide ways for users to subvert the socket
> > buffer limits, we might as well not try to limit anything.
> 
> Why don't we update the socket allocation when doing pskb_expand_head()?
> Sure, it could become negative, but is that so bad?

The socket locked state at this time is variable and unknown.

The socket must be locked in order to modify these values.
And such locks cannot be taken, for example, from HW interrupt
context, amongst other restrictions.

> We need more space though. Should we then just increase the built-in
> headroom?

I simply don't know what to suggest at this point, that's why
we are having this discussion :-)
--
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