UBUNTU-CVE-2025-71072
In the Linux kernel, the following vulnerability has been resolved: shmem: fix recovery on rename failures maple_tree insertions can fail if we are seriously short on memory; simple_offset_rename() does not recover well if it runs into that. The same goes for simple_offset_rename_exchange(). Moreover, shmem_whiteout() expects that if it succeeds, the caller will progress to d_move(), i.e. that shmem_rename2() won't fail past the successful call of shmem_whiteout(). Not hard to fix, fortunately - mtree_store() can't fail if the index we are trying to store into is already present in the tree as a singleton. For simple_offset_rename_exchange() that's enough - we just need to be careful about the order of operations. For simple_offset_rename() solution is to preinsert the target into the tree for new_dir; the rest can be done without any potentially failing operations. That preinsertion has to be done in shmem_rename2() rather than in simple_offset_rename() itself - otherwise we'd need to deal with the possibility of failure after successful shmem_whiteout().
02 / AFFECTED SOFTWARE
Affected packages
11 explicit affected versions
50 explicit affected versions
6 explicit affected versions
12 explicit affected versions
19 explicit affected versions
10 explicit affected versions
6 explicit affected versions
24 explicit affected versions
10 explicit affected versions
32 explicit affected versions
26 explicit affected versions
7 explicit affected versions
35 explicit affected versions
13 explicit affected versions
39 explicit affected versions
35 explicit affected versions
18 explicit affected versions
40 explicit affected versions
13 explicit affected versions
4 explicit affected versions
23 explicit affected versions
47 explicit affected versions
1 explicit affected versions
21 explicit affected versions
9 explicit affected versions
16 explicit affected versions
10 explicit affected versions
15 explicit affected versions
43 explicit affected versions
8 explicit affected versions
7 explicit affected versions
12 explicit affected versions
11 explicit affected versions
7 explicit affected versions
12 explicit affected versions
14 explicit affected versions
10 explicit affected versions
1 explicit affected versions
7 explicit affected versions
11 explicit affected versions
12 explicit affected versions
4 explicit affected versions
12 explicit affected versions
36 explicit affected versions
16 explicit affected versions
12 explicit affected versions
25 explicit affected versions
29 explicit affected versions
10 explicit affected versions
37 explicit affected versions
10 explicit affected versions
4 explicit affected versions
13 explicit affected versions
35 explicit affected versions
3 explicit affected versions
10 explicit affected versions
11 explicit affected versions
26 explicit affected versions
6 explicit affected versions
13 explicit affected versions
29 explicit affected versions
13 explicit affected versions
12 explicit affected versions
36 explicit affected versions
36 explicit affected versions
3 explicit affected versions
33 explicit affected versions
23 explicit affected versions
10 explicit affected versions
15 explicit affected versions
14 explicit affected versions
11 explicit affected versions
5 explicit affected versions
12 explicit affected versions
4 explicit affected versions
7 explicit affected versions
12 explicit affected versions
3 explicit affected versions
11 explicit affected versions
5 explicit affected versions
10 explicit affected versions
26 explicit affected versions
34 explicit affected versions
30 explicit affected versions
42 explicit affected versions
11 explicit affected versions
4 explicit affected versions
13 explicit affected versions
41 explicit affected versions
16 explicit affected versions
45 explicit affected versions
3 explicit affected versions
7 explicit affected versions
10 explicit affected versions
51 explicit affected versions
11 explicit affected versions
18 explicit affected versions
37 explicit affected versions
12 explicit affected versions
3 explicit affected versions
27 explicit affected versions
38 explicit affected versions
8 explicit affected versions
5 explicit affected versions
8 explicit affected versions
10 explicit affected versions
7 explicit affected versions
41 explicit affected versions
13 explicit affected versions
13 explicit affected versions
7 explicit affected versions
8 explicit affected versions
10 explicit affected versions
12 explicit affected versions
9 explicit affected versions
44 explicit affected versions
16 explicit affected versions
3 explicit affected versions
13 explicit affected versions
26 explicit affected versions
45 explicit affected versions
37 explicit affected versions
46 explicit affected versions
14 explicit affected versions
38 explicit affected versions
9 explicit affected versions
12 explicit affected versions
11 explicit affected versions
34 explicit affected versions
15 explicit affected versions
9 explicit affected versions
8 explicit affected versions
7 explicit affected versions
4 explicit affected versions
3 explicit affected versions
1 explicit affected versions
13 explicit affected versions
43 explicit affected versions
9 explicit affected versions
10 explicit affected versions
8 explicit affected versions
40 explicit affected versions
14 explicit affected versions
4 explicit affected versions
78 explicit affected versions
9 explicit affected versions
11 explicit affected versions
1 explicit affected versions
14 explicit affected versions
34 explicit affected versions
03 / CONNECTIONS
Connected vulnerabilities
04 / EVIDENCE
Source records
In the Linux kernel, the following vulnerability has been resolved: shmem: fix recovery on rename failures maple_tree insertions can fail if we are seriously short on memory; simple_offset_rename() does not recover well if it runs into that. The same goes for simple_offset_rename_exchange(). Moreover, shmem_whiteout() expects that if it succeeds, the caller will progress to d_move(), i.e. that shmem_rename2() won't fail past the successful call of shmem_whiteout(). Not hard to fix, fortunately - mtree_store() can't fail if the index we are trying to store into is already present in the tree as a singleton. For simple_offset_rename_exchange() that's enough - we just need to be careful about the order of operations. For simple_offset_rename() solution is to preinsert the target into the tree for new_dir; the rest can be done without any potentially failing operations. That preinsertion has to be done in shmem_rename2() rather than in simple_offset_rename() itself - otherwise we'd need to deal with the possibility of failure after successful shmem_whiteout().
05 / REFERENCES
Further evidence
- https://git.kernel.org/linus/e1b4c6a58304fd490124cc2b454d80edc786665c
- https://git.kernel.org/stable/c/4642686699a46718d7f2fb5acd1e9d866a9d9cca
- https://git.kernel.org/stable/c/4b0fe71fb3965d0db83cdfc2f4fe0b3227d70113
- https://git.kernel.org/stable/c/e1b4c6a58304fd490124cc2b454d80edc786665c
- https://ubuntu.com/security/CVE-2025-71072
- https://ubuntu.com/security/notices/USN-8177-1
- https://ubuntu.com/security/notices/USN-8177-2
- https://ubuntu.com/security/notices/USN-8179-1
- https://ubuntu.com/security/notices/USN-8179-2
- https://ubuntu.com/security/notices/USN-8179-3
- https://ubuntu.com/security/notices/USN-8179-4
- https://ubuntu.com/security/notices/USN-8183-1
- https://ubuntu.com/security/notices/USN-8183-2
- https://ubuntu.com/security/notices/USN-8184-1
- https://ubuntu.com/security/notices/USN-8185-1
- https://ubuntu.com/security/notices/USN-8185-2
- https://ubuntu.com/security/notices/USN-8203-1
- https://ubuntu.com/security/notices/USN-8204-1
- https://ubuntu.com/security/notices/USN-8245-1
- https://ubuntu.com/security/notices/USN-8257-1
- https://ubuntu.com/security/notices/USN-8258-1
- https://ubuntu.com/security/notices/USN-8260-1
- https://ubuntu.com/security/notices/USN-8261-1
- https://ubuntu.com/security/notices/USN-8265-1
- https://ubuntu.com/security/notices/USN-8440-1
- https://www.cve.org/CVERecord?id=CVE-2025-71072