[ciqcbr7_9] Multiple patches tested (4 commits)#1373
Conversation
jira VULN-184554 cve CVE-2026-43190 commit-author Florian Westphal <fw@strlen.de> commit 735ee85 Quoting reporter: In net/netfilter/xt_tcpmss.c (lines 53-68), the TCP option parser reads op[i+1] directly without validating the remaining option length. If the last byte of the option field is not EOL/NOP (0/1), the code attempts to index op[i+1]. In the case where i + 1 == optlen, this causes an out-of-bounds read, accessing memory past the optlen boundary (either reading beyond the stack buffer _opt or the following payload). Reported-by: sungzii <sungzii@pm.me> Signed-off-by: Florian Westphal <fw@strlen.de> (cherry picked from commit 735ee85) Signed-off-by: CIQ Kernel Automation <ciq_kernel_automation@ciq.com>
jira VULN-184484 cve CVE-2026-43158 commit-author Darrick J. Wong <djwong@kernel.org> commit 3eefc0c xfs/592 and xfs/794 both trip this assertion in the leaf block freemap adjustment code after ~20 minutes of running on my test VMs: ASSERT(ichdr->firstused >= ichdr->count * sizeof(xfs_attr_leaf_entry_t) + xfs_attr3_leaf_hdr_size(leaf)); Upon enabling quite a lot more debugging code, I narrowed this down to fsstress trying to set a local extended attribute with namelen=3 and valuelen=71. This results in an entry size of 80 bytes. At the start of xfs_attr3_leaf_add_work, the freemap looks like this: i 0 base 448 size 0 rhs 448 count 46 i 1 base 388 size 132 rhs 448 count 46 i 2 base 2120 size 4 rhs 448 count 46 firstused = 520 where "rhs" is the first byte past the end of the leaf entry array. This is inconsistent -- the entries array ends at byte 448, but freemap[1] says there's free space starting at byte 388! By the end of the function, the freemap is in worse shape: i 0 base 456 size 0 rhs 456 count 47 i 1 base 388 size 52 rhs 456 count 47 i 2 base 2120 size 4 rhs 456 count 47 firstused = 440 Important note: 388 is not aligned with the entries array element size of 8 bytes. Based on the incorrect freemap, the name area starts at byte 440, which is below the end of the entries array! That's why the assertion triggers and the filesystem shuts down. How did we end up here? First, recall from the previous patch that the freemap array in an xattr leaf block is not intended to be a comprehensive map of all free space in the leaf block. In other words, it's perfectly legal to have a leaf block with: * 376 bytes in use by the entries array * freemap[0] has [base = 376, size = 8] * freemap[1] has [base = 388, size = 1500] * the space between 376 and 388 is free, but the freemap stopped tracking that some time ago If we add one xattr, the entries array grows to 384 bytes, and freemap[0] becomes [base = 384, size = 0]. So far, so good. But if we add a second xattr, the entries array grows to 392 bytes, and freemap[0] gets pushed up to [base = 392, size = 0]. This is bad, because freemap[1] hasn't been updated, and now the entries array and the free space claim the same space. The fix here is to adjust all freemap entries so that none of them collide with the entries array. Note that this fix relies on commit 2a2b593 ("xfs: fix attr leaf header freemap.size underflow") and the previous patch that resets zero length freemap entries to have base = 0. Cc: <stable@vger.kernel.org> # v2.6.12 Fixes: 1da177e ("Linux-2.6.12-rc2") Signed-off-by: "Darrick J. Wong" <djwong@kernel.org> Reviewed-by: Christoph Hellwig <hch@lst.de> (cherry picked from commit 3eefc0c) Signed-off-by: CIQ Kernel Automation <ciq_kernel_automation@ciq.com>
jira VULN-178537 cve CVE-2026-23243 commit-author YunJe Shin <yjshin0438@gmail.com> commit 5551b02 upstream-diff | cast second param `hdr_size(file) + hdr_len` in `check_sub_overflow` call to size_t to match the type of the first param `count` to fix build issue. ib_umad_write computes data_len from user-controlled count and the MAD header sizes. With a mismatched user MAD header size and RMPP header length, data_len can become negative and reach ib_create_send_mad(). This can make the padding calculation exceed the segment size and trigger an out-of-bounds memset in alloc_send_rmpp_list(). Add an explicit check to reject negative data_len before creating the send buffer. KASAN splat: [ 211.363464] BUG: KASAN: slab-out-of-bounds in ib_create_send_mad+0xa01/0x11b0 [ 211.364077] Write of size 220 at addr ffff88800c3fa1f8 by task spray_thread/102 [ 211.365867] ib_create_send_mad+0xa01/0x11b0 [ 211.365887] ib_umad_write+0x853/0x1c80 Fixes: 2be8e3e ("IB/umad: Add P_Key index support") Signed-off-by: YunJe Shin <ioerts@kookmin.ac.kr> Link: https://patch.msgid.link/20260203100628.1215408-1-ioerts@kookmin.ac.kr Signed-off-by: Leon Romanovsky <leon@kernel.org> (cherry picked from commit 5551b02) Signed-off-by: CIQ Kernel Automation <ciq_kernel_automation@ciq.com>
jira VULN-185617 cve CVE-2026-43110 commit-author Pengpeng Hou <pengpeng@iscas.ac.cn> commit 304950a upstream-diff | Use `brcmf_err` instead of `bphy_err` due to missing dcb1471 ("brcmfmac: use bphy_err() in all wiphy-related code") brcmf_fweh_handle_if_event() validates the firmware-provided interface index before it touches drvr->iflist[], but it still uses the raw bsscfgidx field as an array index without a matching range check. Reject IF events whose bsscfg index does not fit in drvr->iflist[] before indexing the interface array. Signed-off-by: Pengpeng Hou <pengpeng@iscas.ac.cn> Acked-by: Arend van Spriel <arend.vanspriel@broadcom.com> Link: https://patch.msgid.link/20260323074551.93530-1-pengpeng@iscas.ac.cn [add missing wifi prefix] Signed-off-by: Johannes Berg <johannes.berg@intel.com> (cherry picked from commit 304950a) Signed-off-by: CIQ Kernel Automation <ciq_kernel_automation@ciq.com> Signed-off-by: Roxana Nicolescu <rnicolescu@ciq.com>
|
🤖 Validation Checks In Progress Workflow run: https://github.com/ctrliq/kernel-src-tree/actions/runs/28094204789 |
🔍 Interdiff Analysis
================================================================================
* CONTEXT DIFFERENCES - surrounding code differences between the patches *
================================================================================
--- b/fs/xfs/libxfs/xfs_attr_leaf.c
+++ b/fs/xfs/libxfs/xfs_attr_leaf.c
@@ -1434,5 +1580,5 @@
min_t(uint16_t, ichdr->freemap[i].size,
sizeof(xfs_attr_leaf_entry_t));
}
- }
- ichdr->usedbytes += xfs_attr_leaf_entsize(leaf, args->index);
+
+ /*
================================================================================
* DELTA DIFFERENCES - code changes that differ between the patches *
================================================================================
--- b/drivers/infiniband/core/user_mad.c
+++ b/drivers/infiniband/core/user_mad.c
@@ -546,7 +546,7 @@
}
base_version = ((struct ib_mad_hdr *)&packet->mad.data)->base_version;
- if (check_sub_overflow(count, (size_t)(hdr_size(file) + hdr_len), &data_len)) {
+ if (check_sub_overflow(count, hdr_size(file) + hdr_len, &data_len)) {
ret = -EINVAL;
goto err_ah;
}
================================================================================
* CONTEXT DIFFERENCES - surrounding code differences between the patches *
================================================================================
--- b/drivers/infiniband/core/user_mad.c
+++ b/drivers/infiniband/core/user_mad.c
@@ -471,5 +472,4 @@
struct ib_ah *ah;
- struct ib_rmpp_mad *rmpp_mad;
__be64 *tid;
int ret, data_len, hdr_len, copy_offset, rmpp_active;
u8 base_version;
================================================================================
* DELTA DIFFERENCES - code changes that differ between the patches *
================================================================================
--- b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/fweh.c
+++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/fweh.c
@@ -162,7 +162,8 @@
return;
}
if (ifevent->bsscfgidx >= BRCMF_MAX_IFS) {
- brcmf_err("invalid bsscfg index: %u\n", ifevent->bsscfgidx);
+ bphy_err(drvr, "invalid bsscfg index: %u\n",
+ ifevent->bsscfgidx);
return;
}
================================================================================
* CONTEXT DIFFERENCES - surrounding code differences between the patches *
================================================================================
--- b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/fweh.c
+++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/fweh.c
@@ -150,4 +150,4 @@
- brcmf_err("invalid interface index: %u\n", ifevent->ifidx);
+ bphy_err(drvr, "invalid interface index: %u\n", ifevent->ifidx);
return;
}This is an automated interdiff check for backported commits. |
|
✅ Validation checks completed successfully View full results: https://github.com/ctrliq/kernel-src-tree/actions/runs/28094204789 |
PlaidCat
left a comment
There was a problem hiding this comment.
![]()
I had Claude to a survey of incase there is a weird interaction with the cast to size_t from int and mostly concerned about overflow or negative bit set
hdr_size() returns int and hdr_len is int. The expression hdr_size(file) + hdr_len is evaluated in signed int arithmetic first, then cast to size_t. The values are small constants — hdr_size() returns either sizeof(struct ib_user_mad_hdr) or sizeof(struct ib_user_mad_hdr_old) (both small structs), and hdr_len is one of 24/36/40/56/64. There's no realistic scenario where that int addition overflows. The sum is always a small positive number in the range
~60-120 bytes.
Summary
This PR has been automatically created after successful completion of all CI stages.
Commit Message(s)
Test Results
✅ Build Stage
Status: Passed (x86_64)
Build Time: 12m 56s
Total Time: 13m 59s
View build logs
✅ Boot Verification
🤖 This PR was automatically generated by GitHub Actions
Run ID: 28092236561