netdev - Re: [RFC, PATCH] net: sock_queue_err_skb() and sk_forward

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] [day] [month] [year] [list]

Date:	Fri, 25 Dec 2009 17:29:05 -0800 (PST)
From:	David Miller <davem@...emloft.net>
To:	eric.dumazet@...il.com
Cc:	shemminger@...tta.com, netdev@...r.kernel.org
Subject: Re: [RFC, PATCH] net: sock_queue_err_skb() and sk_forward_alloc
 corruption

From: Eric Dumazet <eric.dumazet@...il.com>
Date: Mon, 07 Dec 2009 23:32:16 +0100

> I wonder if we could use a special version of skb_set_owner_r()/sock_rfree()
> *without* sk_mem_charge()/sk_mem_uncharge() calls for this error queue.
> 
> (We dont call sk_rmem_schedule() anyway, so I guess current usage is not correct,
> even with sock locked ?)
> 
> Something like this (untested but compiled) patch ?
> 
> Signed-off-by: Eric Dumazet <eric.dumazet@...il.com>

I think this is legitimate in exactly this kind of case.

The paths where we do these non-charging add, we already just
made sure the receive queue is not over the limit.  Therefore
we won't have possible paths where we can queue error skbs
endlessly and without any controls.

So I'm ok with this approach to fix these bugs.
--
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