[LTS 9.6] CVE-2025-38248, CVE-2025-39933, CVE-2025-38730, CVE-2025-38415#1163
Open
pvts-mat wants to merge 9 commits intoctrliq:ciqlts9_6from
Open
[LTS 9.6] CVE-2025-38248, CVE-2025-39933, CVE-2025-38730, CVE-2025-38415#1163pvts-mat wants to merge 9 commits intoctrliq:ciqlts9_6from
pvts-mat wants to merge 9 commits intoctrliq:ciqlts9_6from
Conversation
jira VULN-163295 cve CVE-2025-38415 commit-author Phillip Lougher <phillip@squashfs.org.uk> commit 734aa85 Syzkaller reports an "UBSAN: shift-out-of-bounds in squashfs_bio_read" bug. Syzkaller forks multiple processes which after mounting the Squashfs filesystem, issues an ioctl("/dev/loop0", LOOP_SET_BLOCK_SIZE, 0x8000). Now if this ioctl occurs at the same time another process is in the process of mounting a Squashfs filesystem on /dev/loop0, the failure occurs. When this happens the following code in squashfs_fill_super() fails. ---- msblk->devblksize = sb_min_blocksize(sb, SQUASHFS_DEVBLK_SIZE); msblk->devblksize_log2 = ffz(~msblk->devblksize); ---- sb_min_blocksize() returns 0, which means msblk->devblksize is set to 0. As a result, ffz(~msblk->devblksize) returns 64, and msblk->devblksize_log2 is set to 64. This subsequently causes the UBSAN: shift-out-of-bounds in fs/squashfs/block.c:195:36 shift exponent 64 is too large for 64-bit type 'u64' (aka 'unsigned long long') This commit adds a check for a 0 return by sb_min_blocksize(). Link: https://lkml.kernel.org/r/20250409024747.876480-1-phillip@squashfs.org.uk Fixes: 0aa6661 ("Squashfs: super block operations") Reported-by: syzbot+65761fc25a137b9c8c6e@syzkaller.appspotmail.com Closes: https://lore.kernel.org/all/67f0dd7a.050a0220.0a13.0230.GAE@google.com/ Signed-off-by: Phillip Lougher <phillip@squashfs.org.uk> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> (cherry picked from commit 734aa85) Signed-off-by: Marcin Wcisło <marcin.wcislo@conclusive.pl>
jira VULN-163295 cve-bf CVE-2025-38415 commit-author Phillip Lougher <phillip@squashfs.org.uk> commit b64700d upstream-diff Had to maneuver around the code deleted in the non- backported commit 0c12185 ('Revert "squashfs: provide backing_dev_info in order to disable read-ahead"') If sb_min_blocksize returns 0, squashfs_fill_super exits without freeing allocated memory (sb->s_fs_info). Fix this by moving the call to sb_min_blocksize to before memory is allocated. Link: https://lkml.kernel.org/r/20250811223740.110392-1-phillip@squashfs.org.uk Fixes: 734aa85 ("Squashfs: check return result of sb_min_blocksize") Signed-off-by: Phillip Lougher <phillip@squashfs.org.uk> Reported-by: Scott GUO <scottzhguo@tencent.com> Closes: https://lore.kernel.org/all/20250811061921.3807353-1-scott_gzh@163.com Cc: <stable@vger.kernel.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> (cherry picked from commit b64700d) Signed-off-by: Marcin Wcisło <marcin.wcislo@conclusive.pl>
jira VULN-163643 cve-pre CVE-2025-38730 commit-author Jens Axboe <axboe@kernel.dk> commit 03e02e8 req->buf_list is assigned higher up and is safe to use as we remain within a locked region, as is the 'bl' variable itself from which it was assigned. To improve readability, use 'bl' directly rather than get it from the io_kiocb, if we need to increment the head directly in the buffer selection path. This makes it readily apparent that it's the same io_buffer_list being used. Signed-off-by: Jens Axboe <axboe@kernel.dk> (cherry picked from commit 03e02e8) Signed-off-by: Marcin Wcisło <marcin.wcislo@conclusive.pl>
jira VULN-163643 cve-pre CVE-2025-38730 commit-author Jens Axboe <axboe@kernel.dk> commit ecd5c9b Committing the selected ring buffer is currently done in three different spots, combine it into a helper and just call that. Signed-off-by: Jens Axboe <axboe@kernel.dk> (cherry picked from commit 65e8333f22c50419191e46ef196797904a20c03a) Signed-off-by: Marcin Wcisło <marcin.wcislo@conclusive.pl>
jira VULN-163643 cve CVE-2025-38730 commit-author Jens Axboe <axboe@kernel.dk> commit 41b70df upstream-diff | - In the `io_net_kbuf_recyle()' function - Used `-EAGAIN' as the return value instead of `IOU_RETRY', which was defined in the upstream as `-EAGAIN' anyway (see non-backported 7a9dcb0 ("io_uring: return -EAGAIN to continue multishot")). - Omitted the `len' argument in the `io_kbuf_commit()' call. The upstream patch uses the extended version of this function, defined in ae98dbf ("io_uring/kbuf: add support for incremental buffer consumption"), which was compound with the introduction of new feature. Original version is enough for this patch - see the solution of CVE-2025-38730 in rocky9_7. - Resolved conflict in the `io_recvmsg()' function where `return IOU_RETRY' was expected instead of `return -EAGAIN'. Ring provided buffers are potentially only valid within the single execution context in which they were acquired. io_uring deals with this and invalidates them on retry. But on the networking side, if MSG_WAITALL is set, or if the socket is of the streaming type and too little was processed, then it will hang on to the buffer rather than recycle or commit it. This is problematic for two reasons: 1) If someone unregisters the provided buffer ring before a later retry, then the req->buf_list will no longer be valid. 2) If multiple sockers are using the same buffer group, then multiple receives can consume the same memory. This can cause data corruption in the application, as either receive could land in the same userspace buffer. Fix this by disallowing partial retries from pinning a provided buffer across multiple executions, if ring provided buffers are used. Cc: stable@vger.kernel.org Reported-by: pt x <superman.xpt@gmail.com> Fixes: c56e022 ("io_uring: add support for user mapped provided buffer ring") Signed-off-by: Jens Axboe <axboe@kernel.dk> (cherry picked from commit 41b70df) Signed-off-by: Marcin Wcisło <marcin.wcislo@conclusive.pl>
…ing_data_length jira VULN-161396 cve CVE-2025-39933 commit-author Stefan Metzmacher <metze@samba.org> commit f57e53e upstream-diff | - Ignored the extraction of `sc->parameters' into the local variable `sp'. In the upstream it was only needed to get `max_fragmented_recv_size', which in ciqlts9_6 can be found in the `smbd_connection' struct, saved in the `info' variable. Used direct access `info->max_fragmented_recv_size' where needed. (On upstream the field was moved to `smbdirect_socket_parameters' struct in the non-backported commit cc55f65 ("smb: client: make use of common smbdirect_socket_parameters")). - The offset of `padding' is calculated for the `smbd_data_transfer' struct instead of `smbdirect_data_transfer'. Smenatically it's the same struct, just renamed (introduced in 00fab6c ("smb: smbdirect: add smbdirect_pdu.h with protocol definitions"), swapped with `smbd_data_transfer' in 64946d5 ("smb: client: make use of common smbdirect_pdu.h")) This is inspired by the related server fixes. Cc: Tom Talpey <tom@talpey.com> Cc: Long Li <longli@microsoft.com> Cc: linux-cifs@vger.kernel.org Cc: samba-technical@lists.samba.org Reviewed-by: Namjae Jeon <linkinjeon@kernel.org> Fixes: f198186 ("CIFS: SMBD: Establish SMB Direct connection") Signed-off-by: Stefan Metzmacher <metze@samba.org> Signed-off-by: Steve French <stfrench@microsoft.com> (cherry picked from commit f57e53e) Signed-off-by: Marcin Wcisło <marcin.wcislo@conclusive.pl>
…functions jira VULN-162934 cve-pre CVE-2025-38248 commit-author Yong Wang <yongwang@nvidia.com> commit 4b30ae9 When a bridge port STP state is changed from BLOCKING/DISABLED to FORWARDING, the port's igmp query timer will NOT re-arm itself if the bridge has been configured as per-VLAN multicast snooping. Solve this by choosing the correct multicast context(s) to enable/disable port multicast based on whether per-VLAN multicast snooping is enabled or not, i.e. using per-{port, VLAN} context in case of per-VLAN multicast snooping by re-implementing br_multicast_enable_port() and br_multicast_disable_port() functions. Before the patch, the IGMP query does not happen in the last step of the following test sequence, i.e. no growth for tx counter: # ip link add name br1 up type bridge vlan_filtering 1 mcast_snooping 1 mcast_vlan_snooping 1 mcast_querier 1 mcast_stats_enabled 1 # bridge vlan global set vid 1 dev br1 mcast_snooping 1 mcast_querier 1 mcast_query_interval 100 mcast_startup_query_count 0 # ip link add name swp1 up master br1 type dummy # bridge link set dev swp1 state 0 # ip -j -p stats show dev swp1 group xstats_slave subgroup bridge suite mcast | jq '.[]["multicast"]["igmp_queries"]["tx_v2"]' 1 # sleep 1 # ip -j -p stats show dev swp1 group xstats_slave subgroup bridge suite mcast | jq '.[]["multicast"]["igmp_queries"]["tx_v2"]' 1 # bridge link set dev swp1 state 3 # sleep 2 # ip -j -p stats show dev swp1 group xstats_slave subgroup bridge suite mcast | jq '.[]["multicast"]["igmp_queries"]["tx_v2"]' 1 After the patch, the IGMP query happens in the last step of the test: # ip link add name br1 up type bridge vlan_filtering 1 mcast_snooping 1 mcast_vlan_snooping 1 mcast_querier 1 mcast_stats_enabled 1 # bridge vlan global set vid 1 dev br1 mcast_snooping 1 mcast_querier 1 mcast_query_interval 100 mcast_startup_query_count 0 # ip link add name swp1 up master br1 type dummy # bridge link set dev swp1 state 0 # ip -j -p stats show dev swp1 group xstats_slave subgroup bridge suite mcast | jq '.[]["multicast"]["igmp_queries"]["tx_v2"]' 1 # sleep 1 # ip -j -p stats show dev swp1 group xstats_slave subgroup bridge suite mcast | jq '.[]["multicast"]["igmp_queries"]["tx_v2"]' 1 # bridge link set dev swp1 state 3 # sleep 2 # ip -j -p stats show dev swp1 group xstats_slave subgroup bridge suite mcast | jq '.[]["multicast"]["igmp_queries"]["tx_v2"]' 3 Signed-off-by: Yong Wang <yongwang@nvidia.com> Reviewed-by: Andy Roulin <aroulin@nvidia.com> Reviewed-by: Ido Schimmel <idosch@nvidia.com> Signed-off-by: Petr Machata <petrm@nvidia.com> Acked-by: Nikolay Aleksandrov <razor@blackwall.org> Signed-off-by: David S. Miller <davem@davemloft.net> (cherry picked from commit 4b30ae9) Signed-off-by: Marcin Wcisło <marcin.wcislo@conclusive.pl>
jira VULN-162934 cve-pre CVE-2025-38248 commit-author Yong Wang <yongwang@nvidia.com> commit 6c13104 When the vlan STP state is changed, which could be manipulated by "bridge vlan" commands, similar to port STP state, this also impacts multicast behaviors such as igmp query. In the scenario of per-VLAN snooping, there's a need to update the corresponding multicast context to re-arm the port query timer when vlan state becomes "forwarding" etc. Update br_vlan_set_state() function to enable vlan multicast context in such scenario. Before the patch, the IGMP query does not happen in the last step of the following test sequence, i.e. no growth for tx counter: # ip link add name br1 up type bridge vlan_filtering 1 mcast_snooping 1 mcast_vlan_snooping 1 mcast_querier 1 mcast_stats_enabled 1 # bridge vlan global set vid 1 dev br1 mcast_snooping 1 mcast_querier 1 mcast_query_interval 100 mcast_startup_query_count 0 # ip link add name swp1 up master br1 type dummy # sleep 1 # bridge vlan set vid 1 dev swp1 state 4 # ip -j -p stats show dev swp1 group xstats_slave subgroup bridge suite mcast | jq '.[]["multicast"]["igmp_queries"]["tx_v2"]' 1 # sleep 1 # ip -j -p stats show dev swp1 group xstats_slave subgroup bridge suite mcast | jq '.[]["multicast"]["igmp_queries"]["tx_v2"]' 1 # bridge vlan set vid 1 dev swp1 state 3 # sleep 2 # ip -j -p stats show dev swp1 group xstats_slave subgroup bridge suite mcast | jq '.[]["multicast"]["igmp_queries"]["tx_v2"]' 1 After the patch, the IGMP query happens in the last step of the test: # ip link add name br1 up type bridge vlan_filtering 1 mcast_snooping 1 mcast_vlan_snooping 1 mcast_querier 1 mcast_stats_enabled 1 # bridge vlan global set vid 1 dev br1 mcast_snooping 1 mcast_querier 1 mcast_query_interval 100 mcast_startup_query_count 0 # ip link add name swp1 up master br1 type dummy # sleep 1 # bridge vlan set vid 1 dev swp1 state 4 # ip -j -p stats show dev swp1 group xstats_slave subgroup bridge suite mcast | jq '.[]["multicast"]["igmp_queries"]["tx_v2"]' 1 # sleep 1 # ip -j -p stats show dev swp1 group xstats_slave subgroup bridge suite mcast | jq '.[]["multicast"]["igmp_queries"]["tx_v2"]' 1 # bridge vlan set vid 1 dev swp1 state 3 # sleep 2 # ip -j -p stats show dev swp1 group xstats_slave subgroup bridge suite mcast | jq '.[]["multicast"]["igmp_queries"]["tx_v2"]' 3 Signed-off-by: Yong Wang <yongwang@nvidia.com> Reviewed-by: Andy Roulin <aroulin@nvidia.com> Reviewed-by: Ido Schimmel <idosch@nvidia.com> Signed-off-by: Petr Machata <petrm@nvidia.com> Acked-by: Nikolay Aleksandrov <razor@blackwall.org> Signed-off-by: David S. Miller <davem@davemloft.net> (cherry picked from commit 6c13104) Signed-off-by: Marcin Wcisło <marcin.wcislo@conclusive.pl>
jira VULN-162934 cve CVE-2025-38248 commit-author Ido Schimmel <idosch@nvidia.com> commit 7544f3f upstream-diff Context conflicts resolved The bridge maintains a global list of ports behind which a multicast router resides. The list is consulted during forwarding to ensure multicast packets are forwarded to these ports even if the ports are not member in the matching MDB entry. When per-VLAN multicast snooping is enabled, the per-port multicast context is disabled on each port and the port is removed from the global router port list: # ip link add name br1 up type bridge vlan_filtering 1 mcast_snooping 1 # ip link add name dummy1 up master br1 type dummy # ip link set dev dummy1 type bridge_slave mcast_router 2 $ bridge -d mdb show | grep router router ports on br1: dummy1 # ip link set dev br1 type bridge mcast_vlan_snooping 1 $ bridge -d mdb show | grep router However, the port can be re-added to the global list even when per-VLAN multicast snooping is enabled: # ip link set dev dummy1 type bridge_slave mcast_router 0 # ip link set dev dummy1 type bridge_slave mcast_router 2 $ bridge -d mdb show | grep router router ports on br1: dummy1 Since commit 4b30ae9 ("net: bridge: mcast: re-implement br_multicast_{enable, disable}_port functions"), when per-VLAN multicast snooping is enabled, multicast disablement on a port will disable the per-{port, VLAN} multicast contexts and not the per-port one. As a result, a port will remain in the global router port list even after it is deleted. This will lead to a use-after-free [1] when the list is traversed (when adding a new port to the list, for example): # ip link del dev dummy1 # ip link add name dummy2 up master br1 type dummy # ip link set dev dummy2 type bridge_slave mcast_router 2 Similarly, stale entries can also be found in the per-VLAN router port list. When per-VLAN multicast snooping is disabled, the per-{port, VLAN} contexts are disabled on each port and the port is removed from the per-VLAN router port list: # ip link add name br1 up type bridge vlan_filtering 1 mcast_snooping 1 mcast_vlan_snooping 1 # ip link add name dummy1 up master br1 type dummy # bridge vlan add vid 2 dev dummy1 # bridge vlan global set vid 2 dev br1 mcast_snooping 1 # bridge vlan set vid 2 dev dummy1 mcast_router 2 $ bridge vlan global show dev br1 vid 2 | grep router router ports: dummy1 # ip link set dev br1 type bridge mcast_vlan_snooping 0 $ bridge vlan global show dev br1 vid 2 | grep router However, the port can be re-added to the per-VLAN list even when per-VLAN multicast snooping is disabled: # bridge vlan set vid 2 dev dummy1 mcast_router 0 # bridge vlan set vid 2 dev dummy1 mcast_router 2 $ bridge vlan global show dev br1 vid 2 | grep router router ports: dummy1 When the VLAN is deleted from the port, the per-{port, VLAN} multicast context will not be disabled since multicast snooping is not enabled on the VLAN. As a result, the port will remain in the per-VLAN router port list even after it is no longer member in the VLAN. This will lead to a use-after-free [2] when the list is traversed (when adding a new port to the list, for example): # ip link add name dummy2 up master br1 type dummy # bridge vlan add vid 2 dev dummy2 # bridge vlan del vid 2 dev dummy1 # bridge vlan set vid 2 dev dummy2 mcast_router 2 Fix these issues by removing the port from the relevant (global or per-VLAN) router port list in br_multicast_port_ctx_deinit(). The function is invoked during port deletion with the per-port multicast context and during VLAN deletion with the per-{port, VLAN} multicast context. Note that deleting the multicast router timer is not enough as it only takes care of the temporary multicast router states (1 or 3) and not the permanent one (2). [1] BUG: KASAN: slab-out-of-bounds in br_multicast_add_router.part.0+0x3f1/0x560 Write of size 8 at addr ffff888004a67328 by task ip/384 [...] Call Trace: <TASK> dump_stack_lvl+0x6f/0xa0 print_address_description.constprop.0+0x6f/0x350 print_report+0x108/0x205 kasan_report+0xdf/0x110 br_multicast_add_router.part.0+0x3f1/0x560 br_multicast_set_port_router+0x74e/0xac0 br_setport+0xa55/0x1870 br_port_slave_changelink+0x95/0x120 __rtnl_newlink+0x5e8/0xa40 rtnl_newlink+0x627/0xb00 rtnetlink_rcv_msg+0x6fb/0xb70 netlink_rcv_skb+0x11f/0x350 netlink_unicast+0x426/0x710 netlink_sendmsg+0x75a/0xc20 __sock_sendmsg+0xc1/0x150 ____sys_sendmsg+0x5aa/0x7b0 ___sys_sendmsg+0xfc/0x180 __sys_sendmsg+0x124/0x1c0 do_syscall_64+0xbb/0x360 entry_SYSCALL_64_after_hwframe+0x4b/0x53 [2] BUG: KASAN: slab-use-after-free in br_multicast_add_router.part.0+0x378/0x560 Read of size 8 at addr ffff888009f00840 by task bridge/391 [...] Call Trace: <TASK> dump_stack_lvl+0x6f/0xa0 print_address_description.constprop.0+0x6f/0x350 print_report+0x108/0x205 kasan_report+0xdf/0x110 br_multicast_add_router.part.0+0x378/0x560 br_multicast_set_port_router+0x6f9/0xac0 br_vlan_process_options+0x8b6/0x1430 br_vlan_rtm_process_one+0x605/0xa30 br_vlan_rtm_process+0x396/0x4c0 rtnetlink_rcv_msg+0x2f7/0xb70 netlink_rcv_skb+0x11f/0x350 netlink_unicast+0x426/0x710 netlink_sendmsg+0x75a/0xc20 __sock_sendmsg+0xc1/0x150 ____sys_sendmsg+0x5aa/0x7b0 ___sys_sendmsg+0xfc/0x180 __sys_sendmsg+0x124/0x1c0 do_syscall_64+0xbb/0x360 entry_SYSCALL_64_after_hwframe+0x4b/0x53 Fixes: 2796d84 ("net: bridge: vlan: convert mcast router global option to per-vlan entry") Fixes: 4b30ae9 ("net: bridge: mcast: re-implement br_multicast_{enable, disable}_port functions") Reported-by: syzbot+7bfa4b72c6a5da128d32@syzkaller.appspotmail.com Closes: https://lore.kernel.org/all/684c18bd.a00a0220.279073.000b.GAE@google.com/T/ Signed-off-by: Ido Schimmel <idosch@nvidia.com> Link: https://patch.msgid.link/20250619182228.1656906-1-idosch@nvidia.com Signed-off-by: Jakub Kicinski <kuba@kernel.org> (cherry picked from commit 7544f3f) Signed-off-by: Marcin Wcisło <marcin.wcislo@conclusive.pl>
pvts-mat
force-pushed
the
ciqlts9_6-CVE-batch-29
branch
from
685e4ee to
681ec38
Compare
Contributor
Author
|
Latest ciqlts9_6 rebase |
Contributor
Author
|
Regarding CVE-2025-38248 I just did bug replication test for LTS 9.4, which I also have on the list to port the fix. Results can be summarized as:
where bug [1] and bug [2] are those referenced in the 7544f3f commit's message. This confirms that These results are for LTS 9.4, not LTS 9.6, but - judging by git history - the bridge multicast feature is very similar in both versions, so it's highly likely those results apply to LTS 9.6 as well. |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
[LTS 9.6]
Commits
CVE-2025-38248
The Linux kernel advisory page for CVE-2025-38248 points to the commit 2796d84 as introducing the bug:
However, the fixing commit 7544f3f lists another commit which it "Fixes", two in total:
Additionally, the commit message says
This explicitly says that at least one of the two UAFs addressed in the fix happens after the change introduced by the second commit 4b30ae9.
The issue is that the first bug-introducing commit 2796d84 was ported to LTS 9.6 as f5b0bea, but the second 4b30ae9 was not. This makes it unclear whether LTS 9.6 is affected by CVE-2025-38248 and to what extent.
None of the commits 2796d84 and 4b30ae9 share code changes with the CVE-2025-38248 fix 7544f3f, so the problem of bug applicability cannot be resolved by simple code analysis (eg. "affected code not present", etc.)
Commit 4b30ae9 is a bugfix, not an introduction of new feature. This may not be obvious from the tags, because it doesn't contain any
Fixes, but the message clearly contains a statement of a problem and a solution proposition:Given, that:
it was decided to simply backport 4b30ae9
net: bridge: mcast: re-implement br_multicast_{enable, disable}_port functionsas the prerequisite for CVE-2025-38248 solution.The other commit - 6c13104
net: bridge: mcast: update multicast contex when vlan state is changed- was implied by 4b30ae9, as they both address the same issue triggered in different places: bridge port STP state change and vlan STP state change. See commit 88922fe description:They were part of a single upstream-merged branch devoted to this problem:
The selftest commit was omitted in the solution proposed in this PR.
Compare the backporting situation between other Linux versions
The fix in this PR basically syncs the
net/bridge/br_multicast.cfile withrocky9_7.CVE-2025-39933
Changing the type of local variable
data_lengthfrominttou32may raise suspicion, but it doesn't influence the logic of code existing before this patch. Apart from conditionals it's only used as the argument inenqueue_reassembly()call accepting it asint. Upstream body of the modified function also passes this variable toenqueue_reassembly()and its signature is the same as inciqlts9_6, so - assuming the upstream code is correct in this regard - the backported version should be correct as well.CVE-2025-38730
0:
1:
2:
While this prerequisite wasn't strictly necessary (the change is overwriteen by the next commit anyway), it allowed for clean cherry picks.
This solution is identical to what can be found in
rocky9_7. Consider the comparative history of relevant files inciqlts9_6androcky9_7(ellipsis[...]hide parts of history which are the same for both):With this fix the gaps are filled and the three files are identical in both versions.
The
io_kbuf_commit()functionIn the upsteram fix 41b70df the newly introduced function
io_net_kbuf_recyle()usesio_kbuf_commit()which is considerably different from when it was introduced in ecd5c9b - the version used in this solution. Compare the PR's:kernel-src-tree/io_uring/kbuf.h
Lines 124 to 131 in ecd5c9b
with the version used by upstream:
kernel-src-tree/io_uring/kbuf.c
Lines 35 to 61 in 5d3e512
The full timeline of
io_kbuf_commit()function definition is:This may raise the question about the validity of using
io_kbuf_commit()from ecd5c9b instead of 5d3e512.From the
ciqlts9_6's perspective there is no difference, because the only logical change in ae98dbf boils down tolenargument,IOBL_INCflag being set,boolinstead ofvoid,and (1) and (3) are only really a consequence of (2). The
IOBL_INCflag was only introduced in the very same commit which extendedio_kbuf_commit()functionality -io_uring/kbuf: add support for incremental buffer consumption- which was not backported tociqlts9_6and therefore the conditionalbl->flags & IOBL_INCfor the introduced branch could not be true in this version anyway.CVE-2025-38415
kABI check: passed
Boot test: passed
boot-test.log
Kselftests: passed relative
Reference
kselftests–ciqlts9_6–run1.log
kselftests–ciqlts9_6–run2.log
Patch
kselftests–ciqlts9_6-CVE-batch-29–run1.log
kselftests–ciqlts9_6-CVE-batch-29–run2.log
Comparison
There is one test having different results -
kvm:memslot_perf_test- but it's for the patch's advantage.selftests-full-results.txt