linux-kernel - Re: [PATCH v3 5/7] pppoatm: take ATM socket lock in pppoatm

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: <1352242658.7340.19.camel@shinybook.infradead.org>
Date:	Tue, 6 Nov 2012 22:57:39 +0000
From:	"Woodhouse, David" <david.woodhouse@...el.com>
To:	Krzysztof Mazur <krzysiek@...lesie.net>
CC:	"netdev@...r.kernel.org" <netdev@...r.kernel.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	Chas Williams - CONTRACTOR <chas@....nrl.navy.mil>,
	"davem@...emloft.net" <davem@...emloft.net>
Subject: Re: [PATCH v3 5/7] pppoatm: take ATM socket lock in pppoatm_send()

On Tue, 2012-11-06 at 23:17 +0100, Krzysztof Mazur wrote:
> +       if (sock_owned_by_user(sk_atm(vcc)))
> +               goto nospace;

I still think this one can lead to an infinite stall of the PPP channel,
because we return 0 from pppoatm_send() but never make a later call to
ppp_output_wakeup() to unblock it.

In the existing cases where we could return 0 (because
pppoatm_may_send() said no), we were careful to set the BLOCKED flag and
we *knew* that a packet was in flight so we'd get to wake it up again on
a subsequent pppoatm_pop().

None of that works for this new code path that returns zero.

-- 
                   Sent with MeeGo's ActiveSync support.

David Woodhouse                            Open Source Technology Centre
David.Woodhouse@...el.com                              Intel Corporation