[SRU][F/J/N/O][PATCH 0/2] CVE-2024-50047, CVE-2024-53185 and CVE-2025-37750

[Massimiliano Pellizzer]

https://ubuntu.com/security/CVE-2024-50047
https://ubuntu.com/security/CVE-2024-53185
https://ubuntu.com/security/CVE-2025-37750

[ Impact ]

CVE-2024-50047

smb: client: fix UAF in async decryption

Doing an async decryption (large read) crashes with a
slab-use-after-free way down in the crypto API.

This is because TFM is being used in parallel.

Fix this by allocating a new AEAD TFM for async decryption, but keep
the existing one for synchronous READ cases (similar to what is done
in smb3_calc_signature()).

Also remove the calls to aead_request_set_callback() and
crypto_wait_req() since it's always going to be a synchronous operation.

CVE-2024-53185

smb: client: fix NULL ptr deref in crypto_aead_setkey()

Neither SMB3.0 or SMB3.02 supports encryption negotiate context, so
when SMB2_GLOBAL_CAP_ENCRYPTION flag is set in the negotiate response,
the client uses AES-128-CCM as the default cipher.  See MS-SMB2
3.3.5.4.

Commit b0abcd65ec54 ("smb: client: fix UAF in async decryption") added
a @server->cipher_type check to conditionally call
smb3_crypto_aead_allocate(), but that check would always be false as
@server->cipher_type is unset for SMB3.02.

Fix this by setting @server->cipher_type for SMB3.02 as well.

CVE-2025-37750

smb: client: fix UAF in decryption with multichannel

After commit f7025d861694 ("smb: client: allocate crypto only for
primary server") and commit b0abcd65ec54 ("smb: client: fix UAF in
async decryption"), the channels started reusing AEAD TFM from primary
channel to perform synchronous decryption, but that can't done as
there could be multiple cifsd threads (one per channel) simultaneously
accessing it to perform decryption.

[ Fix ]

Oracular and Noble:
  Affected only by CVE-2025-37750,
  backported the fix from mainline.
Jammy and Focal:
  Backported the fix for CVE-2024-50047
  Cherry picked the fix for CVE-2024-53185
  Backported the fix for CVE-2025-37750

[ Test Plan ]

Noble and Oracular compile tested only.

Jammy and Focal compile and boot tested.
Moreover on Jammy and Focal I run the reprouducer
and stress-ng using Jammy as a cifs server and
Focal as a cifs client and vice versa.

# Server

$ sudo apt install -y samba

$ sudo mkdir -p /srv/smbshare
$ sudo chmod 0777 /srv/smbshare

$ sudo adduser --disabled-password testuser
$ sudo smbpasswd -a testuser

$ dd if=/dev/urandom of=/srv/smbshare/largefile bs=1M count=1024

Modified /etc/samba/smb.conf ensuring to have at lest the following:

[global]
   server role = standalone server
   smb encrypt = required
   min protocol = SMB3
   max protocol = SMB3_11

[sambashare]
    path = /srv/smbshare
    read only = no
    browsable = yes
    guest ok = no
    valid users = testuser

$ sudo systemctl restart smbd

# Client

$ sudo apt install -y cifs-utils

$ sudo mkdir -p /mnt/smbshare
$ sudo chmod 0777 /mnt/smbshare

$ sudo mount.cifs //10.10.10.25/sambashare /mnt/smbshare \
    -o username=testuser,password=test,seal,vers=3.1.1,esize=1
  
$ dd if=/mnt/smbshare/largefile of=/dev/null bs=1M
1024+0 records in
1024+0 records out
1073741824 bytes (1.1 GB, 1.0 GiB) copied, 2.51368 s, 427 MB/s

$ cd /mnt/smbshare/
$ sudo stress-ng --hdd 8 --hdd-bytes 2G --timeout 5m --verify --metrics-brief
stress-ng: info:  [1379] setting to a 300 second (5 mins, 0.00 secs) run per stressor
stress-ng: info:  [1379] dispatching hogs: 8 hdd
stress-ng: info:  [1379] successful run completed in 300.18s (5 mins, 0.18 secs)
stress-ng: info:  [1379] stressor       bogo ops real time  usr time  sys time   bogo ops/s     bogo ops/s
stress-ng: info:  [1379]                           (secs)    (secs)    (secs)   (real time) (usr+sys time)
stress-ng: info:  [1379] hdd              352025    300.15     17.46   1237.18      1172.82         280.58

All tests has been run  with KASAN enabled.

[ Where Problems Could Occur ]

The fix affects the SMB3 decryption logic in the CIFS client,
specifically within the function used to process encrypted responses.
An issue with this fix may lead to incorrect handling of per-thread
cryptographic transform contexts (crypto_aead),
particularly when offloaded decryption paths allocate
and manage these contexts dynamically.
A user might experience problems such as failed or corrupted file reads
from encrypted SMB shares.