[ciqlts9_2] Multiple patches tested (8 commits) by ciq-kernel-automation[bot] · Pull Request #1150 · ctrliq/kernel-src-tree

ciq-kernel-automation · 2026-04-27T10:38:28Z

Summary

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

Commit Message(s)

tty: Fix out-of-bound vmalloc access in imageblit

jira VULN-63584
cve CVE-2021-47383
commit-author Igor Matheus Andrade Torrente <igormtorrente@gmail.com>
commit 3b0c406124719b625b1aba431659f5cdc24a982c

net: hns3: do not allow call hns3_nic_net_open repeatedly

jira VULN-3098
cve CVE-2021-47400
commit-author Jian Shen <shenjian15@huawei.com>
commit 5b09e88e1bf7fe86540fab4b5f3eece8abead39e

hwmon: (w83792d) Fix NULL pointer dereference by removing unnecessary structure field

jira VULN-63624
cve CVE-2021-47385
commit-author Nadezda Lutovinova <lutovinova@ispras.ru>
commit 0f36b88173f028e372668ae040ab1a496834d278

hwmon: (w83793) Fix NULL pointer dereference by removing unnecessary structure field

jira VULN-63632
cve CVE-2021-47384
commit-author Nadezda Lutovinova <lutovinova@ispras.ru>
commit dd4d747ef05addab887dc8ff0d6ab9860bbcd783

ethernet: hisilicon: hns: hns_dsaf_misc: fix a possible array overflow in hns_dsaf_ge_srst_by_port()

jira VULN-4395
cve CVE-2021-47548
commit-author Teng Qi <starmiku1207184332@gmail.com>
commit a66998e0fbf213d47d02813b9679426129d0d114

net: amd-xgbe: Fix skb data length underflow

jira VULN-4427
cve CVE-2022-48743
commit-author Shyam Sundar S K <Shyam-sundar.S-k@amd.com>
commit 5aac9108a180fc06e28d4e7fb00247ce603b72ee

um: Fix out-of-bounds read in LDT setup

jira VULN-51243
cve CVE-2022-49395
commit-author Vincent Whitchurch <vincent.whitchurch@axis.com>
commit 2a4a62a14be1947fa945c5c11ebf67326381a568

vt: fix memory overlapping when deleting chars in the buffer

jira VULN-241
cve CVE-2022-48627
commit-author Yangxi Xiang <xyangxi5@gmail.com>
commit 39cdb68c64d84e71a4a717000b6e5de208ee60cc

Test Results

✅ Build Stage

Architecture	Build Time	Total Time
x86_64	22m 14s	22m 53s
aarch64	12m 28s	12m 59s

View build logs

✅ Boot Verification

Status: Passed (all architectures)
View boot logs

✅ Kernel Selftests

Architecture	Passed	Failed	Compared Against	Status
x86_64	174	24	ciqlts9_2	✅ No regressions
aarch64	141	27	ciqlts9_2	✅ No regressions

View kselftest logs

✅ LTP Results

Architecture	Passed	Failed	Compared Against	Status
x86_64	1321	81	ciqlts9_2	⚠️ No baseline available
aarch64	1291	83	ciqlts9_2	⚠️ No baseline available

View LTP logs

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

jira VULN-63584 cve CVE-2021-47383 commit-author Igor Matheus Andrade Torrente <igormtorrente@gmail.com> commit 3b0c406 This issue happens when a userspace program does an ioctl FBIOPUT_VSCREENINFO passing the fb_var_screeninfo struct containing only the fields xres, yres, and bits_per_pixel with values. If this struct is the same as the previous ioctl, the vc_resize() detects it and doesn't call the resize_screen(), leaving the fb_var_screeninfo incomplete. And this leads to the updatescrollmode() calculates a wrong value to fbcon_display->vrows, which makes the real_y() return a wrong value of y, and that value, eventually, causes the imageblit to access an out-of-bound address value. To solve this issue I made the resize_screen() be called even if the screen does not need any resizing, so it will "fix and fill" the fb_var_screeninfo independently. Cc: stable <stable@vger.kernel.org> # after 5.15-rc2 is out, give it time to bake Reported-and-tested-by: syzbot+858dc7a2f7ef07c2c219@syzkaller.appspotmail.com Signed-off-by: Igor Matheus Andrade Torrente <igormtorrente@gmail.com> Link: https://lore.kernel.org/r/20210628134509.15895-1-igormtorrente@gmail.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> (cherry picked from commit 3b0c406) Signed-off-by: CIQ Kernel Automation <ciq_kernel_automation@ciq.com>

jira VULN-3098 cve CVE-2021-47400 commit-author Jian Shen <shenjian15@huawei.com> commit 5b09e88 hns3_nic_net_open() is not allowed to called repeatly, but there is no checking for this. When doing device reset and setup tc concurrently, there is a small oppotunity to call hns3_nic_net_open repeatedly, and cause kernel bug by calling napi_enable twice. The calltrace information is like below: [ 3078.222780] ------------[ cut here ]------------ [ 3078.230255] kernel BUG at net/core/dev.c:6991! [ 3078.236224] Internal error: Oops - BUG: 0 [#1] PREEMPT SMP [ 3078.243431] Modules linked in: hns3 hclgevf hclge hnae3 vfio_iommu_type1 vfio_pci vfio_virqfd vfio pv680_mii(O) [ 3078.258880] CPU: 0 PID: 295 Comm: kworker/u8:5 Tainted: G O 5.14.0-rc4+ #1 [ 3078.269102] Hardware name: , BIOS KpxxxFPGA 1P B600 V181 08/12/2021 [ 3078.276801] Workqueue: hclge hclge_service_task [hclge] [ 3078.288774] pstate: 60400009 (nZCv daif +PAN -UAO -TCO BTYPE=--) [ 3078.296168] pc : napi_enable+0x80/0x84 tc qdisc sho[w 3d0e7v8 .e3t0h218 79] lr : hns3_nic_net_open+0x138/0x510 [hns3] [ 3078.314771] sp : ffff8000108abb20 [ 3078.319099] x29: ffff8000108abb20 x28: 0000000000000000 x27: ffff0820a8490300 [ 3078.329121] x26: 0000000000000001 x25: ffff08209cfc6200 x24: 0000000000000000 [ 3078.339044] x23: ffff0820a8490300 x22: ffff08209cd76000 x21: ffff0820abfe3880 [ 3078.349018] x20: 0000000000000000 x19: ffff08209cd76900 x18: 0000000000000000 [ 3078.358620] x17: 0000000000000000 x16: ffffc816e1727a50 x15: 0000ffff8f4ff930 [ 3078.368895] x14: 0000000000000000 x13: 0000000000000000 x12: 0000259e9dbeb6b4 [ 3078.377987] x11: 0096a8f7e764eb40 x10: 634615ad28d3eab5 x9 : ffffc816ad8885b8 [ 3078.387091] x8 : ffff08209cfc6fb8 x7 : ffff0820ac0da058 x6 : ffff0820a8490344 [ 3078.396356] x5 : 0000000000000140 x4 : 0000000000000003 x3 : ffff08209cd76938 [ 3078.405365] x2 : 0000000000000000 x1 : 0000000000000010 x0 : ffff0820abfe38a0 [ 3078.414657] Call trace: [ 3078.418517] napi_enable+0x80/0x84 [ 3078.424626] hns3_reset_notify_up_enet+0x78/0xd0 [hns3] [ 3078.433469] hns3_reset_notify+0x64/0x80 [hns3] [ 3078.441430] hclge_notify_client+0x68/0xb0 [hclge] [ 3078.450511] hclge_reset_rebuild+0x524/0x884 [hclge] [ 3078.458879] hclge_reset_service_task+0x3c4/0x680 [hclge] [ 3078.467470] hclge_service_task+0xb0/0xb54 [hclge] [ 3078.475675] process_one_work+0x1dc/0x48c [ 3078.481888] worker_thread+0x15c/0x464 [ 3078.487104] kthread+0x160/0x170 [ 3078.492479] ret_from_fork+0x10/0x18 [ 3078.498785] Code: c8027c81 35ffffa2 d50323bf d65f03c0 (d4210000) [ 3078.506889] ---[ end trace 8ebe0340a1b0fb44 ]--- Once hns3_nic_net_open() is excute success, the flag HNS3_NIC_STATE_DOWN will be cleared. So add checking for this flag, directly return when HNS3_NIC_STATE_DOWN is no set. Fixes: e888402 ("net: hns3: call hns3_nic_net_open() while doing HNAE3_UP_CLIENT") Signed-off-by: Jian Shen <shenjian15@huawei.com> Signed-off-by: Guangbin Huang <huangguangbin2@huawei.com> Signed-off-by: David S. Miller <davem@davemloft.net> (cherry picked from commit 5b09e88) Signed-off-by: CIQ Kernel Automation <ciq_kernel_automation@ciq.com>

… structure field jira VULN-63624 cve CVE-2021-47385 commit-author Nadezda Lutovinova <lutovinova@ispras.ru> commit 0f36b88 If driver read val value sufficient for (val & 0x08) && (!(val & 0x80)) && ((val & 0x7) == ((val >> 4) & 0x7)) from device then Null pointer dereference occurs. (It is possible if tmp = 0b0xyz1xyz, where same literals mean same numbers) Also lm75[] does not serve a purpose anymore after switching to devm_i2c_new_dummy_device() in w83791d_detect_subclients(). The patch fixes possible NULL pointer dereference by removing lm75[]. Found by Linux Driver Verification project (linuxtesting.org). Cc: stable@vger.kernel.org Signed-off-by: Nadezda Lutovinova <lutovinova@ispras.ru> Link: https://lore.kernel.org/r/20210921155153.28098-2-lutovinova@ispras.ru [groeck: Dropped unnecessary continuation lines, fixed multipline alignment] Signed-off-by: Guenter Roeck <linux@roeck-us.net> (cherry picked from commit 0f36b88) Signed-off-by: CIQ Kernel Automation <ciq_kernel_automation@ciq.com>

…structure field jira VULN-63632 cve CVE-2021-47384 commit-author Nadezda Lutovinova <lutovinova@ispras.ru> commit dd4d747 If driver read tmp value sufficient for (tmp & 0x08) && (!(tmp & 0x80)) && ((tmp & 0x7) == ((tmp >> 4) & 0x7)) from device then Null pointer dereference occurs. (It is possible if tmp = 0b0xyz1xyz, where same literals mean same numbers) Also lm75[] does not serve a purpose anymore after switching to devm_i2c_new_dummy_device() in w83791d_detect_subclients(). The patch fixes possible NULL pointer dereference by removing lm75[]. Found by Linux Driver Verification project (linuxtesting.org). Cc: stable@vger.kernel.org Signed-off-by: Nadezda Lutovinova <lutovinova@ispras.ru> Link: https://lore.kernel.org/r/20210921155153.28098-3-lutovinova@ispras.ru [groeck: Dropped unnecessary continuation lines, fixed multi-line alignments] Signed-off-by: Guenter Roeck <linux@roeck-us.net> (cherry picked from commit dd4d747) Signed-off-by: CIQ Kernel Automation <ciq_kernel_automation@ciq.com>

…w in hns_dsaf_ge_srst_by_port() jira VULN-4395 cve CVE-2021-47548 commit-author Teng Qi <starmiku1207184332@gmail.com> commit a66998e The if statement: if (port >= DSAF_GE_NUM) return; limits the value of port less than DSAF_GE_NUM (i.e., 8). However, if the value of port is 6 or 7, an array overflow could occur: port_rst_off = dsaf_dev->mac_cb[port]->port_rst_off; because the length of dsaf_dev->mac_cb is DSAF_MAX_PORT_NUM (i.e., 6). To fix this possible array overflow, we first check port and if it is greater than or equal to DSAF_MAX_PORT_NUM, the function returns. Reported-by: TOTE Robot <oslab@tsinghua.edu.cn> Signed-off-by: Teng Qi <starmiku1207184332@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net> (cherry picked from commit a66998e) Signed-off-by: CIQ Kernel Automation <ciq_kernel_automation@ciq.com>

jira VULN-4427 cve CVE-2022-48743 commit-author Shyam Sundar S K <Shyam-sundar.S-k@amd.com> commit 5aac910 There will be BUG_ON() triggered in include/linux/skbuff.h leading to intermittent kernel panic, when the skb length underflow is detected. Fix this by dropping the packet if such length underflows are seen because of inconsistencies in the hardware descriptors. Fixes: 622c36f ("amd-xgbe: Fix jumbo MTU processing on newer hardware") Suggested-by: Tom Lendacky <thomas.lendacky@amd.com> Signed-off-by: Shyam Sundar S K <Shyam-sundar.S-k@amd.com> Acked-by: Tom Lendacky <thomas.lendacky@amd.com> Link: https://lore.kernel.org/r/20220127092003.2812745-1-Shyam-sundar.S-k@amd.com Signed-off-by: Jakub Kicinski <kuba@kernel.org> (cherry picked from commit 5aac910) Signed-off-by: CIQ Kernel Automation <ciq_kernel_automation@ciq.com>

jira VULN-51243 cve CVE-2022-49395 commit-author Vincent Whitchurch <vincent.whitchurch@axis.com> commit 2a4a62a syscall_stub_data() expects the data_count parameter to be the number of longs, not bytes. ================================================================== BUG: KASAN: stack-out-of-bounds in syscall_stub_data+0x70/0xe0 Read of size 128 at addr 000000006411f6f0 by task swapper/1 CPU: 0 PID: 1 Comm: swapper Not tainted 5.18.0+ #18 Call Trace: show_stack.cold+0x166/0x2a7 __dump_stack+0x3a/0x43 dump_stack_lvl+0x1f/0x27 print_report.cold+0xdb/0xf81 kasan_report+0x119/0x1f0 kasan_check_range+0x3a3/0x440 memcpy+0x52/0x140 syscall_stub_data+0x70/0xe0 write_ldt_entry+0xac/0x190 init_new_ldt+0x515/0x960 init_new_context+0x2c4/0x4d0 mm_init.constprop.0+0x5ed/0x760 mm_alloc+0x118/0x170 0x60033f48 do_one_initcall+0x1d7/0x860 0x60003e7b kernel_init+0x6e/0x3d4 new_thread_handler+0x1e7/0x2c0 The buggy address belongs to stack of task swapper/1 and is located at offset 64 in frame: init_new_ldt+0x0/0x960 This frame has 2 objects: [32, 40) 'addr' [64, 80) 'desc' ================================================================== Fixes: 858259c ("uml: maintain own LDT entries") Signed-off-by: Vincent Whitchurch <vincent.whitchurch@axis.com> Cc: stable@vger.kernel.org Signed-off-by: Richard Weinberger <richard@nod.at> (cherry picked from commit 2a4a62a) Signed-off-by: CIQ Kernel Automation <ciq_kernel_automation@ciq.com>

jira VULN-241 cve CVE-2022-48627 commit-author Yangxi Xiang <xyangxi5@gmail.com> commit 39cdb68 A memory overlapping copy occurs when deleting a long line. This memory overlapping copy can cause data corruption when scr_memcpyw is optimized to memcpy because memcpy does not ensure its behavior if the destination buffer overlaps with the source buffer. The line buffer is not always broken, because the memcpy utilizes the hardware acceleration, whose result is not deterministic. Fix this problem by using replacing the scr_memcpyw with scr_memmovew. Fixes: 81732c3 ("tty vt: Fix line garbage in virtual console on command line edition") Cc: stable <stable@kernel.org> Signed-off-by: Yangxi Xiang <xyangxi5@gmail.com> Link: https://lore.kernel.org/r/20220628093322.5688-1-xyangxi5@gmail.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> (cherry picked from commit 39cdb68) Signed-off-by: CIQ Kernel Automation <ciq_kernel_automation@ciq.com>

github-actions · 2026-04-27T10:47:19Z

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

github-actions · 2026-04-27T10:47:20Z

🔍 Upstream Linux Kernel Commit Check

❗ PR commit 53218221ee7 (tty: Fix out-of-bound vmalloc access in imageblit) references upstream commit
3b0c40612471 which does not exist in the upstream Linux kernel.

This is an automated message from the kernel commit checker workflow.

github-actions · 2026-04-27T10:47:21Z

🔍 Interdiff Analysis

❌ PR commit 53218221ee7 (tty: Fix out-of-bound vmalloc access in imageblit) → 3b0c40612471
Error: Failed to generate patch for upstream commit: Git command failed: format-patch -1 --stdout 3b0c406
fatal: bad object 3b0c406

This is an automated interdiff check for backported commits.

github-actions · 2026-04-27T10:48:39Z

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

bmastbergen · 2026-04-27T14:55:54Z

🔍 Upstream Linux Kernel Commit Check

❗ PR commit 53218221ee7 (tty: Fix out-of-bound vmalloc access in imageblit) references upstream commit
3b0c40612471 which does not exist in the upstream Linux kernel.

This is an automated message from the kernel commit checker workflow.

This is weird. 3b0c40612471 is an upstream commit and has existed for years. I wonder why check_kernel_commits.py couldn't find it. Looks like the interdiff step couldn't either.

shreeya-patel98 · 2026-04-28T15:42:00Z

🔍 Upstream Linux Kernel Commit Check

❗ PR commit 53218221ee7 (tty: Fix out-of-bound vmalloc access in imageblit) references upstream commit
3b0c40612471 which does not exist in the upstream Linux kernel.

This is an automated message from the kernel commit checker workflow.

This is weird. 3b0c40612471 is an upstream commit and has existed for years. I wonder why check_kernel_commits.py couldn't find it. Looks like the interdiff step couldn't either.

Another thing is that this PR and automation shouldn't be created if there is any issue or even a false positive found by check_kernel_commits

These CVE automation should mostly be the CVEs which pass all our initial checks. Yes it is still possible that it will fail the build or kABI but that's a different thing.

github-actions · 2026-04-28T15:47:39Z

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

github-actions · 2026-04-28T15:47:40Z

🔍 Upstream Linux Kernel Commit Check

❗ PR commit 53218221ee7 (tty: Fix out-of-bound vmalloc access in imageblit) references upstream commit
3b0c40612471 which does not exist in the upstream Linux kernel.

This is an automated message from the kernel commit checker workflow.

github-actions · 2026-04-28T15:47:41Z

🔍 Interdiff Analysis

❌ PR commit 53218221ee7 (tty: Fix out-of-bound vmalloc access in imageblit) → 3b0c40612471
Error: Failed to generate patch for upstream commit: Git command failed: format-patch -1 --stdout 3b0c406
fatal: bad object 3b0c406

This is an automated interdiff check for backported commits.

github-actions · 2026-04-28T15:49:00Z

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

roxanan1996 · 2026-04-29T08:14:34Z

🔍 Upstream Linux Kernel Commit Check

❗ PR commit 53218221ee7 (tty: Fix out-of-bound vmalloc access in imageblit) references upstream commit
3b0c40612471 which does not exist in the upstream Linux kernel.

This is an automated message from the kernel commit checker workflow.

This is weird. 3b0c40612471 is an upstream commit and has existed for years. I wonder why check_kernel_commits.py couldn't find it. Looks like the interdiff step couldn't either.

Another thing is that this PR and automation shouldn't be created if there is any issue or even a false positive found by check_kernel_commits

These CVE automation should mostly be the CVEs which pass all our initial checks. Yes it is still possible that it will fail the build or kABI but that's a different thing.

@shreeya-patel98 This is solved here but it was not merged yet
https://github.com/ctrliq/kernel-tools/pull/96

But these failure happens only here because of the shallow clone. In the GHA it does not because there I do a full clone. So, sometimes we may run into issues like this

roxanan1996 · 2026-04-29T11:36:35Z

I ran these locally and no issues were found.
I suggest to merge this and not wait for the shallow clone fix from Sultan.


❯ python3 ~/ciq/kernel-src-tree-tools/check_kernel_commits.py --repo . --pr_branch {ciq_kernel_automation}_ciqlts9_2 --base_branch origin/ciqlts9_2 --check-cves
All referenced commits exist upstream and have no Fixes: tags.


❯ python3 ~/ciq/kernel-src-tree-tools/run_interdiff.py --repo . --pr_branch {ciq_kernel_automation}_ciqlts9_2 --base_branch origin/ciqlts9_2
All backported commits match their upstream counterparts.

❯ python3 ~/ciq/kernel-src-tree-tools/jira_pr_check.py --kernel-src-tree .  --merge-target ciqlts9_2 --pr-branch {ciq_kernel_automation}_ciqlts9_2

## JIRA PR Check Results

✅ **No issues found!**


---
**Summary:** Checked 8 commit(s) total.

bmastbergen

🥌

CIQ Kernel Automation added 8 commits April 27, 2026 07:09

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 Apr 27, 2026

shreeya-patel98 approved these changes Apr 27, 2026

View reviewed changes

shreeya-patel98 requested a review from a team April 27, 2026 14:31

shreeya-patel98 self-requested a review April 28, 2026 15:42

shreeya-patel98 mentioned this pull request Apr 28, 2026

[ciqlts8_6] Multiple patches tested (10 commits) #1151

Merged

roxanan1996 approved these changes Apr 29, 2026

View reviewed changes

bmastbergen approved these changes Apr 29, 2026

View reviewed changes

roxanan1996 merged commit b2740b4 into ciqlts9_2 Apr 29, 2026
6 checks passed

Uh oh!

Conversation

ciq-kernel-automation Bot commented Apr 27, 2026

Summary

Commit Message(s)

Test Results

✅ Build Stage

✅ Boot Verification

✅ Kernel Selftests

✅ LTP Results

Uh oh!

github-actions Bot commented Apr 27, 2026

Uh oh!

github-actions Bot commented Apr 27, 2026

🔍 Upstream Linux Kernel Commit Check

Uh oh!

github-actions Bot commented Apr 27, 2026

🔍 Interdiff Analysis

Uh oh!

github-actions Bot commented Apr 27, 2026

Uh oh!

bmastbergen commented Apr 27, 2026

🔍 Upstream Linux Kernel Commit Check

Uh oh!

shreeya-patel98 commented Apr 28, 2026

🔍 Upstream Linux Kernel Commit Check

Uh oh!

github-actions Bot commented Apr 28, 2026

Uh oh!

github-actions Bot commented Apr 28, 2026

🔍 Upstream Linux Kernel Commit Check

Uh oh!

github-actions Bot commented Apr 28, 2026

🔍 Interdiff Analysis

Uh oh!

github-actions Bot commented Apr 28, 2026

Uh oh!

roxanan1996 commented Apr 29, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

🔍 Upstream Linux Kernel Commit Check

Uh oh!

roxanan1996 commented Apr 29, 2026

Uh oh!

bmastbergen left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Milestone

Development

Uh oh!

3 participants

roxanan1996 commented Apr 29, 2026 •

edited

Loading