Temporarily skip `test_aead_aes_gcm` for buildbots with Linux kernel between 6.16.0 and 6.17.x

[hroncok]

Bug report

Bug description:

We have recently started to see the following test failure on Fedora CI with Python 3.14.0rc3 and 3.13.7 (possibly others as well, not tested yet):

======================================================================
ERROR: test_aead_aes_gcm (test.test_socket.LinuxKernelCryptoAPI.test_aead_aes_gcm)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/usr/lib64/python3.14/test/test_socket.py", line 7071, in test_aead_aes_gcm
    op.sendall(plain)
    ~~~~~~~~~~^^^^^^^
OSError: [Errno 22] Invalid argument

platform.architecture: 64bit ELF
platform.freedesktop_os_release[ID]: fedora
platform.freedesktop_os_release[NAME]: Fedora Linux
platform.freedesktop_os_release[VARIANT_ID]: cloud
platform.freedesktop_os_release[VERSION]: 44 (Cloud Edition Prerelease)
platform.freedesktop_os_release[VERSION_ID]: 44
platform.libc_ver: glibc 2.42.9000
platform.platform: Linux-6.17.0-0.rc7.56.fc44.x86_64-x86_64-with-glibc2.42.9000
platform.python_implementation: CPython

This is similar to #73510 and seems to have regressed again. Not sure if this is a kernel bug or CPython bug yet.

CPython versions tested on:

3.14, 3.13

Operating systems tested on:

Linux

Linked PRs

• gh-139310: skip test_aead_aes_gcm for Linux kernel between 6.16.0 and 6.17.x #139552
• [3.13] gh-139310: skip test_aead_aes_gcm for Linux kernel between 6.16.0 and 6.17.x (GH-139552) #139593
• [3.14] gh-139310: skip test_aead_aes_gcm for Linux kernel between 6.16.0 and 6.17.x (GH-139552) #139594

[Zheaoli]

confirm it on 3.15, seems kernel change some api. Working on it

[Zheaoli]

Confirm the root cause. I think it's related with this commit in the kernel torvalds/linux@1b34cbb

I'm not sure if this a bug. I'm sending a report to kernel mail group

[Zheaoli]

FYI https://bugzilla.kernel.org/show_bug.cgi?id=220603

[picnixz]

The previous regression was caused by how the data was actually sent. In addition, EINVAL (22) is returned by the kernel if the data is not correct (see https://docs.kernel.org/crypto/userspace-if.html#aead-cipher-api).

The problem was fixed in torvalds/linux@d0ca0df because we use op.sendall(assoc, socket.MSG_MORE) just before, but socket.MSG_MORE is an even number. Because of this, af_alg_ctx.more which was previously marked as a uint32_t of 1 bit will be 0 instead because of mod 2 conversion. So the latest 6.17 kernel should not have this bug anymore.

[Zheaoli]

@picnixz Yes, I think this is fixed in main branch of the kernel. I think the 6.17 will not be a issue anymore

[Zheaoli]

This bug has been fixed in 6.17 release. I think this issue could be closed as resloved

[hroncok]

Thanks.