This project is mirrored from https://gitlab.com/redhat/centos-stream/src/kernel/centos-stream-10.git.
Pull mirroring updated .
- Mar 13, 2025
-
-
Julio Faracco authored
Signed-off-by:Julio Faracco <jfaracco@redhat.com>
-
Julio Faracco authored
MR: https://gitlab.com/redhat/centos-stream/src/kernel/centos-stream-10/-/merge_requests/397 JIRA: https://issues.redhat.com/browse/RHEL-77309 JIRA: https://issues.redhat.com/browse/RHEL-81387 JIRA: https://issues.redhat.com/browse/RHEL-77180 CVE: CVE-2024-58004 Update media to the upstream 6.13. This update includes the IPU6 driver fixes and fixed the IPU6 driver crash on boot issue. Omitted-fix: d01e5a4d866d70de11e957c11a4f3b54b996137c (media: test-drivers: drop vb2_ops_wait_prepare/finish) isn't supported in RHEL Omitted-fix: 3576f817c5ee730a4567aff445f0f853a8adf53a (staging: media: drop vb2_ops_wait_prepare/finish) isn't supported in RHEL Omitted-fix: d020ca11a816a99f87f2d186e137a9fb2341adb3 (media: samples: v4l2-pci-skeleton.c: drop vb2_ops_wait_prepare/finish) isn't supported in RHEL The upstream commit <1d4a00028997> ( media: ipu6: use the IPU6 DMA mapping APIs to do mapping) replace the VIDEOBUF2_DMA_CONTIG with VIDEOBUF2_DMA_SG, so the CKI test reported videobuf2-dma-contig.ko not found error. Signed-off-by:
Kate Hsuan <hpa@redhat.com> Approved-by:
Mark Langsdorf <mlangsdo@redhat.com> Approved-by:
Eric Chanudet <echanude@redhat.com> Approved-by:
CKI KWF Bot <cki-ci-bot+kwf-gitlab-com@redhat.com> Merged-by:
-
Julio Faracco authored
MR: https://gitlab.com/redhat/centos-stream/src/kernel/centos-stream-10/-/merge_requests/389 JIRA: https://issues.redhat.com/browse/RHEL-78341 Upstream Status: RHEL only The PKEY related config options should be disabled for zfcpdump config. Related kernel ark MRs; https://gitlab.com/cki-project/kernel-ark/-/merge_requests/3698 https://gitlab.com/cki-project/kernel-ark/-/merge_requests/3721 Signed-off-by:
Mete Durlu <mdurlu@redhat.com> Approved-by:
Vladis Dronov <vdronov@redhat.com> Approved-by:
Steve Best <sbest@redhat.com> Approved-by:
-
Julio Faracco authored
MR: https://gitlab.com/redhat/centos-stream/src/kernel/centos-stream-10/-/merge_requests/512 This rebases MANA hyperv driver to upstream kernel 6.14-rc5 JIRA: https://issues.redhat.com/browse/RHEL-80097 Tested: Smoke tested on an azure VM. Signed-off-by:
Maxim Levitsky <mlevitsk@redhat.com> Approved-by:
Kamal Heib <kheib@redhat.com> Approved-by:
Cathy Avery <cavery@redhat.com> Approved-by:
Vitaly Kuznetsov <vkuznets@redhat.com> Merged-by:
-
- Mar 11, 2025
-
-
Julio Faracco authored
Signed-off-by: -
Julio Faracco authored
MR: https://gitlab.com/redhat/centos-stream/src/kernel/centos-stream-10/-/merge_requests/513 JIRA: https://issues.redhat.com/browse/RHEL-73721 Upstream Status: All commits are found in Linus's git tree. Brew: https://brewweb.engineering.redhat.com/brew/taskinfo?taskID=66873040 Signed-off-by:
Nigel Croxon <ncroxon@redhat.com> Approved-by:
Heinz Mauelshagen <heinzm@redhat.com> Approved-by:
Xiao Ni <xni@redhat.com> Approved-by:
-
- Mar 10, 2025
-
-
Julio Faracco authored
Signed-off-by: -
Julio Faracco authored
MR: https://gitlab.com/redhat/centos-stream/src/kernel/centos-stream-10/-/merge_requests/504 JIRA: https://issues.redhat.com/browse/RHEL-81936 Commits: ``` dc287e4c9149ab54a5003b4d4da007818b5fda3d 05793884a1f30509e477de9da233ab73584b1c8c 2844ddbd540fc84d7571cca65d6c43088e4d6952 ``` Signed-off-by:
-
Julio Faracco authored
MR: https://gitlab.com/redhat/centos-stream/src/kernel/centos-stream-10/-/merge_requests/407 JIRA: https://issues.redhat.com/browse/RHEL-80379 Upstream Status: net-next.git commit 0f58804080e3 Signed-off-by:
Hangbin Liu <haliu@redhat.com> Approved-by:
Davide Caratti <dcaratti@redhat.com> Approved-by:
Florian Westphal <fwestpha@redhat.com> Merged-by:
-
Julio Faracco authored
MR: https://gitlab.com/redhat/centos-stream/src/kernel/centos-stream-10/-/merge_requests/239 JIRA: https://issues.redhat.com/browse/RHEL-75660 CVE: CVE-2024-57941 ``` netfs: Fix the (non-)cancellation of copy when cache is temporarily disabled When the caching for a cookie is temporarily disabled (e.g. due to a DIO write on that file), future copying to the cache for that file is disabled until all fds open on that file are closed. However, if netfslib is using the deprecated PG_private_2 method (such as is currently used by ceph), and decides it wants to copy to the cache, netfs_advance_write() will just bail at the first check seeing that the cache stream is unavailable, and indicate that it dealt with all the content. This means that we have no subrequests to provide notifications to drive the state machine or even to pin the request and the request just gets discarded, leaving the folios with PG_private_2 set. Fix this by jumping directly to cancel the request if the cache is not available. That way, we don't remove mark3 from the folio_queue list and netfs_pgpriv2_cancel() will clean up the folios. This was found by running the generic/013 xfstest against ceph with an active cache and the "-o fsc" option passed to ceph. That would usually hang Fixes: ee4cdf7b ("netfs: Speed up buffered reading") Reported-by:
Max Kellermann <max.kellermann@ionos.com> Closes: https://lore.kernel.org/r/CAKPOu+_4m80thNy5_fvROoxBm689YtA0dZ-=gcmkzwYSY4syqw@mail.gmail.com/ Signed-off-by:
David Howells <dhowells@redhat.com> Link: https://lore.kernel.org/r/20241213135013.2964079-11-dhowells@redhat.com cc: Jeff Layton <jlayton@kernel.org> cc: Ilya Dryomov <idryomov@gmail.com> cc: Xiubo Li <xiubli@redhat.com> cc: netfs@lists.linux.dev cc: ceph-devel@vger.kernel.org cc: linux-fsdevel@vger.kernel.org Signed-off-by:
Christian Brauner <brauner@kernel.org> (cherry picked from commit d0327c824338cdccad058723a31d038ecd553409) ``` Signed-off-by:
CKI Backport Bot <cki-ci-bot+cki-gitlab-backport-bot@redhat.com> --- <small>Created 2025-01-21 17:11 UTC by backporter - [KWF FAQ](https://red.ht/kernel_workflow_doc) - [Slack #team-kernel-workflow](https://redhat-internal.slack.com/archives/C04LRUPMJQ5) - [Source](https://gitlab.com/cki-project/kernel-workflow/-/blob/main/webhook/utils/backporter.py) - [Documentation](https://gitlab.com/cki-project/kernel-workflow/-/blob/main/docs/README.backporter.md) - [Report an issue](https://gitlab.com/cki-project/kernel-workflow/-/issues/new?issue%5Btitle%5D=backporter%20webhook%20issue)</small > Approved-by:
Paulo Alcantara <paalcant@redhat.com> Approved-by:
Benjamin Coddington <bcodding@redhat.com> Approved-by:
Alex Markuze <amarkuze@redhat.com> Merged-by:
-
Julio Faracco authored
MR: https://gitlab.com/redhat/centos-stream/src/kernel/centos-stream-10/-/merge_requests/238 JIRA: https://issues.redhat.com/browse/RHEL-75655 CVE: CVE-2024-57942 ``` netfs: Fix ceph copy to cache on write-begin At the end of netfs_unlock_read_folio() in which folios are marked appropriately for copying to the cache (either with by being marked dirty and having their private data set or by having PG_private_2 set) and then unlocked, the folio_queue struct has the entry pointing to the folio cleared. This presents a problem for netfs_pgpriv2_write_to_the_cache(), which is used to write folios marked with PG_private_2 to the cache as it expects to be able to trawl the folio_queue list thereafter to find the relevant folios, leading to a hang. Fix this by not clearing the folio_queue entry if we're going to do the deprecated copy-to-cache. The clearance will be done instead as the folios are written to the cache. This can be reproduced by starting cachefiles, mounting a ceph filesystem with "-o fsc" and writing to it. Fixes: 796a4049 ("netfs: In readahead, put the folio refs as soon extracted") Reported-by:
-
Jan Stancek authored
JIRA: INTERNAL Upstream Status: RHEL only Don't bring in changes from Makefile.rhelver. Signed-off-by:Jan Stancek <jstancek@redhat.com>
-
- Mar 07, 2025
-
-
Julio Faracco authored
Signed-off-by: -
Julio Faracco authored
MR: https://gitlab.com/redhat/centos-stream/src/kernel/centos-stream-10/-/merge_requests/190 JIRA: https://issues.redhat.com/browse/RHEL-80305 CVE: CVE-2024-57902 ``` af_packet: fix vlan_get_tci() vs MSG_PEEK Blamed commit forgot MSG_PEEK case, allowing a crash [1] as found by syzbot. Rework vlan_get_tci() to not touch skb at all, so that it can be used from many cpus on the same skb. Add a const qualifier to skb argument. [1] skbuff: skb_under_panic: text:ffffffff8a8da482 len:32 put:14 head:ffff88807a1d5800 data:ffff88807a1d5810 tail:0x14 end:0x140 dev:<NULL> ------------[ cut here ]------------ kernel BUG at net/core/skbuff.c:206 ! Oops: invalid opcode: 0000 [#1] PREEMPT SMP KASAN PTI CPU: 0 UID: 0 PID: 5880 Comm: syz-executor172 Not tainted 6.13.0-rc3-syzkaller-00762-g9268abe611b0 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/13/2024 RIP: 0010:skb_panic net/core/skbuff.c:206 [inline] RIP: 0010:skb_under_panic+0x14b/0x150 net/core/skbuff.c:216 Code: 0b 8d 48 c7 c6 9e 6c 26 8e 48 8b 54 24 08 8b 0c 24 44 8b 44 24 04 4d 89 e9 50 41 54 41 57 41 56 e8 3a 5a 79 f7 48 83 c4 20 90 <0f> 0b 0f 1f 00 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 f3 RSP: 0018:ffffc90003baf5b8 EFLAGS: 00010286 RAX: 0000000000000087 RBX: dffffc0000000000 RCX: 8565c1eec37aa000 RDX: 0000000000000000 RSI: 0000000080000000 RDI: 0000000000000000 RBP: ffff88802616fb50 R08: ffffffff817f0a4c R09: 1ffff92000775e50 R10: dffffc0000000000 R11: fffff52000775e51 R12: 0000000000000140 R13: ffff88807a1d5800 R14: ffff88807a1d5810 R15: 0000000000000014 FS: 00007fa03261f6c0(0000) GS:ffff8880b8600000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007ffd65753000 CR3: 0000000031720000 CR4: 00000000003526f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: <TASK> skb_push+0xe5/0x100 net/core/skbuff.c:2636 vlan_get_tci+0x272/0x550 net/packet/af_packet.c:565 packet_recvmsg+0x13c9/0x1ef0 net/packet/af_packet.c:3616 sock_recvmsg_nosec net/socket.c:1044 [inline] sock_recvmsg+0x22f/0x280 net/socket.c:1066 ____sys_recvmsg+0x1c6/0x480 net/socket.c:2814 ___sys_recvmsg net/socket.c:2856 [inline] do_recvmmsg+0x426/0xab0 net/socket.c:2951 __sys_recvmmsg net/socket.c:3025 [inline] __do_sys_recvmmsg net/socket.c:3048 [inline] __se_sys_recvmmsg net/socket.c:3041 [inline] __x64_sys_recvmmsg+0x199/0x250 net/socket.c:3041 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83 Fixes: 79eecf63 ("af_packet: Handle outgoing VLAN packets without hardware offloading") Reported-by:
<syzbot+8400677f3fd43f37d3bc@syzkaller.appspotmail.com> Closes: https://lore.kernel.org/netdev/6772c485.050a0220.2f3838.04c6.GAE@google.com/T/#u Signed-off-by:
Eric Dumazet <edumazet@google.com> Cc: Chengen Du <chengen.du@canonical.com> Reviewed-by:
Willem de Bruijn <willemb@google.com> Link: https://patch.msgid.link/20241230161004.2681892-1-edumazet@google.com Signed-off-by:
Jakub Kicinski <kuba@kernel.org> (cherry picked from commit 77ee7a6d16b6ec07b5c3ae2b6b60a24c1afbed09) ``` Signed-off-by:
Xin Long <lxin@redhat.com> Merged-by:
-
Julio Faracco authored
MR: https://gitlab.com/redhat/centos-stream/src/kernel/centos-stream-10/-/merge_requests/412 JIRA: https://issues.redhat.com/browse/RHEL-80534 Signed-off-by:
Scott Mayhew <smayhew@redhat.com> Approved-by:
Jay Shin <jaeshin@redhat.com> Merged-by:
-
Julio Faracco authored
MR: https://gitlab.com/redhat/centos-stream/src/kernel/centos-stream-10/-/merge_requests/470 JIRA: https://issues.redhat.com/browse/RHEL-81482 CVE: CVE-2025-21771 ``` commit d6f3e7d564b2309e1f17e709a70eca78d7ca2bb8 Author: Tejun Heo <tj@kernel.org> Date: Fri Jan 24 12:22:12 2025 -1000 sched_ext: Fix incorrect autogroup migration detection scx_move_task() is called from sched_move_task() and tells the BPF scheduler that cgroup migration is being committed. sched_move_task() is used by both cgroup and autogroup migrations and scx_move_task() tried to filter out autogroup migrations by testing the destination cgroup and PF_EXITING but this is not enough. In fact, without explicitly tagging the thread which is doing the cgroup migration, there is no good way to tell apart scx_move_task() invocations for racing migration to the root cgroup and an autogroup migration. This led to scx_move_task() incorrectly ignoring a migration from non-root cgroup to an autogroup of the root cgroup triggering the following warning: WARNING: CPU: 7 PID: 1 at kernel/sched/ext.c:3725 scx_cgroup_can_attach+0x196/0x340 ... Call Trace: <TASK> cgroup_migrate_execute+0x5b1/0x700 cgroup_attach_task+0x296/0x400 __cgroup_procs_write+0x128/0x140 cgroup_procs_write+0x17/0x30 kernfs_fop_write_iter+0x141/0x1f0 vfs_write+0x31d/0x4a0 __x64_sys_write+0x72/0xf0 do_syscall_64+0x82/0x160 entry_SYSCALL_64_after_hwframe+0x76/0x7e Fix it by adding an argument to sched_move_task() that indicates whether the moving is for a cgroup or autogroup migration. After the change, scx_move_task() is called only for cgroup migrations and renamed to scx_cgroup_move_task(). Link: https://github.com/sched-ext/scx/issues/370 Fixes: 81951366 ("sched_ext: Add cgroup support") Cc: stable@vger.kernel.org # v6.12+ Acked-by:
Peter Zijlstra (Intel) <peterz@infradead.org> Signed-off-by:
Tejun Heo <tj@kernel.org>```> Signed-off-by:
Phil Auld <pauld@redhat.com> Merged-by:
-
Julio Faracco authored
MR: https://gitlab.com/redhat/centos-stream/src/kernel/centos-stream-10/-/merge_requests/395 ``` JIRA: https://issues.redhat.com/browse/RHEL-47437 Add new VMD Device ID and while at it, include a VMD related bug fix. Signed-off-by:
Myron Stowe <mstowe@redhat.com> ``` Approved-by:
David Arcari <darcari@redhat.com> Approved-by:
John W. Linville <linville@redhat.com> Approved-by:
Jiri Dluhos <jdluhos@redhat.com> Merged-by:
-
Julio Faracco authored
MR: https://gitlab.com/redhat/centos-stream/src/kernel/centos-stream-10/-/merge_requests/427 JIRA: https://issues.redhat.com/browse/RHEL-80626 Upstream Status: ARK commit bc86c1c47085637adec8627f507a9130211f5178 commit bc86c1c47085637adec8627f507a9130211f5178 Author: Jan Stancek <jstancek@redhat.com> Date: Tue Feb 25 03:59:52 2025 -0500 kernel.spec: add missing tools-libs on s390x tools-libs-devel requires tools-libs. Previously on s390x they would be both skipped by %cpupowerarches check. But after adding ynl headers and library to tools-libs-devel, it is now built also on s390x. But tools-libs is still skipped and creates a missing dependency. We could conditionally skip the Requires on s390x, but that adds extra burden to keep such condition up to date as more artefacts get introduced to tools-libs-devel in future. Simplest is to just create tools-libs on s390x, even if it ends up empty for now. Fixes: e9f967afa161 ("redhat: kernel.spec: add ynl to kernel-tools") Reported-by:
Bruno Goncalves <bgoncalv@redhat.com> Signed-off-by:
Daniel Horak <dhorak@redhat.com> Approved-by:
Scott Weaver <scweaver@redhat.com> Merged-by:
-
Julio Faracco authored
MR: https://gitlab.com/redhat/centos-stream/src/kernel/centos-stream-10/-/merge_requests/489 JIRA: https://issues.redhat.com/browse/RHEL-81669 CVE: CVE-2025-21785 ``` commit 875d742cf5327c93cba1f11e12b08d3cce7a88d2 Author: Radu Rendec <rrendec@redhat.com> Date: Thu Feb 6 12:44:20 2025 -0500 arm64: cacheinfo: Avoid out-of-bounds write to cacheinfo array The loop that detects/populates cache information already has a bounds check on the array size but does not account for cache levels with separate data/instructions cache. Fix this by incrementing the index for any populated leaf (instead of any populated level). Fixes: 5d425c18 ("arm64: kernel: add support for cpu cache information") Signed-off-by:
Radu Rendec <rrendec@redhat.com> Link: https://lore.kernel.org/r/20250206174420.2178724-1-rrendec@redhat.com Signed-off-by:
Will Deacon <will@kernel.org>```> Signed-off-by:
-
Julio Faracco authored
MR: https://gitlab.com/redhat/centos-stream/src/kernel/centos-stream-10/-/merge_requests/414 JIRA: https://issues.redhat.com/browse/RHEL-76749 Build Info: https://brewweb.engineering.redhat.com/brew/taskinfo?taskID=66787277 Tested: Verified Brew build test kernel RPMs Signed-off-by:
Mamatha Inamdar <minamdar@redhat.com> commit 6efbd5ddb6af0408301b4c15b413e6425c7650b2 Author: Sourabh Jain <sourabhjain@linux.ibm.com> Date: Sat Sep 21 16:07:45 2024 +0530 kexec/crash: no crash update when kexec in progress The following errors are observed when kexec is done with SMT=off on powerpc. [ 358.458385] Removing IBM Power 842 compression device [ 374.795734] kexec_core: Starting new kernel [ 374.795748] kexec: Waking offline cpu 1. [ 374.875695] crash hp: kexec_trylock() failed, elfcorehdr may be inaccurate [ 374.935833] kexec: Waking offline cpu 2. [ 375.015664] crash hp: kexec_trylock() failed, elfcorehdr may be inaccurate snip.. [ 375.515823] kexec: Waking offline cpu 6. [ 375.635667] crash hp: kexec_trylock() failed, elfcorehdr may be inaccurate [ 375.695836] kexec: Waking offline cpu 7. To avoid kexec kernel boot failure on PowerPC, all the present CPUs that are offline are brought online during kexec. For more information, refer to commit e8e5c215 ("powerpc/kexec: Fix orphaned offline CPUs across kexec"). Bringing the CPUs online triggers the crash hotplug handler, crash_handle_hotplug_event(), to update the kdump image. Since the system is on the kexec kernel boot path and the kexec lock is held, the crash_handle_hotplug_event() function fails to acquire the same lock to update the kdump image, resulting in the error messages mentioned above. To fix this, return from crash_handle_hotplug_event() without printing the error message if kexec is in progress. The same applies to the crash_check_hotplug_support() function. Return 0 if kexec is in progress because kernel is not in a position to update the kdump image. Link: https://lkml.kernel.org/r/20240921103745.560430-1-sourabhjain@linux.ibm.com Signed-off-by:
Sourabh Jain <sourabhjain@linux.ibm.com> Acked-by:
Baoquan he <bhe@redhat.com> Reported-by:
Sachin P Bappalige <sachinpb@linux.vnet.ibm.com> Cc: Hari Bathini <hbathini@linux.ibm.com> Cc: Michael Ellerman <mpe@ellerman.id.au> Signed-off-by:
Andrew Morton <akpm@linux-foundation.org> Signed-off-by:
Desnes Nunes <desnesn@redhat.com> Approved-by:
Baoquan He <5820488-baoquan_he@users.noreply.gitlab.com> Merged-by:
-
Julio Faracco authored
MR: https://gitlab.com/redhat/centos-stream/src/kernel/centos-stream-10/-/merge_requests/481 JIRA: https://issues.redhat.com/browse/RHEL-81540 CVE: CVE-2025-21712 ``` commit 8d28d0ddb986f56920ac97ae704cc3340a699a30 Author: Yu Kuai <yukuai3@huawei.com> Date: Fri Jan 24 17:20:55 2025 +0800 md/md-bitmap: Synchronize bitmap_get_stats() with bitmap lifetime After commit ec6bb299 ("md/md-bitmap: add 'sync_size' into struct md_bitmap_stats"), following panic is reported: Oops: general protection fault, probably for non-canonical address RIP: 0010:bitmap_get_stats+0x2b/0xa0 Call Trace: <TASK> md_seq_show+0x2d2/0x5b0 seq_read_iter+0x2b9/0x470 seq_read+0x12f/0x180 proc_reg_read+0x57/0xb0 vfs_read+0xf6/0x380 ksys_read+0x6c/0xf0 do_syscall_64+0x82/0x170 entry_SYSCALL_64_after_hwframe+0x76/0x7e Root cause is that bitmap_get_stats() can be called at anytime if mddev is still there, even if bitmap is destroyed, or not fully initialized. Deferenceing bitmap in this case can crash the kernel. Meanwhile, the above commit start to deferencing bitmap->storage, make the problem easier to trigger. Fix the problem by protecting bitmap_get_stats() with bitmap_info.mutex. Cc: stable@vger.kernel.org # v6.12+ Fixes: 32a7627c ("[PATCH] md: optimised resync using Bitmap based intent logging") Reported-and-tested-by:
Harshit Mogalapalli <harshit.m.mogalapalli@oracle.com> Closes: https://lore.kernel.org/linux-raid/ca3a91a2-50ae-4f68-b317-abd9889f3907@oracle.com/T/#m6e5086c95201135e4941fe38f9efa76daf9666c5 Signed-off-by:
Yu Kuai <yukuai3@huawei.com> Link: https://lore.kernel.org/r/20250124092055.4050195-1-yukuai1@huaweicloud.com Signed-off-by:
Song Liu <song@kernel.org>```> Signed-off-by:
-
Julio Faracco authored
MR: https://gitlab.com/redhat/centos-stream/src/kernel/centos-stream-10/-/merge_requests/513 JIRA: https://issues.redhat.com/browse/RHEL-73721 Upstream Status: All commits are found in Linus's git tree. Brew: https://brewweb.engineering.redhat.com/brew/taskinfo?taskID=66873040 Signed-off-by:
-
Jan Stancek authored
Signed-off-by: -
Jan Stancek authored
MR: https://gitlab.com/redhat/rhel/src/kernel/rhel-10/-/merge_requests/14 JIRA: https://issues.redhat.com/browse/RHEL-79457 This MR contains a number of bug fixes that impact firmware loading and good operation on Mediatek USB Bluetooth adapters. CVE: CVE-2024-56653 CVE: CVE-2024-53238 CVE: CVE-2024-56757 Signed-off-by:
Bastien Nocera <bnocera@redhat.com> Closes RHEL-79457 Approved-by:
David Marlin <dmarlin@redhat.com> Approved-by:
-
Jan Stancek authored
MR: https://gitlab.com/redhat/rhel/src/kernel/rhel-10/-/merge_requests/5 JIRA: https://issues.redhat.com/browse/RHEL-76090 CVE: CVE-2024-56623 Upstream Status: From upstream linux mainline System crash is observed with stack trace warning of use after free. There are 2 signals to tell dpc_thread to terminate (UNLOADING flag and kthread_stop). On setting the UNLOADING flag when dpc_thread happens to run at the time and sees the flag, this causes dpc_thread to exit and clean up itself. When kthread_stop is called for final cleanup, this causes use after free. Remove UNLOADING signal to terminate dpc_thread. Use the kthread_stop as the main signal to exit dpc_thread. [596663.812935] kernel BUG at mm/slub.c:294! [596663.812950] invalid opcode: 0000 [#1] SMP PTI [596663.812957] CPU: 13 PID: 1475935 Comm: rmmod Kdump: loaded Tainted: G IOE --------- - - 4.18.0-240.el8.x86_64 #1 [596663.812960] Hardware name: HP ProLiant DL380p Gen8, BIOS P70 08/20/2012 [596663.812974] RIP: 0010:__slab_free+0x17d/0x360 ... [596663.813008] Call Trace: [596663.813022] ? __dentry_kill+0x121/0x170 [596663.813030] ? _cond_resched+0x15/0x30 [596663.813034] ? _cond_resched+0x15/0x30 [596663.813039] ? wait_for_completion+0x35/0x190 [596663.813048] ? try_to_wake_up+0x63/0x540 [596663.813055] free_task+0x5a/0x60 [596663.813061] kthread_stop+0xf3/0x100 [596663.813103] qla2x00_remove_one+0x284/0x440 [qla2xxx] Cc: stable@vger.kernel.org Signed-off-by:
Quinn Tran <qutran@marvell.com> Signed-off-by:
Nilesh Javali <njavali@marvell.com> Link: https://lore.kernel.org/r/20241115130313.46826-3-njavali@marvell.com Reviewed-by:
Himanshu Madhani <himanshu.madhani@oracle.com> Signed-off-by:
Martin K. Petersen <martin.petersen@oracle.com> (cherry picked from commit 07c903db0a2ff84b68efa1a74a4de353ea591eb0) Signed-off-by:
Ewan D. Milne <emilne@redhat.com> Closes RHEL-76090 Approved-by:
Chris Leech <cleech@redhat.com> Approved-by:
John Meneghini <jmeneghi@redhat.com> Approved-by:
-
Jan Stancek authored
MR: https://gitlab.com/redhat/rhel/src/kernel/rhel-10/-/merge_requests/4 JIRA: https://issues.redhat.com/browse/RHEL-76089 Upstream Status: From upstream linux mainline CVE: CVE-2024-56631 Conflicts: Merge differences due to lack of commit 4045de893f69 ("scsi: sg: Enable runtime power management") Fix a use-after-free bug in sg_release(), detected by syzbot with KASAN: BUG: KASAN: slab-use-after-free in lock_release+0x151/0xa30 kernel/locking/lockdep.c:5838 __mutex_unlock_slowpath+0xe2/0x750 kernel/locking/mutex.c:912 sg_release+0x1f4/0x2e0 drivers/scsi/sg.c:407 In sg_release(), the function kref_put(&sfp->f_ref, sg_remove_sfp) is called before releasing the open_rel_lock mutex. The kref_put() call may decrement the reference count of sfp to zero, triggering its cleanup through sg_remove_sfp(). This cleanup includes scheduling deferred work via sg_remove_sfp_usercontext(), which ultimately frees sfp. After kref_put(), sg_release() continues to unlock open_rel_lock and may reference sfp or sdp. If sfp has already been freed, this results in a slab-use-after-free error. Move the kref_put(&sfp->f_ref, sg_remove_sfp) call after unlocking the open_rel_lock mutex. This ensures: - No references to sfp or sdp occur after the reference count is decremented. - Cleanup functions such as sg_remove_sfp() and sg_remove_sfp_usercontext() can safely execute without impacting the mutex handling in sg_release(). The fix has been tested and validated by syzbot. This patch closes the bug reported at the following syzkaller link and ensures proper sequencing of resource cleanup and mutex operations, eliminating the risk of use-after-free errors in sg_release(). Reported-by:
<syzbot+7efb5850a17ba6ce098b@syzkaller.appspotmail.com> Closes: https://syzkaller.appspot.com/bug?extid=7efb5850a17ba6ce098b Tested-by:
Suraj Sonawane <surajsonawane0215@gmail.com> Link: https://lore.kernel.org/r/20241120125944.88095-1-surajsonawane0215@gmail.com Reviewed-by:
Bart Van Assche <bvanassche@acm.org> Signed-off-by:
-
Jan Stancek authored
MR: https://gitlab.com/redhat/rhel/src/kernel/rhel-10/-/merge_requests/13 JIRA: https://issues.redhat.com/browse/RHEL-78975 CVE: CVE-2025-1272 Upstream Status: RHEL-only Restore the functionality of the lockdown LSM routines in the architecture-specific setup_arch() routines for x86, s390, powerpc, and arm64. Calls to the LSM lockdown routines security_lock_kernel_down() and security_locked_down() are ineffective prior to a call to early_security_init(). And commit 77b644c3 ("init/main.c: Initialize early LSMs after arch code, static keys and calls") moved the call to early_security_init() in start_kernel() from before the call to setup_arch() to after it. Secondly, even if lock_kernel_down() is called directly, e.g. via the kernel parameter lockdown, or CONFIG_LOCK_DOWN_KERNEL_FORCE_*, security_locked_down() will return false until early_security_init() is called. An example of such an early call occurs in acpi_table_upgrade() if CONFIG_ACPI_TABLE_UPGRADE is enabled. Fix this by calling early_security_init() in the arch-specifc setup_arch() routines that depend on early enablement of the lockdown LSM. First, make it safe to call early_security_init() more than once. All subsequent calls do nothing. Then add a call to early_security_init() into the x86, s390, powerpc, and arm64 versions of setup_arch(). Both static_call_init() and jump_table_init() are prerequisites for early_security_init(). So add or move them accordingly. All three of these routines can be safely called more than once. Tested: Kernel lockdown tested on x86_64, s390x, ppc64le, and arm64. Fixes: 77b644c3 ("init/main.c: Initialize early LSMs after arch code, static keys and calls") v2: - Added arm64 setup_arch() because it calls acpi_table_upgrade() Signed-off-by:
Lenny Szubowicz <lszubowi@redhat.com> Approved-by:
Ondrej Mosnáček <omosnacek@gmail.com> Approved-by:
-
Jan Stancek authored
JIRA: INTERNAL Upstream Status: RHEL only Don't bring in changes from Makefile.rhelver. Signed-off-by:
-
- Mar 06, 2025
-
-
Jan Stancek authored
Signed-off-by: -
Jan Stancek authored
MR: https://gitlab.com/redhat/rhel/src/kernel/rhel-10/-/merge_requests/28 JIRA: https://issues.redhat.com/browse/RHEL-41204 Signed-off-by:
Benjamin Poirier <bpoirier@redhat.com> Approved-by:
Michal Schmidt <mschmidt@redhat.com> Approved-by:
-
Jan Stancek authored
MR: https://gitlab.com/redhat/rhel/src/kernel/rhel-10/-/merge_requests/20 JIRA: https://issues.redhat.com/browse/RHEL-71568 commit 56a708742a8bf127eb66798bfc9c9516c61f9930 Author: Yang Shi <yang@os.amperecomputing.com> Date: Mon, 25 Nov 2024 09:16:50 -0800 Commit ba0fb44a ("dma-mapping: replace zone_dma_bits by zone_dma_limit") and subsequent patches changed how zone_dma_limit is calculated to allow a reduced ZONE_DMA even when RAM starts above 4GB. Commit 122c234e ("arm64: mm: keep low RAM dma zone") further fixed this to ensure ZONE_DMA remains below U32_MAX if RAM starts below 4GB, especially on platforms that do not have IORT or DT description of the device DMA ranges. While zone boundaries calculation was fixed by the latter commit, zone_dma_limit, used to determine the GFP_DMA flag in the core code, was not updated. This results in excessive use of GFP_DMA and unnecessary ZONE_DMA allocations on some platforms. Update zone_dma_limit to match the actual upper bound of ZONE_DMA. Fixes: ba0fb44a ("dma-mapping: replace zone_dma_bits by zone_dma_limit") Cc: <stable@vger.kernel.org> # 6.12.x Reported-by:
Yutang Jiang <jiangyutang@os.amperecomputing.com> Tested-by:
Yang Shi <yang@os.amperecomputing.com> Link: https://lore.kernel.org/r/20241125171650.77424-1-yang@os.amperecomputing.com [catalin.marinas@arm.com: some tweaking of the commit log] Signed-off-by:
Catalin Marinas <catalin.marinas@arm.com> Signed-off-by:
Luiz Capitulino <luizcap@redhat.com> Approved-by:
Waiman Long <longman@redhat.com> Approved-by:
Herton R. Krzesinski <herton@redhat.com> Approved-by:
-
Jan Stancek authored
MR: https://gitlab.com/redhat/rhel/src/kernel/rhel-10/-/merge_requests/10 JIRA: https://issues.redhat.com/browse/RHEL-80149 Enable FIPS module for the UKI. Note: 'kernel-uki-virt-addons' already ship fips=1' cmdline extension and this can now be used. Note: to work properly, dracut >= 104 is needed. Signed-off-by:
Emanuele Giuseppe Esposito <eesposit@redhat.com> Approved-by:
-
- Mar 05, 2025
-
-
Julio Faracco authored
Signed-off-by: -
Nigel Croxon authored
JIRA: https://issues.redhat.com/browse/RHEL-73721 commit 6564862d646e7d630929ba1ff330740bb215bdac Author: John Garry <john.g.garry@oracle.com> Date: Thu Jan 9 11:39:59 2025 +0000 block: Ensure start sector is aligned for stacking atomic writes For stacking atomic writes, ensure that the start sector is aligned with the device atomic write unit min and any boundary. Otherwise, we may permit misaligned atomic writes. Rework bdev_can_atomic_write() into a common helper to resuse the alignment check. There also use atomic_write_hw_unit_min, which is more proper (than atomic_write_unit_min). Fixes: d7f36dc446e89 ("block: Support atomic writes limits for stacked devices") Reviewed-by:
Christoph Hellwig <hch@lst.de> Signed-off-by:
John Garry <john.g.garry@oracle.com> Reviewed-by:
Jens Axboe <axboe@kernel.dk> (cherry picked from commit 6564862d646e7d630929ba1ff330740bb215bdac) Signed-off-by:
-
Julio Faracco authored
MR: https://gitlab.com/redhat/centos-stream/src/kernel/centos-stream-10/-/merge_requests/381 JIRA: https://issues.redhat.com/browse/RHEL-79464 ``` commit 52c11d31b5a1d1c747bb5f36cc4808e93e2348f4 Author: Joshua Hay <joshua.a.hay@intel.com> Date: Tue Feb 4 18:08:11 2025 -0800 idpf: call set_real_num_queues in idpf_open On initial driver load, alloc_etherdev_mqs is called with whatever max queue values are provided by the control plane. However, if the driver is loaded on a system where num_online_cpus() returns less than the max queues, the netdev will think there are more queues than are actually available. Only num_online_cpus() will be allocated, but skb_get_queue_mapping(skb) could possibly return an index beyond the range of allocated queues. Consequently, the packet is silently dropped and it appears as if TX is broken. Set the real number of queues during open so the netdev knows how many queues will be allocated. Fixes: 1c325aac ("idpf: configure resources for TX queues") Signed-off-by:
Joshua Hay <joshua.a.hay@intel.com> Reviewed-by:
Madhu Chittim <madhu.chittim@intel.com> Tested-by:
Samuel Salin <Samuel.salin@intel.com> Signed-off-by:
Tony Nguyen <anthony.l.nguyen@intel.com>```> Signed-off-by:
José Ignacio Tornos Martínez <jtornosm@redhat.com> Approved-by:
-
Julio Faracco authored
MR: https://gitlab.com/redhat/centos-stream/src/kernel/centos-stream-10/-/merge_requests/501 # Merge Request Required Information JIRA: https://issues.redhat.com/browse/RHEL-80060 ## Summary of Changes Re-order code in `event_hist_trigger_parse` so that `hist_trigger_enable` is called before `event_trigger_unregister`, enabling the latter to function correctly and remove a histogram with failed trigger parsing from the list. ## Approved Development Ticket(s) All submissions to CentOS Stream must reference a ticket in [Red Hat Jira](https://issues.redhat.com/). <details><summary>Click for formatting instructions</summary> Please follow the CentOS Stream [contribution documentation](https://docs.centos.org/en-US/stream-contrib/quickstart/ ) for how to file this ticket and have it approved. List tickets each on their own line of this description using the format "Resolves: RHEL-76229", "Related: RHEL-76229" or "Reverts: RHEL-76229", as appropriate. </details> Signed-off-by:
Tomas Glozar <tglozar@redhat.com> Approved-by:
Joe Lawrence <joe.lawrence@redhat.com> Approved-by:
-
Julio Faracco authored
MR: https://gitlab.com/redhat/centos-stream/src/kernel/centos-stream-10/-/merge_requests/404 JIRA: https://issues.redhat.com/browse/RHEL-79809 commits; ``` c12b2704a678b8a116eeb03f5b91895b90b4dd6f ``` Signed-off-by:
Tony Camuso <tcamuso@redhat.com> Approved-by:
-
Julio Faracco authored
MR: https://gitlab.com/redhat/centos-stream/src/kernel/centos-stream-10/-/merge_requests/198 JIRA: https://issues.redhat.com/browse/RHEL-74125 CVE: CVE-2024-57901 ``` af_packet: fix vlan_get_protocol_dgram() vs MSG_PEEK Blamed commit forgot MSG_PEEK case, allowing a crash [1] as found by syzbot. Rework vlan_get_protocol_dgram() to not touch skb at all, so that it can be used from many cpus on the same skb. Add a const qualifier to skb argument. [1] skbuff: skb_under_panic: text:ffffffff8a8ccd05 len:29 put:14 head:ffff88807fc8e400 data:ffff88807fc8e3f4 tail:0x11 end:0x140 dev:<NULL> ------------[ cut here ]------------ kernel BUG at net/core/skbuff.c:206 ! Oops: invalid opcode: 0000 [#1] PREEMPT SMP KASAN PTI CPU: 1 UID: 0 PID: 5892 Comm: syz-executor883 Not tainted 6.13.0-rc4-syzkaller-00054-gd6ef8b40d075 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/13/2024 RIP: 0010:skb_panic net/core/skbuff.c:206 [inline] RIP: 0010:skb_under_panic+0x14b/0x150 net/core/skbuff.c:216 Code: 0b 8d 48 c7 c6 86 d5 25 8e 48 8b 54 24 08 8b 0c 24 44 8b 44 24 04 4d 89 e9 50 41 54 41 57 41 56 e8 5a 69 79 f7 48 83 c4 20 90 <0f> 0b 0f 1f 00 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 f3 RSP: 0018:ffffc900038d7638 EFLAGS: 00010282 RAX: 0000000000000087 RBX: dffffc0000000000 RCX: 609ffd18ea660600 RDX: 0000000000000000 RSI: 0000000080000000 RDI: 0000000000000000 RBP: ffff88802483c8d0 R08: ffffffff817f0a8c R09: 1ffff9200071ae60 R10: dffffc0000000000 R11: fffff5200071ae61 R12: 0000000000000140 R13: ffff88807fc8e400 R14: ffff88807fc8e3f4 R15: 0000000000000011 FS: 00007fbac5e006c0(0000) GS:ffff8880b8700000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007fbac5e00d58 CR3: 000000001238e000 CR4: 00000000003526f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: <TASK> skb_push+0xe5/0x100 net/core/skbuff.c:2636 vlan_get_protocol_dgram+0x165/0x290 net/packet/af_packet.c:585 packet_recvmsg+0x948/0x1ef0 net/packet/af_packet.c:3552 sock_recvmsg_nosec net/socket.c:1033 [inline] sock_recvmsg+0x22f/0x280 net/socket.c:1055 ____sys_recvmsg+0x1c6/0x480 net/socket.c:2803 ___sys_recvmsg net/socket.c:2845 [inline] do_recvmmsg+0x426/0xab0 net/socket.c:2940 __sys_recvmmsg net/socket.c:3014 [inline] __do_sys_recvmmsg net/socket.c:3037 [inline] __se_sys_recvmmsg net/socket.c:3030 [inline] __x64_sys_recvmmsg+0x199/0x250 net/socket.c:3030 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f Fixes: 79eecf63 ("af_packet: Handle outgoing VLAN packets without hardware offloading") Reported-by:
<syzbot+74f70bb1cb968bf09e4f@syzkaller.appspotmail.com> Closes: https://lore.kernel.org/netdev/6772c485.050a0220.2f3838.04c5.GAE@google.com/T/#u Signed-off-by:
-
Julio Faracco authored
MR: https://gitlab.com/redhat/centos-stream/src/kernel/centos-stream-10/-/merge_requests/225 JIRA: https://issues.redhat.com/browse/RHEL-75473 ``` cxgb4: use port number to set mac addr t4_set_vf_mac_acl() uses pf to set mac addr, but t4vf_get_vf_mac_acl() uses port number to get mac addr, this leads to error when an attempt to set MAC address on VF's of PF2 and PF3. This patch fixes the issue by using port number to set mac address. Fixes: e0cdac65 ("cxgb4vf: configure ports accessible by the VF") Signed-off-by:
Anumula Murali Mohan Reddy <anumula@chelsio.com> Signed-off-by:
Potnuri Bharat Teja <bharat@chelsio.com> Reviewed-by:
Simon Horman <horms@kernel.org> Link: https://patch.msgid.link/20241206062014.49414-1-anumula@chelsio.com Signed-off-by:
-
Jan Stancek authored
JIRA: INTERNAL Upstream Status: RHEL only Don't bring in changes from Makefile.rhelver and self-tests. Signed-off-by:
-
