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:   Thu, 16 Mar 2017 21:28:11 -0700 (PDT)
From:   David Miller <>
Subject: Re: [PATCH net] rxrpc: Ignore BUSY packets on old calls

From: David Howells <>
Date: Thu, 16 Mar 2017 16:27:10 +0000

> If we receive a BUSY packet for a call we think we've just completed, the
> packet is handed off to the connection processor to deal with - but the
> connection processor doesn't expect a BUSY packet and so flags a protocol
> error.
> Fix this by simply ignoring the BUSY packet for the moment.
> The symptom of this may appear as a system call failing with EPROTO.  This
> may be triggered by pressing ctrl-C under some circumstances.
> This comes about we abort calls due to interruption by a signal (which we
> shouldn't do, but that's going to be a large fix and mostly in fs/afs/).
> What happens is that we abort the call and may also abort follow up calls
> too (this needs offloading somehoe).  So we see a transmission of something
> like the following sequence of packets:
> 	DATA for call N
> 	ABORT call N
> 	DATA for call N+1
> 	ABORT call N+1
> in very quick succession on the same channel.  However, the peer may have
> deferred the processing of the ABORT from the call N to a background thread
> and thus sees the DATA message from the call N+1 coming in before it has
> cleared the channel.  Thus it sends a BUSY packet[*].
> [*] Note that some implementations (OpenAFS, for example) mark the BUSY
>     packet with one plus the callNumber of the call prior to call N.
>     Ordinarily, this would be call N, but there's no requirement for the
>     calls on a channel to be numbered strictly sequentially (the number is
>     required to increase).
>     This is wrong and means that the callNumber in the BUSY packet should
>     be ignored (it really ought to be N+1 since that's what it's in
>     response to).
> Signed-off-by: David Howells <>

Applied, thanks David.

Powered by blists - more mailing lists