This project is mirrored from https://gitlab.com/redhat/centos-stream/src/kernel/centos-stream-10.git.
Pull mirroring updated .
- Mar 10, 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/504 JIRA: https://issues.redhat.com/browse/RHEL-81936 Commits: ``` dc287e4c9149ab54a5003b4d4da007818b5fda3d 05793884a1f30509e477de9da233ab73584b1c8c 2844ddbd540fc84d7571cca65d6c43088e4d6952 ``` Signed-off-by:
Mete Durlu <mdurlu@redhat.com> Merged-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:
Steve Best <sbest@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:
Heinz Mauelshagen <heinzm@redhat.com> Approved-by:
Xiao Ni <xni@redhat.com> Merged-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> Merged-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:
CKI KWF Bot <cki-ci-bot+kwf-gitlab-com@redhat.com> Merged-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:
Kamal Heib <kheib@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:
Vitaly Kuznetsov <vkuznets@redhat.com> Approved-by:
Emanuele Giuseppe Esposito <eesposit@redhat.com> Approved-by:
-
- Mar 05, 2025
-
-
Julio Faracco authored
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:
-
- Mar 04, 2025
-
-
Nigel Croxon authored
JIRA: https://issues.redhat.com/browse/RHEL-73721 commit fbe8f2fa971c537571994a0df532c511c4fb5537 Author: Bart Van Assche <bvanassche@acm.org> Date: Wed Feb 12 09:11:07 2025 -0800 md/raid*: Fix the set_queue_limits implementations queue_limits_cancel_update() must only be called if queue_limits_start_update() is called first. Remove the queue_limits_cancel_update() calls from the raid*_set_limits() functions because there is no corresponding queue_limits_start_update() call. Cc: Christoph Hellwig <hch@lst.de> Fixes: c6e56cf6 ("block: move integrity information into queue_limits") Signed-off-by:
Christoph Hellwig <hch@lst.de> Link: https://lore.kernel.org/linux-raid/20250212171108.3483150-1-bvanassche@acm.org/ Signed-off-by:
Yu Kuai <yukuai@kernel.org> (cherry picked from commit fbe8f2fa971c537571994a0df532c511c4fb5537) Signed-off-by:
-
Nigel Croxon authored
JIRA: https://issues.redhat.com/browse/RHEL-73721 commit a572593ac80e51eb69ecede7e614289fcccdbf8d Author: Bart Van Assche <bvanassche@acm.org> Date: Wed Jan 29 14:56:35 2025 -0800 md: Fix linear_set_limits() queue_limits_cancel_update() must only be called if queue_limits_start_update() is called first. Remove the queue_limits_cancel_update() call from linear_set_limits() because there is no corresponding queue_limits_start_update() call. This bug was discovered by annotating all mutex operations with clang thread-safety attributes and by building the kernel with clang and -Wthread-safety. Cc: Yu Kuai <yukuai3@huawei.com> Cc: Coly Li <colyli@kernel.org> Cc: Mike Snitzer <snitzer@kernel.org> Cc: Christoph Hellwig <hch@lst.de> Fixes: 127186cfb184 ("md: reintroduce md-linear") Signed-off-by:
Song Liu <song@kernel.org> Signed-off-by:
-
Nigel Croxon authored
JIRA: https://issues.redhat.com/browse/RHEL-73721 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:
-
Nigel Croxon authored
JIRA: https://issues.redhat.com/browse/RHEL-73721 commit 62c552070a980363d55a6082b432ebd1cade7a6e Author: Dan Carpenter <dan.carpenter@linaro.org> Date: Wed Jan 15 09:53:52 2025 +0300 md/md-linear: Fix a NULL vs IS_ERR() bug in linear_add() The linear_conf() returns error pointers, it doesn't return NULL. Update the error checking to match. Fixes: 127186cfb184 ("md: reintroduce md-linear") Signed-off-by:
Dan Carpenter <dan.carpenter@linaro.org> Reviewed-by:
-
Nigel Croxon authored
JIRA: https://issues.redhat.com/browse/RHEL-73721 commit cd5fc653381811f1e0ba65f5d169918cab61476f Author: Yu Kuai <yukuai3@huawei.com> Date: Thu Jan 9 09:51:45 2025 +0800 md/md-bitmap: move bitmap_{start, end}write to md upper layer There are two BUG reports that raid5 will hang at bitmap_startwrite([1],[2]), root cause is that bitmap start write and end write is unbalanced, it's not quite clear where, and while reviewing raid5 code, it's found that bitmap operations can be optimized. For example, for a 4 disks raid5, with chunksize=8k, if user issue a IO (0 + 48k) to the array: ┌────────────────────────────────────────────────────────────┐ │chunk 0 │ │ ┌────────────┬─────────────┬─────────────┬────────────┼ │ sh0 │A0: 0 + 4k │A1: 8k + 4k │A2: 16k + 4k │A3: P │ │ ┼────────────┼─────────────┼─────────────┼────────────┼ │ sh1 │B0: 4k + 4k │B1: 12k + 4k │B2: 20k + 4k │B3: P │ ┼──────┴────────────┴─────────────┴─────────────┴────────────┼ │chunk 1 │ │ ┌────────────┬─────────────┬─────────────┬────────────┤ │ sh2 │C0: 24k + 4k│C1: 32k + 4k │C2: P │C3: 40k + 4k│ │ ┼────────────┼─────────────┼─────────────┼────────────┼ │ sh3 │D0: 28k + 4k│D1: 36k + 4k │D2: P │D3: 44k + 4k│ └──────┴────────────┴─────────────┴─────────────┴────────────┘ Before this patch, 4 stripe head will be used, and each sh will attach bio for 3 disks, and each attached bio will trigger bitmap_startwrite() once, which means total 12 times. - 3 times (0 + 4k), for (A0, A1 and A2) - 3 times (4 + 4k), for (B0, B1 and B2) - 3 times (8 + 4k), for (C0, C1 and C3) - 3 times (12 + 4k), for (D0, D1 and D3) After this patch, md upper layer will calculate that IO range (0 + 48k) is corresponding to the bitmap (0 + 16k), and call bitmap_startwrite() just once. Noted that this patch will align bitmap ranges to the chunks, for example, if user issue a IO (0 + 4k) to array: - Before this patch, 1 time (0 + 4k), for A0; - After this patch, 1 time (0 + 8k) for chunk 0; Usually, one bitmap bit will represent more than one disk chunk, and this doesn't have any difference. And even if user really created a array that one chunk contain multiple bits, the overhead is that more data will be recovered after power failure. Also remove STRIPE_BITMAP_PENDING since it's not used anymore. [1] https://lore.kernel.org/all/CAJpMwyjmHQLvm6zg1cmQErttNNQPDAAXPKM3xgTjMhbfts986Q@mail.gmail.com/ [2] https://lore.kernel.org/all/ADF7D720-5764-4AF3-B68E-1845988737AA@flyingcircus.io/ Signed-off-by:
-
Nigel Croxon authored
JIRA: https://issues.redhat.com/browse/RHEL-73721 commit 9c89f604476cf15c31fbbdb043cff7fbf1dbe0cb Author: Yu Kuai <yukuai3@huawei.com> Date: Thu Jan 9 09:51:44 2025 +0800 md/raid5: implement pers->bitmap_sector() Bitmap is used for the whole array for raid1/raid10, hence IO for the array can be used directly for bitmap. However, bitmap is used for underlying disks for raid5, hence IO for the array can't be used directly for bitmap. Implement pers->bitmap_sector() for raid5 to convert IO ranges from the array to the underlying disks. Signed-off-by:
-
Nigel Croxon authored
JIRA: https://issues.redhat.com/browse/RHEL-73721 commit 0c984a283a3ea3f10bebecd6c57c1d41b2e4f518 Author: Yu Kuai <yukuai3@huawei.com> Date: Thu Jan 9 09:51:43 2025 +0800 md: add a new callback pers->bitmap_sector() This callback will be used in raid5 to convert io ranges from array to bitmap. Signed-off-by:
-
