Skip to content

[ciqlts9_6] Multiple patches tested (4 commits) - #1607

Open
ciq-kernel-automation[bot] wants to merge 4 commits into
ciqlts9_6from
{ciq_kernel_automation}_ciqlts9_6
Open

[ciqlts9_6] Multiple patches tested (4 commits)#1607
ciq-kernel-automation[bot] wants to merge 4 commits into
ciqlts9_6from
{ciq_kernel_automation}_ciqlts9_6

Conversation

@ciq-kernel-automation

@ciq-kernel-automation ciq-kernel-automation Bot commented Sep 14, 2026

Copy link
Copy Markdown

Summary

This PR has been automatically created after successful completion of all CI stages.

Commit Message(s)

io_uring/poll: fix signed comparison in io_poll_get_ownership()

jira VULN-189078
cve CVE-2026-52933
commit-author Longxuan Yu <ylong030@ucr.edu>
commit 326941b22806cbf2df1fbfe902b7908b368cce42

i2c: stub: Reject I2C block transfers with invalid length

jira VULN-192584
cve CVE-2026-64191
commit-author Weiming Shi <bestswngs@gmail.com>
commit 6036b5067a8199ba7a2dc7b377d4b9dd276d5f9e

USB: serial: io_ti: fix heap overflow in get_manuf_info()

jira VULN-189707
cve CVE-2026-53196
commit-author Adrian Korwel <adriank20047@gmail.com>
commit 183c1076eca43bbb3e7bdf597456f91d81c73e74

zram: fix use-after-free in zram_bvec_write_partial()

jira VULN-190462
cve CVE-2026-53185
commit-author Cunlong Li <shenxiaogll@gmail.com>
commit 732fd9f0b9c1cdc6dfd77162ded60df005182cc0

Test Results

✅ Build Stage

Architecture Build Time Total Time
x86_64 24m 8s 24m 56s
aarch64 12m 43s 13m 14s

✅ Boot Verification

✅ Kernel Selftests

Architecture Passed Failed Compared Against Status
x86_64 206 43 ciqlts9_6 ✅ No regressions
aarch64 154 45 ciqlts9_6 ✅ No regressions

✅ LTP Results

Architecture Passed Failed Compared Against Status
x86_64 1452 83 ciqlts9_6 ❌ 1 regressions
aarch64 1426 83 ciqlts9_6 ✅ No regressions

x86_64 regressions:

  • clock_adjtime01 (PASS -> FAIL)

🤖 This PR was automatically generated by GitHub Actions
Run ID: 34813546712

CIQ Kernel Automation added 4 commits September 14, 2026 06:20
CIQ Kernel Automation
io_uring/poll: fix signed comparison in io_poll_get_ownership()
ce0b702 
jira VULN-189078
cve CVE-2026-52933
commit-author Longxuan Yu <ylong030@ucr.edu>
commit 326941b

io_poll_get_ownership() uses a signed comparison to check whether
poll_refs has reached the threshold for the slowpath:

    if (unlikely(atomic_read(&req->poll_refs) >= IO_POLL_REF_BIAS))

atomic_read() returns int (signed). When IO_POLL_CANCEL_FLAG
(BIT(31)) is set in poll_refs, the value becomes negative in
signed arithmetic, so the >= 128 comparison always evaluates to
false and the slowpath is never taken.

Fix this by casting the atomic_read() result to unsigned int
before the comparison, so that the cancel flag is treated as a
large positive value and correctly triggers the slowpath.

Fixes: a26a35e ("io_uring: make poll refs more robust")
	Cc: stable@vger.kernel.org
	Reported-by: Yifan Wu <yifanwucs@gmail.com>
	Reported-by: Juefei Pu <tomapufckgml@gmail.com>
Co-developed-by: Yuan Tan <yuantan098@gmail.com>
	Signed-off-by: Yuan Tan <yuantan098@gmail.com>
	Suggested-by: Xin Liu <bird@lzu.edu.cn>
	Tested-by: Zhengchuan Liang <zcliangcn@gmail.com>
	Signed-off-by: Longxuan Yu <ylong030@ucr.edu>
	Signed-off-by: Ren Wei <n05ec@lzu.edu.cn>
	Reviewed-by: Pavel Begunkov <asml.silence@gmail.com>
Link: https://patch.msgid.link/3a3508b08bcd7f1bc3beff848ae6e1d73d355043.1775965597.git.ylong030@ucr.edu
	Signed-off-by: Jens Axboe <axboe@kernel.dk>
(cherry picked from commit 326941b)
	Signed-off-by: CIQ Kernel Automation <ciq_kernel_automation@ciq.com>
CIQ Kernel Automation
i2c: stub: Reject I2C block transfers with invalid length
fdb4a81 
jira VULN-192584
cve CVE-2026-64191
commit-author Weiming Shi <bestswngs@gmail.com>
commit 6036b50

The I2C_SMBUS_I2C_BLOCK_DATA case in stub_xfer() uses data->block[0]
as the transfer length. The existing check only clamps it to avoid
overrunning the chip->words[256] register array, but does not validate
it against I2C_SMBUS_BLOCK_MAX (32), which is the limit of the union
i2c_smbus_data.block buffer (34 bytes total). The driver is a
development/test tool (CONFIG_I2C_STUB=m, not built by default)
that must be loaded with a chip_addr= parameter.

A local user with access to /dev/i2c-* can issue an I2C_SMBUS ioctl
with I2C_SMBUS_I2C_BLOCK_DATA and data->block[0] > 32, causing
stub_xfer() to read or write past the end of the union
i2c_smbus_data.block buffer:

 BUG: KASAN: stack-out-of-bounds in stub_xfer (drivers/i2c/i2c-stub.c:223)
 Read of size 1 at addr ffff88800abcfd92 by task exploit/81
 Call Trace:
  <TASK>
  stub_xfer (drivers/i2c/i2c-stub.c:223)
  __i2c_smbus_xfer (drivers/i2c/i2c-core-smbus.c:593)
  i2c_smbus_xfer (drivers/i2c/i2c-core-smbus.c:536)
  i2cdev_ioctl_smbus (drivers/i2c/i2c-dev.c:391)
  i2cdev_ioctl (drivers/i2c/i2c-dev.c:478)
  __x64_sys_ioctl (fs/ioctl.c:583)
  do_syscall_64 (arch/x86/entry/syscall_64.c:94)
  entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:130)
  </TASK>

The bug exists because i2c-stub implements .smbus_xfer directly,
bypassing the I2C_SMBUS_BLOCK_MAX validation in
i2c_smbus_xfer_emulated(). The I2C_SMBUS_BLOCK_DATA case in the same
function correctly validates against I2C_SMBUS_BLOCK_MAX, but the
I2C_SMBUS_I2C_BLOCK_DATA case does not.

Fix by rejecting transfers with data->block[0] == 0 or
data->block[0] > I2C_SMBUS_BLOCK_MAX with -EINVAL, consistent with
both the I2C_SMBUS_BLOCK_DATA case in the same function and the
I2C_SMBUS_I2C_BLOCK_DATA validation in i2c_smbus_xfer_emulated().

Fixes: 4710317 ("i2c-stub: Implement I2C block support")
	Reported-by: Xiang Mei <xmei5@asu.edu>
	Signed-off-by: Weiming Shi <bestswngs@gmail.com>
	Reviewed-by: Jean Delvare <jdelvare@suse.de>
	Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
(cherry picked from commit 6036b50)
	Signed-off-by: CIQ Kernel Automation <ciq_kernel_automation@ciq.com>
CIQ Kernel Automation
USB: serial: io_ti: fix heap overflow in get_manuf_info()
811c142 
jira VULN-189707
cve CVE-2026-53196
commit-author Adrian Korwel <adriank20047@gmail.com>
commit 183c107

get_manuf_info() reads le16_to_cpu(rom_desc->Size) bytes from the
device I2C EEPROM into a buffer allocated with kmalloc_obj(), which
is sizeof(struct edge_ti_manuf_descriptor) = 10 bytes.

The Size field comes from the device and is only validated (in
check_i2c_image()) to make sure the descriptor fits within
TI_MAX_I2C_SIZE (16384 bytes), not against the destination buffer size.
A malicious USB device can therefore set Size to any value up to 16377,
causing a heap overflow of up to 16367 bytes when plugged into a host
running this driver.

valid_csum() is called after read_rom() and also iterates
buffer[0..Size-1], compounding the out-of-bounds access.

Fix by rejecting descriptors with unexpected length before calling
read_rom().

Fixes: 1da177e ("Linux-2.6.12-rc2")
	Cc: stable@vger.kernel.org
	Signed-off-by: Adrian Korwel <adriank20047@gmail.com>
[ johan: amend commit message; also check for short descriptors ]
	Signed-off-by: Johan Hovold <johan@kernel.org>
(cherry picked from commit 183c107)
	Signed-off-by: CIQ Kernel Automation <ciq_kernel_automation@ciq.com>
CIQ Kernel Automation
zram: fix use-after-free in zram_bvec_write_partial()
4286c3d 
jira VULN-190462
cve CVE-2026-53185
commit-author Cunlong Li <shenxiaogll@gmail.com>
commit 732fd9f

zram_read_page() picks the sync or async backing device read path based on
whether the parent bio is NULL.  zram_bvec_write_partial() passes its
parent bio down, so for ZRAM_WB slots the read is dispatched
asynchronously and zram_read_page() returns 0 while the bio is still in
flight.  The caller then runs memcpy_from_bvec(), zram_write_page() and
__free_page() on the buffer, leaving the async read to write into a freed
page.

zram_bvec_read_partial() was switched to NULL in commit 4e3c87b
("zram: fix synchronous reads") for the same reason; the write_partial
counterpart was missed.

Link: https://lore.kernel.org/20260528-zram-v3-1-cab86eef8764@gmail.com
Fixes: 8e654f8 ("zram: read page from backing device")
	Reviewed-by: Christoph Hellwig <hch@lst.de>
	Reviewed-by: Sergey Senozhatsky <senozhatsky@chromium.org>
	Signed-off-by: Cunlong Li <shenxiaogll@gmail.com>
	Cc: Jens Axboe <axboe@kernel.dk>
	Cc: Minchan Kim <minchan@kernel.org>
	Cc: Yisheng Xie <xieyisheng1@huawei.com>
	Cc: <stable@vger.kernel.org>
	Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
(cherry picked from commit 732fd9f)
	Signed-off-by: CIQ Kernel Automation <ciq_kernel_automation@ciq.com>
@ciq-kernel-automation ciq-kernel-automation Bot added the created-by-kernelci Tag PRs that were automatically created when a user branch was pushed to the repo (kernelCI) label Sep 14, 2026
@github-actions

github-actions Bot commented Sep 14, 2026

Copy link
Copy Markdown

🤖 Validation Checks In Progress Workflow run: https://github.com/ctrliq/kernel-src-tree/actions/runs/34831159148

@github-actions

github-actions Bot commented Sep 14, 2026

Copy link
Copy Markdown

✅ Validation checks completed successfully View full results: https://github.com/ctrliq/kernel-src-tree/actions/runs/34831159148

bmastbergen
bmastbergen approved these changes Sep 14, 2026
View reviewed changes

@bmastbergen bmastbergen left a comment

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🥌

@bmastbergen
bmastbergen requested a review from a team September 14, 2026 13:53
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Reviewers

@bmastbergen bmastbergen bmastbergen approved these changes

At least 2 approving reviews are required to merge this pull request.

Assignees

No one assigned

Labels

created-by-kernelci Tag PRs that were automatically created when a user branch was pushed to the repo (kernelCI)

Milestone

No milestone

Development

Successfully merging this pull request may close these issues.

1 participant

@bmastbergen