This project is mirrored from https://gitlab.com/redhat/centos-stream/src/kernel/centos-stream-10.git.
Pull mirroring updated .
- Feb 14, 2025
-
-
Jan Stancek authored
Signed-off-by:Jan Stancek <jstancek@redhat.com>
-
Jan Stancek authored
Merge: CVE-2024-56611: mm/mempolicy: fix migrate_to_node() assuming there is at least one VMA in a MM MR: https://gitlab.com/redhat/centos-stream/src/kernel/centos-stream-10/-/merge_requests/253 JIRA: https://issues.redhat.com/browse/RHEL-76120 CVE: CVE-2024-56611 ``` mm/mempolicy: fix migrate_to_node() assuming there is at least one VMA in a MM We currently assume that there is at least one VMA in a MM, which isn't true. So we might end up having find_vma() return NULL, to then de-reference NULL. So properly handle find_vma() returning NULL. This fixes the report: Oops: general protection fault, probably for non-canonical address 0xdffffc0000000000: 0000 [#1] PREEMPT SMP KASAN PTI KASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007] CPU: 1 UID: 0 PID: 6021 Comm: syz-executor284 Not tainted 6.12.0-rc7-syzkaller-00187-gf868cd251776 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 10/30/2024 RIP: 0010:migrate_to_node mm/mempolicy.c:1090 [inline] RIP: 0010:do_migrate_pages+0x403/0x6f0 mm/mempolicy.c:1194 Code: ... RSP: 0018:ffffc9000375fd08 EFLAGS: 00010246 RAX: 0000000000000000 RBX: ffffc9000375fd78 RCX: 0000000000000000 RDX: ffff88807e171300 RSI: dffffc0000000000 RDI: ffff88803390c044 RBP: ffff88807e171428 R08: 0000000000000014 R09: fffffbfff2039ef1 R10: ffffffff901cf78f R11: 0000000000000000 R12: 0000000000000003 R13: ffffc9000375fe90 R14: ffffc9000375fe98 R15: ffffc9000375fdf8 FS: 00005555919e1380(0000) GS:ffff8880b8700000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00005555919e1ca8 CR3: 000000007f12a000 CR4: 00000000003526f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: <TASK> kernel_migrate_pages+0x5b2/0x750 mm/mempolicy.c:1709 __do_sys_migrate_pages mm/mempolicy.c:1727 [inline] __se_sys_migrate_pages mm/mempolicy.c:1723 [inline] __x64_sys_migrate_pages+0x96/0x100 mm/mempolicy.c:1723 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xcd/0x250 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f [akpm@linux-foundation.org: add unlikely()] Link: https://lkml.kernel.org/r/20241120201151.9518-1-david@redhat.com Fixes: 39743889 ("[PATCH] Swap Migration V5: sys_migrate_pages interface") Signed-off-by:
David Hildenbrand <david@redhat.com> Reported-by:
<syzbot+3511625422f7aa637f0d@syzkaller.appspotmail.com> Closes: https://lore.kernel.org/lkml/673d2696.050a0220.3c9d61.012f.GAE@google.com/T/ Reviewed-by:
Liam R. Howlett <Liam.Howlett@Oracle.com> Reviewed-by:
Christoph Lameter <cl@linux.com> Cc: Liam R. Howlett <Liam.Howlett@Oracle.com> Cc: <stable@vger.kernel.org> Signed-off-by:
Andrew Morton <akpm@linux-foundation.org> (cherry picked from commit 091c1dd2d4df6edd1beebe0e5863d4034ade9572) ``` Signed-off-by:
CKI Backport Bot <cki-ci-bot+cki-gitlab-backport-bot@redhat.com> --- <small>Created 2025-01-24 09:59 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:
Waiman Long <longman@redhat.com> Approved-by:
Aristeu Rozanski <arozansk@redhat.com> Approved-by:
Rafael Aquini <raquini@redhat.com> Approved-by:
Nico Pache <npache@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/centos-stream/src/kernel/centos-stream-10/-/merge_requests/378 JIRA: INTERNAL Upstream Status: RHEL only Reinstate s1-gcp-ci.brew-build.tier1.functional test, owners said it's stable now. This reverts commit 6a121851. Signed-off-by:
Eder Zulian <ezulian@redhat.com> Merged-by:
-
Jan Stancek authored
MR: https://gitlab.com/redhat/centos-stream/src/kernel/centos-stream-10/-/merge_requests/374 nvme: remove multipath module parameter JIRA: https://issues.redhat.com/browse/RHEL-78133 Upstream Status: RHEL-only Since device-mapper multipath will no longer be operating on NVMe devices, there is no longer a need for the "multipath" parameter. Note that, when compiled with CONFIG_NVME_MULTIPATH off multi-path capable controllers and namespaces will continue to present multiple device entries - one for each controller/namespace discovered. This could be confusing, as device-mapper multipath relies upon code in nvme/host/multipath.c, and running device-mapper multipath with a kernel compiled with CONFIG_NVME_MULTIPATH disabled is not supported. Closes: https://lore.kernel.org/linux-nvme/20241121220321.40616-1-bgurney@redhat.com/ Tested-by:
John Meneghini <jmeneghi@redhat.com> Reviewed-by:
Bryan Gurney <bgurney@redhat.com> Approved-by:
Ewan D. Milne <emilne@redhat.com> Approved-by:
-
Jan Stancek authored
MR: https://gitlab.com/redhat/centos-stream/src/kernel/centos-stream-10/-/merge_requests/370 NFSD: Fix CB_GETATTR status fix JIRA: https://issues.redhat.com/browse/RHEL-56888 Signed-off-by:
Olga Kornievskaia <okorniev@redhat.com> Approved-by:
Scott Mayhew <smayhew@redhat.com> Approved-by:
Benjamin Coddington <bcodding@redhat.com> Approved-by:
-
Jan Stancek authored
MR: https://gitlab.com/redhat/centos-stream/src/kernel/centos-stream-10/-/merge_requests/362 JIRA: https://issues.redhat.com/browse/RHEL-78517 CVE: CVE-2024-57949 ``` irqchip/gic-v3-its: Don't enable interrupts in its_irq_set_vcpu_affinity() The following call-chain leads to enabling interrupts in a nested interrupt disabled section: irq_set_vcpu_affinity() irq_get_desc_lock() raw_spin_lock_irqsave() <--- Disable interrupts its_irq_set_vcpu_affinity() guard(raw_spinlock_irq) <--- Enables interrupts when leaving the guard() irq_put_desc_unlock() <--- Warns because interrupts are enabled This was broken in commit b97e8a2f, which replaced the original raw_spin_[un]lock() pair with guard(raw_spinlock_irq). Fix the issue by using guard(raw_spinlock). [ tglx: Massaged change log ] Fixes: b97e8a2f ("irqchip/gic-v3-its: Fix potential race condition in its_vlpi_prop_update()") Signed-off-by:
Tomas Krcka <krckatom@amazon.de> Signed-off-by:
Thomas Gleixner <tglx@linutronix.de> Reviewed-by:
Marc Zyngier <maz@kernel.org> Cc: stable@vger.kernel.org Link: https://lore.kernel.org/all/20241230150825.62894-1-krckatom@amazon.de (cherry picked from commit 35cb2c6ce7da545f3b5cb1e6473ad7c3a6f08310) ``` Signed-off-by:
Charles Mirabile <cmirabil@redhat.com> Approved-by:
John W. Linville <linville@redhat.com> Approved-by:
Lenny Szubowicz <lszubowi@redhat.com> Approved-by:
-
Jan Stancek authored
MR: https://gitlab.com/redhat/centos-stream/src/kernel/centos-stream-10/-/merge_requests/361 JIRA: https://issues.redhat.com/browse/RHEL-78322 Upstream status: RHEL-Only Since some of our key projects use erofs we have surveyed the code and assessed upstream support status for the file system and this all looks good from a support perspective. So we are promoting erofs to full support. Signed-off-by:
Ian Kent <ikent@redhat.com> Approved-by:
Brian Foster <bfoster@redhat.com> Approved-by:
Eric Sandeen <esandeen@redhat.com> Approved-by:
-
Jan Stancek authored
MR: https://gitlab.com/redhat/centos-stream/src/kernel/centos-stream-10/-/merge_requests/356 JIRA: https://issues.redhat.com/browse/RHEL-78388 Signed-off-by:
Marc Dionne <mdionne@redhat.com> Approved-by:
Alice Mitchell <ajmitchell@redhat.com> Approved-by:
David Howells <dhowells@redhat.com> Approved-by:
-
Jan Stancek authored
MR: https://gitlab.com/redhat/centos-stream/src/kernel/centos-stream-10/-/merge_requests/353 JIRA: https://issues.redhat.com/browse/RHEL-78152 Signed-off-by:
Paulo Alcantara <paalcant@redhat.com> Approved-by:
Jay Shin <jaeshin@redhat.com> Approved-by:
-
Jan Stancek authored
MR: https://gitlab.com/redhat/centos-stream/src/kernel/centos-stream-10/-/merge_requests/346 JIRA: https://issues.redhat.com/browse/RHEL-78209 commit 8ac412a3361173e3000b16167af3d1f6f90af613 Author: Daniel Xu <dxu@dxuuu.xyz> Date: Tue Jan 14 13:28:43 2025 -0700 bpf: tcp: Mark bpf_load_hdr_opt() arg2 as read-write MEM_WRITE attribute is defined as: "Non-presence of MEM_WRITE means that MEM is only being read". bpf_load_hdr_opt() both reads and writes from its arg2 - void *search_res. This matters a lot for the next commit where we more precisely track stack accesses. Without this annotation, the verifier will make false assumptions about the contents of memory written to by helpers and possibly prune valid branches. Fixes: 6fad274f ("bpf: Add MEM_WRITE attribute") Acked-by:
Martin KaFai Lau <martin.lau@kernel.org> Signed-off-by:
Daniel Xu <dxu@dxuuu.xyz> Link: https://lore.kernel.org/r/730e45f8c39be2a5f3d8c4406cceca9d574cbf14.1736886479.git.dxu@dxuuu.xyz Signed-off-by:
Alexei Starovoitov <ast@kernel.org> Signed-off-by:
Viktor Malik <vmalik@redhat.com> Approved-by:
Tomas Glozar <tglozar@redhat.com> Approved-by:
Jerome Marchand <jmarchan@redhat.com> Approved-by:
Toke Høiland-Jørgensen <toke@redhat.com> Approved-by:
-
Jan Stancek authored
MR: https://gitlab.com/redhat/centos-stream/src/kernel/centos-stream-10/-/merge_requests/340 JIRA: https://issues.redhat.com/browse/RHEL-77959 MR: https://gitlab.com/redhat/centos-stream/src/kernel/centos-stream-10/-/merge_requests/340 The second patch is the fix commit. The first patch fixes a minor issue in the code. Signed-off-by:
Phil Auld <pauld@redhat.com> Approved-by:
Herton R. Krzesinski <herton@redhat.com> Approved-by:
-
Jan Stancek authored
MR: https://gitlab.com/redhat/centos-stream/src/kernel/centos-stream-10/-/merge_requests/208 JIRA: https://issues.redhat.com/browse/RHEL-71050 Upstream Status: https://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm commit d40797d6720e861196e848f3615bb09dae5be7ce Author: Peter Zijlstra <peterz@infradead.org> Date: Fri, 22 Nov 2024 16:54:51 +0100 kasan: make kasan_record_aux_stack_noalloc() the default behaviour kasan_record_aux_stack_noalloc() was introduced to record a stack trace without allocating memory in the process. It has been added to callers which were invoked while a raw_spinlock_t was held. More and more callers were identified and changed over time. Is it a good thing to have this while functions try their best to do a locklessly setup? The only downside of having kasan_record_aux_stack() not allocate any memory is that we end up without a stacktrace if stackdepot runs out of memory and at the same stacktrace was not recorded before To quote Marco Elver from https://lore.kernel.org/all/CANpmjNPmQYJ7pv1N3cuU8cP18u7PP_uoZD8YxwZd4jtbof9nVQ@mail.gmail.com/ | I'd be in favor, it simplifies things. And stack depot should be | able to replenish its pool sufficiently in the "non-aux" cases | i.e. regular allocations. Worst case we fail to record some | aux stacks, but I think that's only really bad if there's a bug | around one of these allocations. In general the probabilities | of this being a regression are extremely small [...] Make the kasan_record_aux_stack_noalloc() behaviour default as kasan_record_aux_stack(). [bigeasy@linutronix.de: dressed the diff as patch] Link: https://lkml.kernel.org/r/20241122155451.Mb2pmeyJ@linutronix.de Fixes: 7cb3007c ("kasan: generic: introduce kasan_record_aux_stack_noalloc()") Signed-off-by:
Peter Zijlstra (Intel) <peterz@infradead.org> Signed-off-by:
Sebastian Andrzej Siewior <bigeasy@linutronix.de> Reported-by:
<syzbot+39f85d612b7c20d8db48@syzkaller.appspotmail.com> Closes: https://lore.kernel.org/all/67275485.050a0220.3c8d68.0a37.GAE@google.com Reviewed-by:
Andrey Konovalov <andreyknvl@gmail.com> Reviewed-by:
Marco Elver <elver@google.com> Reviewed-by:
Wander Lairson Costa <wander@redhat.com> Approved-by:
-
Jan Stancek authored
MR: https://gitlab.com/redhat/centos-stream/src/kernel/centos-stream-10/-/merge_requests/206 JIRA: https://issues.redhat.com/browse/RHEL-74109 CVE: CVE-2024-57888 commit de35994ecd2dd6148ab5a6c5050a1670a04dec77 Author: Tvrtko Ursulin <tvrtko.ursulin@igalia.com> Date: Thu, 19 Dec 2024 09:30:30 +0000 workqueue: Do not warn when cancelling WQ_MEM_RECLAIM work from !WQ_MEM_RECLAIM worker After commit 746ae46c ("drm/sched: Mark scheduler work queues with WQ_MEM_RECLAIM") amdgpu started seeing the following warning: [ ] workqueue: WQ_MEM_RECLAIM sdma0:drm_sched_run_job_work [gpu_sched] is flushing !WQ_MEM_RECLAIM events:amdgpu_device_delay_enable_gfx_off [amdgpu] ... [ ] Workqueue: sdma0 drm_sched_run_job_work [gpu_sched] ... [ ] Call Trace: [ ] <TASK> ... [ ] ? check_flush_dependency+0xf5/0x110 ... [ ] cancel_delayed_work_sync+0x6e/0x80 [ ] amdgpu_gfx_off_ctrl+0xab/0x140 [amdgpu] [ ] amdgpu_ring_alloc+0x40/0x50 [amdgpu] [ ] amdgpu_ib_schedule+0xf4/0x810 [amdgpu] [ ] ? drm_sched_run_job_work+0x22c/0x430 [gpu_sched] [ ] amdgpu_job_run+0xaa/0x1f0 [amdgpu] [ ] drm_sched_run_job_work+0x257/0x430 [gpu_sched] [ ] process_one_work+0x217/0x720 ... [ ] </TASK> The intent of the verifcation done in check_flush_depedency is to ensure forward progress during memory reclaim, by flagging cases when either a memory reclaim process, or a memory reclaim work item is flushed from a context not marked as memory reclaim safe. This is correct when flushing, but when called from the cancel(_delayed)_work_sync() paths it is a false positive because work is either already running, or will not be running at all. Therefore cancelling it is safe and we can relax the warning criteria by letting the helper know of the calling context. Signed-off-by:
Tvrtko Ursulin <tvrtko.ursulin@igalia.com> Fixes: fca839c0 ("workqueue: warn if memory reclaim tries to flush !WQ_MEM_RECLAIM workqueue") References: 746ae46c ("drm/sched: Mark scheduler work queues with WQ_MEM_RECLAIM") Cc: Tejun Heo <tj@kernel.org> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Lai Jiangshan <jiangshanlai@gmail.com> Cc: Alex Deucher <alexander.deucher@amd.com> Cc: Christian König <christian.koenig@amd.com Cc: Matthew Brost <matthew.brost@intel.com> Cc: <stable@vger.kernel.org> # v4.5+ Signed-off-by:
Tejun Heo <tj@kernel.org> Signed-off-by:
-
Jan Stancek authored
MR: https://gitlab.com/redhat/centos-stream/src/kernel/centos-stream-10/-/merge_requests/306 JIRA: https://issues.redhat.com/browse/RHEL-77236 CVE: CVE-2025-21673 ``` smb: client: fix double free of TCP_Server_Info::hostname When shutting down the server in cifs_put_tcp_session(), cifsd thread might be reconnecting to multiple DFS targets before it realizes it should exit the loop, so @server->hostname can't be freed as long as cifsd thread isn't done. Otherwise the following can happen: RIP: 0010:__slab_free+0x223/0x3c0 Code: 5e 41 5f c3 cc cc cc cc 4c 89 de 4c 89 cf 44 89 44 24 08 4c 89 1c 24 e8 fb cf 8e 00 44 8b 44 24 08 4c 8b 1c 24 e9 5f fe ff ff <0f> 0b 41 f7 45 08 00 0d 21 00 0f 85 2d ff ff ff e9 1f ff ff ff 80 RSP: 0018:ffffb26180dbfd08 EFLAGS: 00010246 RAX: ffff8ea34728e510 RBX: ffff8ea34728e500 RCX: 0000000000800068 RDX: 0000000000800068 RSI: 0000000000000000 RDI: ffff8ea340042400 RBP: ffffe112041ca380 R08: 0000000000000001 R09: 0000000000000000 R10: 6170732e31303000 R11: 70726f632e786563 R12: ffff8ea34728e500 R13: ffff8ea340042400 R14: ffff8ea34728e500 R15: 0000000000800068 FS: 0000000000000000(0000) GS:ffff8ea66fd80000(0000) 000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007ffc25376080 CR3: 000000012a2ba001 CR4: PKRU: 55555554 Call Trace: <TASK> ? show_trace_log_lvl+0x1c4/0x2df ? show_trace_log_lvl+0x1c4/0x2df ? __reconnect_target_unlocked+0x3e/0x160 [cifs] ? __die_body.cold+0x8/0xd ? die+0x2b/0x50 ? do_trap+0xce/0x120 ? __slab_free+0x223/0x3c0 ? do_error_trap+0x65/0x80 ? __slab_free+0x223/0x3c0 ? exc_invalid_op+0x4e/0x70 ? __slab_free+0x223/0x3c0 ? asm_exc_invalid_op+0x16/0x20 ? __slab_free+0x223/0x3c0 ? extract_hostname+0x5c/0xa0 [cifs] ? extract_hostname+0x5c/0xa0 [cifs] ? __kmalloc+0x4b/0x140 __reconnect_target_unlocked+0x3e/0x160 [cifs] reconnect_dfs_server+0x145/0x430 [cifs] cifs_handle_standard+0x1ad/0x1d0 [cifs] cifs_demultiplex_thread+0x592/0x730 [cifs] ? __pfx_cifs_demultiplex_thread+0x10/0x10 [cifs] kthread+0xdd/0x100 ? __pfx_kthread+0x10/0x10 ret_from_fork+0x29/0x50 </TASK> Fixes: 7be3248f ("cifs: To match file servers, make sure the server hostname matches") Reported-by:
Paulo Alcantara (Red Hat) <pc@manguebit.com> Signed-off-by:
Steve French <stfrench@microsoft.com> (cherry picked from commit fa2f9906a7b333ba757a7dbae0713d8a5396186e) ``` Signed-off-by:
-
Jan Stancek authored
MR: https://gitlab.com/redhat/centos-stream/src/kernel/centos-stream-10/-/merge_requests/50 JIRA: https://issues.redhat.com/browse/RHEL-67530 Upstream Status: RHEL only It is suggested that the 4k arm64 kernel should have a CONFIG_ARCH_FORCE_MAX_ORDER value of 12 to match that of RHEL9 to avoid compatibility problem when applications are ported from RHEL9 to RHEL10. Due to the way the ARCH_FORCE_MAX_ORDER kconfig option is defined in arch/arm64/Kconfig, we just can't change CONFIG_ARCH_FORCE_MAX_ORDER of the 4k kernel from the default by adding a kconfig file under redhat/configs as "make dist-configs" will fail. So the only option left is to modify the default value in the ARCH_FORCE_MAX_ORDER entry of arch/arm64/Kconfig. Signed-off-by:
Mark Langsdorf <mlangsdo@redhat.com> Approved-by:
-
Jan Stancek authored
MR: https://gitlab.com/redhat/centos-stream/src/kernel/centos-stream-10/-/merge_requests/295 JIRA: https://issues.redhat.com/browse/RHEL-77048 Signed-off-by:
David Arcari <darcari@redhat.com> Approved-by:
Mika Penttilä <mpenttil@redhat.com> Approved-by:
Steve Best <sbest@redhat.com> Approved-by:
-
Jan Stancek authored
MR: https://gitlab.com/redhat/centos-stream/src/kernel/centos-stream-10/-/merge_requests/36 Backport 'Relax canonical checks on some arch msrs' to fix rare failures during SMM entry on 5 level paging enabled CPUs. JIRA: https://issues.redhat.com/browse/RHEL-44575 Signed-off-by:
Maxim Levitsky <mlevitsk@redhat.com> Approved-by:
Vitaly Kuznetsov <vkuznets@redhat.com> Approved-by:
Paolo Bonzini <bonzini@gnu.org> Approved-by:
-
Jan Stancek authored
MR: https://gitlab.com/redhat/centos-stream/src/kernel/centos-stream-10/-/merge_requests/29 JIRA: https://issues.redhat.com/browse/RHEL-64637 Upstream Status: RHEL only. Tested: via fstests. fscrypt has never been enabled for ext4. CONFIG_FS_ENCRYPTION was recently enabled for Ceph support, however. This has the side effect of enabling related codepaths in ext4. To maintain disabled status, open code the encrypt feature bit handler to force disable the feature at runtime. This preserves historical ability to mount filesystems with the encrypt feature bit set, but without the ability to use fscrypt functionality. Signed-off-by:
Carlos Maiolino <cmaiolino@redhat.com> Approved-by:
-
Jan Stancek authored
MR: https://gitlab.com/redhat/centos-stream/src/kernel/centos-stream-10/-/merge_requests/28 ``` Latest Intel platform Clearwater Forest has introduced new instructions enumerated by CPUIDs of SHA512, SM3, SM4 and AVX-VNNI-INT16. Advertise these CPUIDs to userspace so that guests can query them directly. These new instructions only operate in xmm, ymm registers and have no new VMX controls, so there is no additional host enabling required for guests to use these instructions, i.e. advertising these CPUIDs to userspace is safe. ``` ``` JIRA: https://issues.redhat.com/browse/RHEL-45114 Signed-off-by:
Paolo Bonzini <pbonzini@redhat.com> ``` Approved-by:
-
Jan Stancek authored
MR: https://gitlab.com/redhat/centos-stream/src/kernel/centos-stream-10/-/merge_requests/275 JIRA: https://issues.redhat.com/browse/RHEL-75944 Upstream Status: git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git Recent upstream fixes for iommufd: iommufd/iova_bitmap: Fix shift-out-of-bounds in iova_bitmap_offset_to_index() iommu: iommufd: fix WARNING in iommufd_device_unbind iommufd/fault: Destroy response and mutex in iommufd_fault_destroy() iommufd/fault: Use a separate spinlock to protect fault->deliver list iommufd: Fix struct iommu_hwpt_pgfault init and padding Signed-off-by:
Donald Dutile <ddutile@redhat.com> Approved-by:
-
Jan Stancek authored
MR: https://gitlab.com/redhat/centos-stream/src/kernel/centos-stream-10/-/merge_requests/259 JIRA: https://issues.redhat.com/browse/RHEL-76126 CVE: CVE-2024-53179 ``` smb: client: fix use-after-free of signing key Customers have reported use-after-free in @ses->auth_key.response with SMB2.1 + sign mounts which occurs due to following race: task A task B cifs_mount() dfs_mount_share() get_session() cifs_mount_get_session() cifs_send_recv() cifs_get_smb_ses() compound_send_recv() cifs_setup_session() smb2_setup_request() kfree_sensitive() smb2_calc_signature() crypto_shash_setkey() *UAF* Fix this by ensuring that we have a valid @ses->auth_key.response by checking whether @ses->ses_status is SES_GOOD or SES_EXITING with @ses->ses_lock held. After commit 24a9799a ("smb: client: fix UAF in smb2_reconnect_server()"), we made sure to call ->logoff() only when @ses was known to be good (e.g. valid ->auth_key.response), so it's safe to access signing key when @ses->ses_status == SES_EXITING. Cc: stable@vger.kernel.org Reported-by:
-
Jan Stancek authored
MR: https://gitlab.com/redhat/centos-stream/src/kernel/centos-stream-10/-/merge_requests/257 JIRA: https://issues.redhat.com/browse/RHEL-76124 CVE: CVE-2024-53185 ``` smb: client: fix NULL ptr deref in crypto_aead_setkey() Neither SMB3.0 or SMB3.02 supports encryption negotiate context, so when SMB2_GLOBAL_CAP_ENCRYPTION flag is set in the negotiate response, the client uses AES-128-CCM as the default cipher. See MS-SMB2 3.3.5.4. Commit b0abcd65 ("smb: client: fix UAF in async decryption") added a @server->cipher_type check to conditionally call smb3_crypto_aead_allocate(), but that check would always be false as @server->cipher_type is unset for SMB3.02. Fix the following KASAN splat by setting @server->cipher_type for SMB3.02 as well. mount.cifs //srv/share /mnt -o vers=3.02,seal,... BUG: KASAN: null-ptr-deref in crypto_aead_setkey+0x2c/0x130 Read of size 8 at addr 0000000000000020 by task mount.cifs/1095 CPU: 1 UID: 0 PID: 1095 Comm: mount.cifs Not tainted 6.12.0 #1 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-3.fc41 04/01/2014 Call Trace: <TASK> dump_stack_lvl+0x5d/0x80 ? crypto_aead_setkey+0x2c/0x130 kasan_report+0xda/0x110 ? crypto_aead_setkey+0x2c/0x130 crypto_aead_setkey+0x2c/0x130 crypt_message+0x258/0xec0 [cifs] ? __asan_memset+0x23/0x50 ? __pfx_crypt_message+0x10/0x10 [cifs] ? mark_lock+0xb0/0x6a0 ? hlock_class+0x32/0xb0 ? mark_lock+0xb0/0x6a0 smb3_init_transform_rq+0x352/0x3f0 [cifs] ? lock_acquire.part.0+0xf4/0x2a0 smb_send_rqst+0x144/0x230 [cifs] ? __pfx_smb_send_rqst+0x10/0x10 [cifs] ? hlock_class+0x32/0xb0 ? smb2_setup_request+0x225/0x3a0 [cifs] ? __pfx_cifs_compound_last_callback+0x10/0x10 [cifs] compound_send_recv+0x59b/0x1140 [cifs] ? __pfx_compound_send_recv+0x10/0x10 [cifs] ? __create_object+0x5e/0x90 ? hlock_class+0x32/0xb0 ? do_raw_spin_unlock+0x9a/0xf0 cifs_send_recv+0x23/0x30 [cifs] SMB2_tcon+0x3ec/0xb30 [cifs] ? __pfx_SMB2_tcon+0x10/0x10 [cifs] ? lock_acquire.part.0+0xf4/0x2a0 ? __pfx_lock_release+0x10/0x10 ? do_raw_spin_trylock+0xc6/0x120 ? lock_acquire+0x3f/0x90 ? _get_xid+0x16/0xd0 [cifs] ? __pfx_SMB2_tcon+0x10/0x10 [cifs] ? cifs_get_smb_ses+0xcdd/0x10a0 [cifs] cifs_get_smb_ses+0xcdd/0x10a0 [cifs] ? __pfx_cifs_get_smb_ses+0x10/0x10 [cifs] ? cifs_get_tcp_session+0xaa0/0xca0 [cifs] cifs_mount_get_session+0x8a/0x210 [cifs] dfs_mount_share+0x1b0/0x11d0 [cifs] ? __pfx___lock_acquire+0x10/0x10 ? __pfx_dfs_mount_share+0x10/0x10 [cifs] ? lock_acquire.part.0+0xf4/0x2a0 ? find_held_lock+0x8a/0xa0 ? hlock_class+0x32/0xb0 ? lock_release+0x203/0x5d0 cifs_mount+0xb3/0x3d0 [cifs] ? do_raw_spin_trylock+0xc6/0x120 ? __pfx_cifs_mount+0x10/0x10 [cifs] ? lock_acquire+0x3f/0x90 ? find_nls+0x16/0xa0 ? smb3_update_mnt_flags+0x372/0x3b0 [cifs] cifs_smb3_do_mount+0x1e2/0xc80 [cifs] ? __pfx_vfs_parse_fs_string+0x10/0x10 ? __pfx_cifs_smb3_do_mount+0x10/0x10 [cifs] smb3_get_tree+0x1bf/0x330 [cifs] vfs_get_tree+0x4a/0x160 path_mount+0x3c1/0xfb0 ? kasan_quarantine_put+0xc7/0x1d0 ? __pfx_path_mount+0x10/0x10 ? kmem_cache_free+0x118/0x3e0 ? user_path_at+0x74/0xa0 __x64_sys_mount+0x1a6/0x1e0 ? __pfx___x64_sys_mount+0x10/0x10 ? mark_held_locks+0x1a/0x90 do_syscall_64+0xbb/0x1d0 entry_SYSCALL_64_after_hwframe+0x77/0x7f Cc: Tom Talpey <tom@talpey.com> Reported-by:
Jianhong Yin <jiyin@redhat.com> Cc: stable@vger.kernel.org # v6.12 Fixes: b0abcd65 ("smb: client: fix UAF in async decryption") Signed-off-by:
-
Jan Stancek authored
MR: https://gitlab.com/redhat/centos-stream/src/kernel/centos-stream-10/-/merge_requests/357 JIRA: https://issues.redhat.com/browse/RHEL-63081 Upstream Status: ARK.git Conflicts: In first patch, skip hunk applied to Documentation/networking/napi.rst commit a90a91e24b48 ("docs: networking: Describe irq suspension") irq suspension is not yet available in RHEL10 (yet) Depends: https://gitlab.com/redhat/centos-stream/src/kernel/centos-stream-10/-/merge_requests/337 Build and package tools/net/ynl. Signed-off-by:
Paolo Abeni <pabeni@redhat.com> Approved-by:
Jarod Wilson <jarod@redhat.com> Approved-by:
-
Jan Stancek authored
JIRA: https://issues.redhat.com/browse/RHEL-63081 Upstream Status: ARK.git commit e9f967afa1618dca23de6e8bcba1d2eb6c8285fc Author: Jan Stancek <jstancek@redhat.com> Date: Thu Oct 24 05:20:56 2024 -0400 redhat: kernel.spec: add ynl to kernel-tools build and package tools/net/ynl. Signed-off-by:
-
- Feb 13, 2025
-
-
Jan Stancek authored
JIRA: INTERNAL Upstream Status: RHEL only Reinstate s1-gcp-ci.brew-build.tier1.functional test, owners said it's stable now. This reverts commit 6a121851. Signed-off-by:
-
Paulo Alcantara authored
JIRA: https://issues.redhat.com/browse/RHEL-78152 commit be1963dd4ce4e467f062b023d1e696f40c926a04 Author: Paulo Alcantara <pc@manguebit.com> Date: Wed Feb 5 13:41:32 2025 -0300 smb: client: get rid of kstrdup() in get_ses_refpath() After commit 36008fe6e3dc ("smb: client: don't try following DFS links in cifs_tree_connect()"), TCP_Server_Info::leaf_fullpath will no longer be changed, so there is no need to kstrdup() it. Signed-off-by:
-
Paulo Alcantara authored
JIRA: https://issues.redhat.com/browse/RHEL-78152 commit 773dc23ff81838b6f74d7fabba5a441cc6a93982 Author: Paulo Alcantara <pc@manguebit.com> Date: Wed Feb 5 13:22:11 2025 -0300 smb: client: fix noisy when tree connecting to DFS interlink targets When the client attempts to tree connect to a domain-based DFS namespace from a DFS interlink target, the server will return STATUS_BAD_NETWORK_NAME and the following will appear on dmesg: CIFS: VFS: BAD_NETWORK_NAME: \\dom\dfs Since a DFS share might contain several DFS interlinks and they expire after 10 minutes, the above message might end up being flooded on dmesg when mounting or accessing them. Print this only once per share. Signed-off-by:
-
Paulo Alcantara authored
JIRA: https://issues.redhat.com/browse/RHEL-78152 commit 77c2e45dbf9d2ced21d2cf6cc3b2a048d57ab7ad Author: Paulo Alcantara <pc@manguebit.com> Date: Wed Feb 5 13:03:33 2025 -0300 smb: client: don't trust DFSREF_STORAGE_SERVER bit Some servers don't respect the DFSREF_STORAGE_SERVER bit, so unconditionally tree connect to DFS link target and then decide whether or not continue chasing DFS referrals for DFS interlinks. Otherwise the client would fail to mount such shares. Signed-off-by:
-
Paulo Alcantara authored
JIRA: https://issues.redhat.com/browse/RHEL-78152 commit 3681c74d342db75b0d641ba60de27bf73e16e66b Author: Paulo Alcantara <pc@manguebit.com> Date: Tue Jan 21 15:25:36 2025 -0300 smb: client: handle lack of EA support in smb2_query_path_info() If the server doesn't support both EAs and reparse point in a file, the SMB2_QUERY_INFO request will fail with either STATUS_NO_EAS_ON_FILE or STATUS_EAS_NOT_SUPPORT in the compound chain, so ignore it as long as reparse point isn't IO_REPARSE_TAG_LX_(CHR|BLK), which would require the EAs to know about major/minor numbers. Reported-by:
Pali Rohár <pali@kernel.org> Signed-off-by:
-
Paulo Alcantara authored
JIRA: https://issues.redhat.com/browse/RHEL-78152 commit 056e91cbc9804f15704b5bc2f02f91c23b1abea1 Author: Paulo Alcantara <pc@manguebit.com> Date: Fri Jan 17 17:52:15 2025 -0300 smb: client: don't check for @leaf_fullpath in match_server() The matching of DFS connections is already handled by @dfs_conn, so remove @leaf_fullpath matching altogether. Signed-off-by:
-
Paulo Alcantara authored
JIRA: https://issues.redhat.com/browse/RHEL-78152 commit 0a9b00e5e5c5fc3c77cbfd01e6ffbe77fc7fe74a Author: Paulo Alcantara <pc@manguebit.com> Date: Fri Jan 17 17:38:56 2025 -0300 smb: client: get rid of TCP_Server_Info::refpath_lock TCP_Server_Info::leaf_fullpath is allocated in cifs_get_tcp_session() and never changed afterwards, so there is no need to serialize its access. Signed-off-by:
-
Paulo Alcantara authored
JIRA: https://issues.redhat.com/browse/RHEL-78152 commit 015683d4ed0d23698c71f2194f09bd17dbfad044 Author: Pali Rohár <pali@kernel.org> Date: Thu Jan 2 21:38:48 2025 +0100 cifs: Use cifs_autodisable_serverino() for disabling CIFS_MOUNT_SERVER_INUM in readdir.c In all other places is used function cifs_autodisable_serverino() for disabling CIFS_MOUNT_SERVER_INUM mount flag. So use is also in readir.c _initiate_cifs_search() function. Benefit of cifs_autodisable_serverino() is that it also prints dmesg message that server inode numbers are being disabled. Fixes: ec06aedd ("cifs: clean up handling when server doesn't consistently support inode numbers") Fixes: f534dc99 ("cifs: clear server inode number flag while autodisabling") Signed-off-by:
-
Paulo Alcantara authored
JIRA: https://issues.redhat.com/browse/RHEL-78152 commit 72cf9e94f32fc18096be3cc21216a78f50220e03 Author: Steve French <stfrench@microsoft.com> Date: Sun Jan 19 01:02:06 2025 -0600 smb3: add missing tracepoint for querying wsl EAs We had tracepoints for the return code for querying WSL EAs (trace_smb3_query_wsl_ea_compound_err and trace_smb3_query_wsl_ea_compound_done) but were missing one for trace_smb3_query_wsl_ea_compound_enter. Fixes: ea41367b ("smb: client: introduce SMB2_OP_QUERY_WSL_EA") Signed-off-by:
-
Paulo Alcantara authored
JIRA: https://issues.redhat.com/browse/RHEL-78152 commit 11f8b80ab9f99291dc88d09855b9f8f43b772335 Author: Ruben Devos <devosruben6@gmail.com> Date: Sat Jan 18 21:03:30 2025 +0100 smb: client: fix order of arguments of tracepoints The tracepoints based on smb3_inf_compound_*_class have tcon id and session id swapped around. This results in incorrect output in `trace-cmd report`. Fix the order of arguments to resolve this issue. The trace-cmd output below shows the before and after of the smb3_delete_enter and smb3_delete_done events as an example. The smb3_cmd_* events show the correct session and tcon id for reference. Also fix tracepoint set -> get in the SMB2_OP_GET_REPARSE case. BEFORE: rm-2211 [001] ..... 1839.550888: smb3_delete_enter: xid=281 sid=0x5 tid=0x3d path=\hello2.txt rm-2211 [001] ..... 1839.550894: smb3_cmd_enter: sid=0x1ac000000003d tid=0x5 cmd=5 mid=61 rm-2211 [001] ..... 1839.550896: smb3_cmd_enter: sid=0x1ac000000003d tid=0x5 cmd=6 mid=62 rm-2211 [001] ..... 1839.552091: smb3_cmd_done: sid=0x1ac000000003d tid=0x5 cmd=5 mid=61 rm-2211 [001] ..... 1839.552093: smb3_cmd_done: sid=0x1ac000000003d tid=0x5 cmd=6 mid=62 rm-2211 [001] ..... 1839.552103: smb3_delete_done: xid=281 sid=0x5 tid=0x3d AFTER: rm-2501 [001] ..... 3237.656110: smb3_delete_enter: xid=88 sid=0x1ac0000000041 tid=0x5 path=\hello2.txt rm-2501 [001] ..... 3237.656122: smb3_cmd_enter: sid=0x1ac0000000041 tid=0x5 cmd=5 mid=84 rm-2501 [001] ..... 3237.656123: smb3_cmd_enter: sid=0x1ac0000000041 tid=0x5 cmd=6 mid=85 rm-2501 [001] ..... 3237.657909: smb3_cmd_done: sid=0x1ac0000000041 tid=0x5 cmd=5 mid=84 rm-2501 [001] ..... 3237.657909: smb3_cmd_done: sid=0x1ac0000000041 tid=0x5 cmd=6 mid=85 rm-2501 [001] ..... 3237.657922: smb3_delete_done: xid=88 sid=0x1ac0000000041 tid=0x5 Cc: stable@vger.kernel.org Signed-off-by:
Ruben Devos <devosruben6@gmail.com> Signed-off-by:
-
Paulo Alcantara authored
JIRA: https://issues.redhat.com/browse/RHEL-78152 commit be7a6a77669588bfa5022a470989702bbbb11e7f Author: Paulo Alcantara <pc@manguebit.com> Date: Thu Jan 16 14:29:03 2025 -0300 smb: client: fix oops due to unset link speed It isn't guaranteed that NETWORK_INTERFACE_INFO::LinkSpeed will always be set by the server, so the client must handle any values and then prevent oopses like below from happening: Oops: divide error: 0000 [#1] PREEMPT SMP KASAN NOPTI CPU: 0 UID: 0 PID: 1323 Comm: cat Not tainted 6.13.0-rc7 #2 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-3.fc41 04/01/2014 RIP: 0010:cifs_debug_data_proc_show+0xa45/0x1460 [cifs] Code: 00 00 48 89 df e8 3b cd 1b c1 41 f6 44 24 2c 04 0f 84 50 01 00 00 48 89 ef e8 e7 d0 1b c1 49 8b 44 24 18 31 d2 49 8d 7c 24 28 <48> f7 74 24 18 48 89 c3 e8 6e cf 1b c1 41 8b 6c 24 28 49 8d 7c 24 RSP: 0018:ffffc90001817be0 EFLAGS: 00010246 RAX: 0000000000000000 RBX: ffff88811230022c RCX: ffffffffc041bd99 RDX: 0000000000000000 RSI: 0000000000000567 RDI: ffff888112300228 RBP: ffff888112300218 R08: fffff52000302f5f R09: ffffed1022fa58ac R10: ffff888117d2c566 R11: 00000000fffffffe R12: ffff888112300200 R13: 000000012a15343f R14: 0000000000000001 R15: ffff888113f2db58 FS: 00007fe27119e740(0000) GS:ffff888148600000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007fe2633c5000 CR3: 0000000124da0000 CR4: 0000000000750ef0 PKRU: 55555554 Call Trace: <TASK> ? __die_body.cold+0x19/0x27 ? die+0x2e/0x50 ? do_trap+0x159/0x1b0 ? cifs_debug_data_proc_show+0xa45/0x1460 [cifs] ? do_error_trap+0x90/0x130 ? cifs_debug_data_proc_show+0xa45/0x1460 [cifs] ? exc_divide_error+0x39/0x50 ? cifs_debug_data_proc_show+0xa45/0x1460 [cifs] ? asm_exc_divide_error+0x1a/0x20 ? cifs_debug_data_proc_show+0xa39/0x1460 [cifs] ? cifs_debug_data_proc_show+0xa45/0x1460 [cifs] ? seq_read_iter+0x42e/0x790 seq_read_iter+0x19a/0x790 proc_reg_read_iter+0xbe/0x110 ? __pfx_proc_reg_read_iter+0x10/0x10 vfs_read+0x469/0x570 ? do_user_addr_fault+0x398/0x760 ? __pfx_vfs_read+0x10/0x10 ? find_held_lock+0x8a/0xa0 ? __pfx_lock_release+0x10/0x10 ksys_read+0xd3/0x170 ? __pfx_ksys_read+0x10/0x10 ? __rcu_read_unlock+0x50/0x270 ? mark_held_locks+0x1a/0x90 do_syscall_64+0xbb/0x1d0 entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0033:0x7fe271288911 Code: 00 48 8b 15 01 25 10 00 f7 d8 64 89 02 b8 ff ff ff ff eb bd e8 20 ad 01 00 f3 0f 1e fa 80 3d b5 a7 10 00 00 74 13 31 c0 0f 05 <48> 3d 00 f0 ff ff 77 4f c3 66 0f 1f 44 00 00 55 48 89 e5 48 83 ec RSP: 002b:00007ffe87c079d8 EFLAGS: 00000246 ORIG_RAX: 0000000000000000 RAX: ffffffffffffffda RBX: 0000000000040000 RCX: 00007fe271288911 RDX: 0000000000040000 RSI: 00007fe2633c6000 RDI: 0000000000000003 RBP: 00007ffe87c07a00 R08: 0000000000000000 R09: 00007fe2713e6380 R10: 0000000000000022 R11: 0000000000000246 R12: 0000000000040000 R13: 00007fe2633c6000 R14: 0000000000000003 R15: 0000000000000000 </TASK> Fix this by setting cifs_server_iface::speed to a sane value (1Gbps) by default when link speed is unset. Cc: Shyam Prasad N <nspmangalore@gmail.com> Cc: Tom Talpey <tom@talpey.com> Fixes: a6d8fb54 ("cifs: distribute channels across interfaces based on speed") Reported-by:
Frank Sorenson <sorenson@redhat.com> Reported-by:
-
Paulo Alcantara authored
JIRA: https://issues.redhat.com/browse/RHEL-78152 commit 215b7f9ecb8d7c14d56febdcdd246f3579c32aba Author: Liang Jie <liangjie@lixiang.com> Date: Sat Jan 18 20:35:28 2025 +0800 smb: client: correctly handle ErrorContextData as a flexible array The `smb2_symlink_err_rsp` structure was previously defined with `ErrorContextData` as a single `__u8` byte. However, the `ErrorContextData` field is intended to be a variable-length array based on `ErrorDataLength`. This mismatch leads to incorrect pointer arithmetic and potential memory access issues when processing error contexts. Updates the `ErrorContextData` field to be a flexible array (`__u8 ErrorContextData[]`). Additionally, it modifies the corresponding casts in the `symlink_data()` function to properly handle the flexible array, ensuring correct memory calculations and data handling. These changes improve the robustness of SMB2 symlink error processing. Signed-off-by:
Liang Jie <liangjie@lixiang.com> Suggested-by:
Tom Talpey <tom@talpey.com> Signed-off-by:
-
Paulo Alcantara authored
JIRA: https://issues.redhat.com/browse/RHEL-78152 commit 48aa99523e88e5792edc007e0c7f89faffacc5f7 Author: Paulo Alcantara <pc@manguebit.com> Date: Mon Jan 13 19:00:29 2025 -0300 smb: client: don't retry DFS targets on server shutdown If TCP Server is about to be destroyed (e.g. CifsExiting was set) and it is reconnecting, stop retrying DFS targets from cached DFS referral as this would potentially delay server shutdown in several seconds. Signed-off-by:
-
Paulo Alcantara authored
JIRA: https://issues.redhat.com/browse/RHEL-78152 commit bfc1155030151912e7c5426449c7703dad45a890 Author: Paulo Alcantara <pc@manguebit.com> Date: Fri Jan 10 16:45:44 2025 -0300 smb: client: fix return value of parse_dfs_referrals() Return -ENOENT in parse_dfs_referrals() when server returns no targets for a referral request as specified in MS-DFSC 3.1.5.4.3 Receiving a Root Referral Response or Link Referral Response: > If the referral request is successful, but the NumberOfReferrals > field in the referral header (as specified in section 2.2.4) is > 0, the DFS server could not find suitable targets to return to > the client. In this case, the client MUST fail the original I/O > operation with STATUS_OBJECT_PATH_NOT_FOUND. Signed-off-by:
-
Paulo Alcantara authored
JIRA: https://issues.redhat.com/browse/RHEL-78152 commit 5433c629e8d4eee77233a2bc88075886dc6e37ef Author: Paulo Alcantara <pc@manguebit.com> Date: Fri Jan 10 15:58:08 2025 -0300 smb: client: optimize referral walk on failed link targets If a link referral request sent to root server was successful but client failed to connect to all link targets, there is no need to retry same link referral on a different root server. Set an end marker for the DFS root referral so the client will not attempt to re-send link referrals to different root servers on failures. Signed-off-by:
-
Paulo Alcantara authored
JIRA: https://issues.redhat.com/browse/RHEL-78152 commit 4b1b4c8be9dee9aa1a751cfa3954b2fcfdfe9c3d Author: Paulo Alcantara <pc@manguebit.com> Date: Tue Jan 7 12:22:50 2025 -0300 smb: client: provide dns_resolve_{unc,name} helpers Some places pass hostnames rather than UNC paths to resolve them to ip addresses, so provide helpers to handle both cases and then stop converting hostnames to UNC paths by inserting path delimiters into them. Also kill @expiry parameter as it's not used anywhere. Signed-off-by:
-
