Re: [PATCH] crypto: af_alg - Disallow multiple in-flight AIO requests

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



[CCing the stable team, as it looks like two prerequisite changes for a
patch already applied are missing in at least 4.19.y]

On 15.03.24 18:55, Ralph Siemsen wrote:
> 
> I have found a regression in userspace behaviour after this patch was
> merged into the 4.19.y kernel. The fix seems to involve backporting a
> few more changes. Could you review details below and confirm if this is
> the right approach?

FWIW, developers are totally free to not care about stable and longterm
kernels series. Not sure if Herbert is among those developers, but it
might explain why there is no reply yet. That's why I CCed the stable
maintainers, strictly speaking they are responsible.

> On Tue, Nov 28, 2023 at 04:25:49PM +0800, Herbert Xu wrote:
>> Having multiple in-flight AIO requests results in unpredictable
>> output because they all share the same IV.  Fix this by only allowing
>> one request at a time.
> [...]
> This change got backported on the 4.19 kernel in January:
> https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?h=linux-4.19.y&id=19af0310c8767c993f2a5d5261e4df3f9f465ce1
> 
> Since then, I am seeCiao, ing a regression in a simple openssl encoding test:
> 
> openssl enc -k mysecret -aes-256-cbc -in plain.txt -out cipher.txt
> -engine afalg
> 
> It fails intermittently with the message "error writing to file", but
> this error is a bit misleading, the actual problem is that the kernel
> returns -16 (EBUSY) on the encoding operation.
> 
> This happens only in 4.19, and not under 5.10. The patch seems correct,
> however it seems we are missing a couple of other patches on 4.19:
> 
> f3c802a1f3001 crypto: algif_aead - Only wake up when ctx->more is zero
> 21dfbcd1f5cbf crypto: algif_aead - fix uninitialized ctx->init
> 
> I was able to cherry-pick those into 4.19.y, with just a minor conflict
> in one case. With those applied, the openssl command no longer fails.

Some feedback here from Herbert would of course be splendid, but maybe
your tests are all the stable team needs to pick those up for a future
4.19.y release.

> I suspect similar changes would be needed also in 5.4 kernel, however I
> neither checked that, nor have I run any tests on that version.

Ciao, Thorsten (wearing his 'the Linux kernel's regression tracker' hat)
--
Everything you wanna know about Linux kernel regression tracking:
https://linux-regtracking.leemhuis.info/about/#tldr
If I did something stupid, please tell me, as explained on that page.




[Index of Archives]     [Kernel]     [Gnu Classpath]     [Gnu Crypto]     [DM Crypt]     [Netfilter]     [Bugtraq]
  Powered by Linux