This project is mirrored from https://gitlab.com/redhat/centos-stream/src/kernel/centos-stream-10.git.
Pull mirroring updated .
- Feb 20, 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/372 Description: updates for cpupower JIRA: https://issues.redhat.com/browse/RHEL-78946 Build Info: https://brewweb.engineering.redhat.com/brew/taskinfo?taskID=66664135 Tested: Successful platform test results on Intel (intel-arrowlake-s-02) system. Signed-off-by:
Steve Best <sbest@redhat.com> Approved-by:
Tony Camuso <tcamuso@redhat.com> Approved-by:
Desnes Nunes <desnesn@redhat.com> Approved-by:
Lenny Szubowicz <lszubowi@redhat.com> Merged-by:
-
Julio Faracco authored
MR: https://gitlab.com/redhat/centos-stream/src/kernel/centos-stream-10/-/merge_requests/376 Description: updates for powercap: intel_rapl JIRA: https://issues.redhat.com/browse/RHEL-79097 Build Info: https://brewweb.engineering.redhat.com/brew/taskinfo?taskID=66676240 Tested: Successful platform test results on Intel (intel-arrowlake-s-02) system. Signed-off-by:
-
Julio Faracco authored
JIRA: INTERNAL Upstream Status: RHEL only Signed-off-by:
-
- Feb 16, 2025
-
-
Jan Stancek authored
Signed-off-by:Jan Stancek <jstancek@redhat.com>
-
Jan Stancek authored
MR: https://gitlab.com/redhat/centos-stream/src/kernel/centos-stream-10/-/merge_requests/317 ovl: support encoding fid from inode with no alias JIRA: https://issues.redhat.com/browse/RHEL-77301 CVE: CVE-2025-21654 Signed-off-by:
Miklos Szeredi <mszeredi@redhat.com> Approved-by:
Ian Kent <ikent@redhat.com> Approved-by:
Carlos Maiolino <cmaiolino@redhat.com> Approved-by:
David Howells <dhowells@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/307 JIRA: https://issues.redhat.com/browse/RHEL-77240 CVE: CVE-2025-21668 ``` pmdomain: imx8mp-blk-ctrl: add missing loop break condition Currently imx8mp_blk_ctrl_remove() will continue the for loop until an out-of-bounds exception occurs. pstate: 60000005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : dev_pm_domain_detach+0x8/0x48 lr : imx8mp_blk_ctrl_shutdown+0x58/0x90 sp : ffffffc084f8bbf0 x29: ffffffc084f8bbf0 x28: ffffff80daf32ac0 x27: 0000000000000000 x26: ffffffc081658d78 x25: 0000000000000001 x24: ffffffc08201b028 x23: ffffff80d0db9490 x22: ffffffc082340a78 x21: 00000000000005b0 x20: ffffff80d19bc180 x19: 000000000000000a x18: ffffffffffffffff x17: ffffffc080a39e08 x16: ffffffc080a39c98 x15: 4f435f464f006c72 x14: 0000000000000004 x13: ffffff80d0172110 x12: 0000000000000000 x11: ffffff80d0537740 x10: ffffff80d05376c0 x9 : ffffffc0808ed2d8 x8 : ffffffc084f8bab0 x7 : 0000000000000000 x6 : 0000000000000000 x5 : ffffff80d19b9420 x4 : fffffffe03466e60 x3 : 0000000080800077 x2 : 0000000000000000 x1 : 0000000000000001 x0 : 0000000000000000 Call trace: dev_pm_domain_detach+0x8/0x48 platform_shutdown+0x2c/0x48 device_shutdown+0x158/0x268 kernel_restart_prepare+0x40/0x58 kernel_kexec+0x58/0xe8 __do_sys_reboot+0x198/0x258 __arm64_sys_reboot+0x2c/0x40 invoke_syscall+0x5c/0x138 el0_svc_common.constprop.0+0x48/0xf0 do_el0_svc+0x24/0x38 el0_svc+0x38/0xc8 el0t_64_sync_handler+0x120/0x130 el0t_64_sync+0x190/0x198 Code: 8128c2d0 ffffffc0 aa1e03e9 d503201f Fixes: 556f5cf9 ("soc: imx: add i.MX8MP HSIO blk-ctrl") Cc: stable@vger.kernel.org Signed-off-by:
Xiaolei Wang <xiaolei.wang@windriver.com> Reviewed-by:
Lucas Stach <l.stach@pengutronix.de> Reviewed-by:
Fabio Estevam <festevam@gmail.com> Reviewed-by:
Frank Li <Frank.Li@nxp.com> Link: https://lore.kernel.org/r/20250115014118.4086729-1-xiaolei.wang@windriver.com Signed-off-by:
Ulf Hansson <ulf.hansson@linaro.org> (cherry picked from commit 726efa92e02b460811e8bc6990dd742f03b645ea) ``` Signed-off-by:
CKI Backport Bot <cki-ci-bot+cki-gitlab-backport-bot@redhat.com> --- <small>Created 2025-01-31 18:55 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:
Jennifer Berringer <jberring@redhat.com> Approved-by:
Radu Rendec <rrendec@redhat.com> Approved-by:
-
Jan Stancek authored
MR: https://gitlab.com/redhat/centos-stream/src/kernel/centos-stream-10/-/merge_requests/368 JIRA: https://issues.redhat.com/browse/RHEL-78677 CVE: CVE-2025-21686 Signed-off-by:
Jeff Moyer <jmoyer@redhat.com> Approved-by:
Ming Lei <ming.lei@redhat.com> Approved-by:
Brian Foster <bfoster@redhat.com> Approved-by:
-
Jan Stancek authored
MR: https://gitlab.com/redhat/centos-stream/src/kernel/centos-stream-10/-/merge_requests/301 JIRA: https://issues.redhat.com/browse/RHEL-77214 CVE: CVE-2025-21666 ``` vsock: prevent null-ptr-deref in vsock_*[has_data|has_space] Recent reports have shown how we sometimes call vsock_*_has_data() when a vsock socket has been de-assigned from a transport (see attached links), but we shouldn't. Previous commits should have solved the real problems, but we may have more in the future, so to avoid null-ptr-deref, we can return 0 (no space, no data available) but with a warning. This way the code should continue to run in a nearly consistent state and have a warning that allows us to debug future problems. Fixes: c0cfa2d8 ("vsock: add multi-transports support") Cc: stable@vger.kernel.org Link: https://lore.kernel.org/netdev/Z2K%2FI4nlHdfMRTZC@v4bel-B760M-AORUS-ELITE-AX/ Link: https://lore.kernel.org/netdev/5ca20d4c-1017-49c2-9516-f6f75fd331e9@rbox.co/ Link: https://lore.kernel.org/netdev/677f84a8.050a0220.25a300.01b3.GAE@google.com/ Co-developed-by:
Hyunwoo Kim <v4bel@theori.io> Signed-off-by:
Wongi Lee <qwerty@theori.io> Signed-off-by:
Stefano Garzarella <sgarzare@redhat.com> Reviewed-by:
Luigi Leonardi <leonardi@redhat.com> Reviewed-by:
Paolo Abeni <pabeni@redhat.com> (cherry picked from commit 91751e248256efc111e52e15115840c35d85abaf) ``` Signed-off-by:
Jon Maloy <jmaloy@redhat.com> Approved-by:
-
Jan Stancek authored
MR: https://gitlab.com/redhat/centos-stream/src/kernel/centos-stream-10/-/merge_requests/365 JIRA: https://issues.redhat.com/browse/RHEL-78685 CVE: CVE-2025-21689 ``` commit 575a5adf48b06a2980c9eeffedf699ed5534fade Author: Qasim Ijaz <qasdev00@gmail.com> Date: Mon Jan 13 18:00:34 2025 +0000 USB: serial: quatech2: fix null-ptr-deref in qt2_process_read_urb() This patch addresses a null-ptr-deref in qt2_process_read_urb() due to an incorrect bounds check in the following: if (newport > serial->num_ports) { dev_err(&port->dev, "%s - port change to invalid port: %i\n", __func__, newport); break; } The condition doesn't account for the valid range of the serial->port buffer, which is from 0 to serial->num_ports - 1. When newport is equal to serial->num_ports, the assignment of "port" in the following code is out-of-bounds and NULL: serial_priv->current_port = newport; port = serial->port[serial_priv->current_port]; The fix checks if newport is greater than or equal to serial->num_ports indicating it is out-of-bounds. Reported-by:
syzbot <syzbot+506479ebf12fe435d01a@syzkaller.appspotmail.com> Closes: https://syzkaller.appspot.com/bug?extid=506479ebf12fe435d01a Fixes: f7a33e60 ("USB: serial: add quatech2 usb to serial driver") Cc: <stable@vger.kernel.org> # 3.5 Signed-off-by:
Qasim Ijaz <qasdev00@gmail.com> Reviewed-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by:
Johan Hovold <johan@kernel.org>```> Signed-off-by:
Daniel Horak <dhorak@redhat.com> Approved-by:
John W. Linville <linville@redhat.com> Approved-by:
-
Jan Stancek authored
MR: https://gitlab.com/redhat/centos-stream/src/kernel/centos-stream-10/-/merge_requests/358 JIRA: https://issues.redhat.com/browse/RHEL-58817 - lazy tlb: fix hotplug exit race with MMU_LAZY_TLB_SHOOTDOWN (Herton R. Krzesinski) [[RHEL-58817](https://issues.redhat.com/browse/RHEL-58817) ] Signed-off-by:
Herton R. Krzesinski <herton@redhat.com> Approved-by:
Waiman Long <longman@redhat.com> Approved-by:
Phil Auld <pauld@redhat.com> Approved-by:
-
- Feb 14, 2025
-
-
Jan Stancek authored
Signed-off-by: -
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:
Aristeu Rozanski <arozansk@redhat.com> Approved-by:
Rafael Aquini <raquini@redhat.com> Approved-by:
Nico Pache <npache@redhat.com> Approved-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:
-
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:
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:
-
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:
-
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:
-
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:
-
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:
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:
-
