August 2024 - Linux-stable-mirror

[4.19 v2] filelock: Correct the filelock owner in fcntl_setlk/fcntl_setlk64

by Long Li

The locks_remove_posix() function in fcntl_setlk/fcntl_setlk64 is designed to reliably remove locks when an fcntl/close race is detected. However, it was passing in the wrong filelock owner, it looks like a mistake and resulting in a failure to remove locks. More critically, if the lock removal fails, it could lead to a uaf issue while traversing the locks. This problem occurs only in the 4.19/5.4 stable version. Fixes: a561145f3ae9 ("filelock: Fix fcntl/close race recovery compat path") Fixes: d30ff3304083 ("filelock: Remove locks reliably when fcntl/close race is detected") Cc: stable(a)vger.kernel.org Signed-off-by: Long Li <leo.lilong(a)huawei.com> --- fs/locks.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/fs/locks.c b/fs/locks.c index 234ebfa8c070..b1201b01867a 100644 --- a/fs/locks.c +++ b/fs/locks.c @@ -2313,7 +2313,7 @@ int fcntl_setlk(unsigned int fd, struct file *filp, unsigned int cmd, f = fcheck(fd); spin_unlock(&current->files->file_lock); if (f != filp) { - locks_remove_posix(filp, &current->files); + locks_remove_posix(filp, current->files); error = -EBADF; } } @@ -2443,7 +2443,7 @@ int fcntl_setlk64(unsigned int fd, struct file *filp, unsigned int cmd, f = fcheck(fd); spin_unlock(&current->files->file_lock); if (f != filp) { - locks_remove_posix(filp, &current->files); + locks_remove_posix(filp, current->files); error = -EBADF; } } -- 2.39.2

8 months, 2 weeks

1
0
0 0

[obsolete] lib-stackdepot-double-depot_pools_cap-if-kasan-is-enabled.patch removed from -mm tree

by Andrew Morton

The quilt patch titled Subject: lib/stackdepot: double DEPOT_POOLS_CAP if KASAN is enabled has been removed from the -mm tree. Its filename was lib-stackdepot-double-depot_pools_cap-if-kasan-is-enabled.patch This patch was dropped because it is obsolete ------------------------------------------------------ From: Waiman Long <longman(a)redhat.com> Subject: lib/stackdepot: double DEPOT_POOLS_CAP if KASAN is enabled Date: Wed, 7 Aug 2024 12:52:28 -0400 When a wide variety of workloads are run on a debug kernel with KASAN enabled, the following warning may sometimes be printed. [ 6818.650674] Stack depot reached limit capacity [ 6818.650730] WARNING: CPU: 1 PID: 272741 at lib/stackdepot.c:252 depot_alloc_stack+0x39e/0x3d0 : [ 6818.650907] Call Trace: [ 6818.650909] [<00047dd453d84b92>] depot_alloc_stack+0x3a2/0x3d0 [ 6818.650916] [<00047dd453d85254>] stack_depot_save_flags+0x4f4/0x5c0 [ 6818.650920] [<00047dd4535872c6>] kasan_save_stack+0x56/0x70 [ 6818.650924] [<00047dd453587328>] kasan_save_track+0x28/0x40 [ 6818.650927] [<00047dd45358a27a>] kasan_save_free_info+0x4a/0x70 [ 6818.650930] [<00047dd45358766a>] __kasan_slab_free+0x12a/0x1d0 [ 6818.650933] [<00047dd45350deb4>] kmem_cache_free+0x1b4/0x580 [ 6818.650938] [<00047dd452c520da>] __put_task_struct+0x24a/0x320 [ 6818.650945] [<00047dd452c6aee4>] delayed_put_task_struct+0x294/0x350 [ 6818.650949] [<00047dd452e9066a>] rcu_do_batch+0x6ea/0x2090 [ 6818.650953] [<00047dd452ea60f4>] rcu_core+0x474/0xa90 [ 6818.650956] [<00047dd452c780c0>] handle_softirqs+0x3c0/0xf90 [ 6818.650960] [<00047dd452c76fbe>] __irq_exit_rcu+0x35e/0x460 [ 6818.650963] [<00047dd452c79992>] irq_exit_rcu+0x22/0xb0 [ 6818.650966] [<00047dd454bd8128>] do_ext_irq+0xd8/0x120 [ 6818.650972] [<00047dd454c0ddd0>] ext_int_handler+0xb8/0xe8 [ 6818.650979] [<00047dd453589cf6>] kasan_check_range+0x236/0x2f0 [ 6818.650982] [<00047dd453378cf0>] filemap_get_pages+0x190/0xaa0 [ 6818.650986] [<00047dd453379940>] filemap_read+0x340/0xa70 [ 6818.650989] [<00047dd3d325d226>] xfs_file_buffered_read+0x2c6/0x400 [xfs] [ 6818.651431] [<00047dd3d325dfe2>] xfs_file_read_iter+0x2c2/0x550 [xfs] [ 6818.651663] [<00047dd45364710c>] vfs_read+0x64c/0x8c0 [ 6818.651669] [<00047dd453648ed8>] ksys_read+0x118/0x200 [ 6818.651672] [<00047dd452b6cf5a>] do_syscall+0x27a/0x380 [ 6818.651676] [<00047dd454bd7e74>] __do_syscall+0xf4/0x1a0 [ 6818.651680] [<00047dd454c0db58>] system_call+0x70/0x98 As KASAN is a big user of stackdepot, the current DEPOT_POOLS_CAP of 8192 may not be enough. Double DEPOT_POOLS_CAP if KASAN is enabled to avoid hitting this problem. Also use the MIN() macro for defining DEPOT_MAX_POOLS to clarify the intention. Link: https://lkml.kernel.org/r/20240807165228.1116831-1-longman@redhat.com Fixes: 02754e0a484a ("lib/stackdepot.c: bump stackdepot capacity from 16MB to 128MB") Signed-off-by: Waiman Long <longman(a)redhat.com> Cc: Andrey Konovalov <andreyknvl(a)google.com> Cc: Andrey Ryabinin <ryabinin.a.a(a)gmail.com> Cc: <stable(a)vger.kernel.org> Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> --- lib/stackdepot.c | 7 ++++--- 1 file changed, 4 insertions(+), 3 deletions(-) --- a/lib/stackdepot.c~lib-stackdepot-double-depot_pools_cap-if-kasan-is-enabled +++ a/lib/stackdepot.c @@ -36,11 +36,12 @@ #include <linux/memblock.h> #include <linux/kasan-enabled.h> -#define DEPOT_POOLS_CAP 8192 +/* KASAN is a big user of stackdepot, double the cap if KASAN is enabled */ +#define DEPOT_POOLS_CAP (8192 * (IS_ENABLED(CONFIG_KASAN) ? 2 : 1)) + /* The pool_index is offset by 1 so the first record does not have a 0 handle. */ #define DEPOT_MAX_POOLS \ - (((1LL << (DEPOT_POOL_INDEX_BITS)) - 1 < DEPOT_POOLS_CAP) ? \ - (1LL << (DEPOT_POOL_INDEX_BITS)) - 1 : DEPOT_POOLS_CAP) + MIN((1LL << (DEPOT_POOL_INDEX_BITS)) - 1, DEPOT_POOLS_CAP) static bool stack_depot_disabled; static bool __stack_depot_early_init_requested __initdata = IS_ENABLED(CONFIG_STACKDEPOT_ALWAYS_INIT); _ Patches currently in -mm which might be from longman(a)redhat.com are mm-memory-failure-use-raw_spinlock_t-in-struct-memory_failure_cpu.patch mm-memory-failure-use-raw_spinlock_t-in-struct-memory_failure_cpu-v3.patch watchdog-handle-the-enodev-failure-case-of-lockup_detector_delay_init-separately.patch

8 months, 2 weeks

1
0
0 0

[PATCH 4.19] filelock: Correct the filelock owner in fcntl_setlk/fcntl_setlk64

by Long Li

The locks_remove_posix() function in fcntl_setlk/fcntl_setlk64 is designed to reliably remove locks when an fcntl/close race is detected. However, it was passing in the wrong filelock owner, it looks like a mistake and resulting in a failure to remove locks. More critically, if the lock removal fails, it could lead to a uaf issue while traversing the locks. This problem occurs only in the 4.19 stable version. Fixes: a561145f3ae9 ("filelock: Fix fcntl/close race recovery compat path") Fixes: d30ff3304083 ("filelock: Remove locks reliably when fcntl/close race is detected") Cc: stable(a)vger.kernel.org Signed-off-by: Long Li <leo.lilong(a)huawei.com> --- fs/locks.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/fs/locks.c b/fs/locks.c index 234ebfa8c070..b1201b01867a 100644 --- a/fs/locks.c +++ b/fs/locks.c @@ -2313,7 +2313,7 @@ int fcntl_setlk(unsigned int fd, struct file *filp, unsigned int cmd, f = fcheck(fd); spin_unlock(&current->files->file_lock); if (f != filp) { - locks_remove_posix(filp, &current->files); + locks_remove_posix(filp, current->files); error = -EBADF; } } @@ -2443,7 +2443,7 @@ int fcntl_setlk64(unsigned int fd, struct file *filp, unsigned int cmd, f = fcheck(fd); spin_unlock(&current->files->file_lock); if (f != filp) { - locks_remove_posix(filp, &current->files); + locks_remove_posix(filp, current->files); error = -EBADF; } } -- 2.39.2

8 months, 2 weeks

1
0
0 0

+ mm-slub-add-check-for-s-flags-in-the-alloc_tagging_slab_free_hook.patch added to mm-hotfixes-unstable branch

by Andrew Morton

The patch titled Subject: mm/slub: add check for s->flags in the alloc_tagging_slab_free_hook has been added to the -mm mm-hotfixes-unstable branch. Its filename is mm-slub-add-check-for-s-flags-in-the-alloc_tagging_slab_free_hook.patch This patch will shortly appear at https://git.kernel.org/pub/scm/linux/kernel/git/akpm/25-new.git/tree/patche… This patch will later appear in the mm-hotfixes-unstable branch at git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm Before you just go and hit "reply", please: a) Consider who else should be cc'ed b) Prefer to cc a suitable mailing list as well c) Ideally: find the original patch on the mailing list and do a reply-to-all to that, adding suitable additional cc's *** Remember to use Documentation/process/submit-checklist.rst when testing your code *** The -mm tree is included into linux-next via the mm-everything branch at git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm and is updated there every 2-3 working days ------------------------------------------------------ From: Hao Ge <gehao(a)kylinos.cn> Subject: mm/slub: add check for s->flags in the alloc_tagging_slab_free_hook Date: Fri, 16 Aug 2024 09:33:36 +0800 When enable CONFIG_MEMCG & CONFIG_KFENCE & CONFIG_KMEMLEAK, the following warning always occurs,This is because the following call stack occurred: mem_pool_alloc kmem_cache_alloc_noprof slab_alloc_node kfence_alloc Once the kfence allocation is successful,slab->obj_exts will not be empty, because it has already been assigned a value in kfence_init_pool. Since in the prepare_slab_obj_exts_hook function,we perform a check for s->flags & (SLAB_NO_OBJ_EXT | SLAB_NOLEAKTRACE),the alloc_tag_add function will not be called as a result.Therefore,ref->ct remains NULL. However,when we call mem_pool_free,since obj_ext is not empty, it eventually leads to the alloc_tag_sub scenario being invoked. This is where the warning occurs. So we should add corresponding checks in the alloc_tagging_slab_free_hook. For __GFP_NO_OBJ_EXT case,I didn't see the specific case where it's using kfence,so I won't add the corresponding check in alloc_tagging_slab_free_hook for now. [ 3.734349] ------------[ cut here ]------------ [ 3.734807] alloc_tag was not set [ 3.735129] WARNING: CPU: 4 PID: 40 at ./include/linux/alloc_tag.h:130 kmem_cache_free+0x444/0x574 [ 3.735866] Modules linked in: autofs4 [ 3.736211] CPU: 4 UID: 0 PID: 40 Comm: ksoftirqd/4 Tainted: G W 6.11.0-rc3-dirty #1 [ 3.736969] Tainted: [W]=WARN [ 3.737258] Hardware name: QEMU KVM Virtual Machine, BIOS unknown 2/2/2022 [ 3.737875] pstate: 60400005 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 3.738501] pc : kmem_cache_free+0x444/0x574 [ 3.738951] lr : kmem_cache_free+0x444/0x574 [ 3.739361] sp : ffff80008357bb60 [ 3.739693] x29: ffff80008357bb70 x28: 0000000000000000 x27: 0000000000000000 [ 3.740338] x26: ffff80008207f000 x25: ffff000b2eb2fd60 x24: ffff0000c0005700 [ 3.740982] x23: ffff8000804229e4 x22: ffff800082080000 x21: ffff800081756000 [ 3.741630] x20: fffffd7ff8253360 x19: 00000000000000a8 x18: ffffffffffffffff [ 3.742274] x17: ffff800ab327f000 x16: ffff800083398000 x15: ffff800081756df0 [ 3.742919] x14: 0000000000000000 x13: 205d344320202020 x12: 5b5d373038343337 [ 3.743560] x11: ffff80008357b650 x10: 000000000000005d x9 : 00000000ffffffd0 [ 3.744231] x8 : 7f7f7f7f7f7f7f7f x7 : ffff80008237bad0 x6 : c0000000ffff7fff [ 3.744907] x5 : ffff80008237ba78 x4 : ffff8000820bbad0 x3 : 0000000000000001 [ 3.745580] x2 : 68d66547c09f7800 x1 : 68d66547c09f7800 x0 : 0000000000000000 [ 3.746255] Call trace: [ 3.746530] kmem_cache_free+0x444/0x574 [ 3.746931] mem_pool_free+0x44/0xf4 [ 3.747306] free_object_rcu+0xc8/0xdc [ 3.747693] rcu_do_batch+0x234/0x8a4 [ 3.748075] rcu_core+0x230/0x3e4 [ 3.748424] rcu_core_si+0x14/0x1c [ 3.748780] handle_softirqs+0x134/0x378 [ 3.749189] run_ksoftirqd+0x70/0x9c [ 3.749560] smpboot_thread_fn+0x148/0x22c [ 3.749978] kthread+0x10c/0x118 [ 3.750323] ret_from_fork+0x10/0x20 [ 3.750696] ---[ end trace 0000000000000000 ]--- Link: https://lkml.kernel.org/r/20240816013336.17505-1-hao.ge@linux.dev Fixes: 4b8736964640 ("mm/slab: add allocation accounting into slab allocation and free paths") Signed-off-by: Hao Ge <gehao(a)kylinos.cn> Cc: Christoph Lameter <cl(a)linux.com> Cc: David Rientjes <rientjes(a)google.com> Cc: Hyeonggon Yoo <42.hyeyoo(a)gmail.com> Cc: Joonsoo Kim <iamjoonsoo.kim(a)lge.com> Cc: Kees Cook <kees(a)kernel.org> Cc: Kent Overstreet <kent.overstreet(a)linux.dev> Cc: Pekka Enberg <penberg(a)kernel.org> Cc: Roman Gushchin <roman.gushchin(a)linux.dev> Cc: Suren Baghdasaryan <surenb(a)google.com> Cc: Vlastimil Babka <vbabka(a)suse.cz> Cc: <stable(a)vger.kernel.org> Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> --- mm/slub.c | 4 ++++ 1 file changed, 4 insertions(+) --- a/mm/slub.c~mm-slub-add-check-for-s-flags-in-the-alloc_tagging_slab_free_hook +++ a/mm/slub.c @@ -2116,6 +2116,10 @@ alloc_tagging_slab_free_hook(struct kmem if (!mem_alloc_profiling_enabled()) return; + /* slab->obj_exts might not be NULL if it was created for MEMCG accounting. */ + if (s->flags & (SLAB_NO_OBJ_EXT | SLAB_NOLEAKTRACE)) + return; + obj_exts = slab_obj_exts(slab); if (!obj_exts) return; _ Patches currently in -mm which might be from gehao(a)kylinos.cn are mm-slub-add-check-for-s-flags-in-the-alloc_tagging_slab_free_hook.patch mm-cma-change-the-addition-of-totalcma_pages-in-the-cma_init_reserved_mem.patch

8 months, 3 weeks

1
0
0 0

[PATCH] perf hist: Update hist symbol when updating maps

by Matt Fleming

AddressSanitizer found a use-after-free bug in the symbol code which manifested as perf top segfaulting. ==1238389==ERROR: AddressSanitizer: heap-use-after-free on address 0x60b00c48844b at pc 0x5650d8035961 bp 0x7f751aaecc90 sp 0x7f751aaecc80 READ of size 1 at 0x60b00c48844b thread T193 #0 0x5650d8035960 in _sort__sym_cmp util/sort.c:310 #1 0x5650d8043744 in hist_entry__cmp util/hist.c:1286 #2 0x5650d8043951 in hists__findnew_entry util/hist.c:614 #3 0x5650d804568f in __hists__add_entry util/hist.c:754 #4 0x5650d8045bf9 in hists__add_entry util/hist.c:772 #5 0x5650d8045df1 in iter_add_single_normal_entry util/hist.c:997 #6 0x5650d8043326 in hist_entry_iter__add util/hist.c:1242 #7 0x5650d7ceeefe in perf_event__process_sample /home/matt/src/linux/tools/perf/builtin-top.c:845 #8 0x5650d7ceeefe in deliver_event /home/matt/src/linux/tools/perf/builtin-top.c:1208 #9 0x5650d7fdb51b in do_flush util/ordered-events.c:245 #10 0x5650d7fdb51b in __ordered_events__flush util/ordered-events.c:324 #11 0x5650d7ced743 in process_thread /home/matt/src/linux/tools/perf/builtin-top.c:1120 #12 0x7f757ef1f133 in start_thread nptl/pthread_create.c:442 #13 0x7f757ef9f7db in clone3 ../sysdeps/unix/sysv/linux/x86_64/clone3.S:81 When updating hist maps it's also necessary to update the hist symbol reference because the old one gets freed in map__put(). While this bug was probably introduced with 5c24b67aae72 ("perf tools: Replace map->referenced & maps->removed_maps with map->refcnt"), the symbol objects were leaked until c087e9480cf3 ("perf machine: Fix refcount usage when processing PERF_RECORD_KSYMBOL") was merged so the bug was masked. Fixes: c087e9480cf3 ("perf machine: Fix refcount usage when processing PERF_RECORD_KSYMBOL") Signed-off-by: Matt Fleming (Cloudflare) <matt(a)readmodwrite.com> Reported-by: Yunzhao Li <yunzhao(a)cloudflare.com> Cc: stable(a)vger.kernel.org # v5.13+ --- tools/perf/util/hist.c | 5 +++++ 1 file changed, 5 insertions(+) diff --git a/tools/perf/util/hist.c b/tools/perf/util/hist.c index 0f554febf9a1..0f9ce2ee2c31 100644 --- a/tools/perf/util/hist.c +++ b/tools/perf/util/hist.c @@ -639,6 +639,11 @@ static struct hist_entry *hists__findnew_entry(struct hists *hists, * the history counter to increment. */ if (he->ms.map != entry->ms.map) { + if (he->ms.sym) { + u64 addr = he->ms.sym->start; + he->ms.sym = map__find_symbol(entry->ms.map, addr); + } + map__put(he->ms.map); he->ms.map = map__get(entry->ms.map); } -- 2.34.1

8 months, 3 weeks

3
2
0 0

FAILED: patch "[PATCH] scsi: mpt3sas: Avoid IOMMU page faults on REPORT ZONES" failed to apply to 5.4-stable tree

by gregkh＠linuxfoundation.org

The patch below does not apply to the 5.4-stable tree. If someone wants it applied there, or to any other stable or longterm tree, then please email the backport, including the original git commit id to <stable(a)vger.kernel.org>. To reproduce the conflict and resubmit, you may use the following commands: git fetch https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/ linux-5.4.y git checkout FETCH_HEAD git cherry-pick -x 82dbb57ac8d06dfe8227ba9ab11a49de2b475ae5 # <resolve conflicts, build, test, etc.> git commit -s git send-email --to '<stable(a)vger.kernel.org>' --in-reply-to '2024081113-creamed-unleaded-c696@gregkh' --subject-prefix 'PATCH 5.4.y' HEAD^.. Possible dependencies: 82dbb57ac8d0 ("scsi: mpt3sas: Avoid IOMMU page faults on REPORT ZONES") 0c25422d34b4 ("scsi: mpt3sas: Remove scsi_dma_map() error messages") thanks, greg k-h ------------------ original commit in Linus's tree ------------------ From 82dbb57ac8d06dfe8227ba9ab11a49de2b475ae5 Mon Sep 17 00:00:00 2001 From: Damien Le Moal <dlemoal(a)kernel.org> Date: Fri, 19 Jul 2024 16:39:12 +0900 Subject: [PATCH] scsi: mpt3sas: Avoid IOMMU page faults on REPORT ZONES Some firmware versions of the 9600 series SAS HBA byte-swap the REPORT ZONES command reply buffer from ATA-ZAC devices by directly accessing the buffer in the host memory. This does not respect the default command DMA direction and causes IOMMU page faults on architectures with an IOMMU enforcing write-only mappings for DMA_FROM_DEVICE DMA driection (e.g. AMD hosts). scsi 18:0:0:0: Direct-Access-ZBC ATA WDC WSH722020AL W870 PQ: 0 ANSI: 6 scsi 18:0:0:0: SATA: handle(0x0027), sas_addr(0x300062b2083e7c40), phy(0), device_name(0x5000cca29dc35e11) scsi 18:0:0:0: enclosure logical id (0x300062b208097c40), slot(0) scsi 18:0:0:0: enclosure level(0x0000), connector name( C0.0) scsi 18:0:0:0: atapi(n), ncq(y), asyn_notify(n), smart(y), fua(y), sw_preserve(y) scsi 18:0:0:0: qdepth(32), tagged(1), scsi_level(7), cmd_que(1) sd 18:0:0:0: Attached scsi generic sg2 type 20 sd 18:0:0:0: [sdc] Host-managed zoned block device mpt3sas 0000:41:00.0: AMD-Vi: Event logged [IO_PAGE_FAULT domain=0x0021 address=0xfff9b200 flags=0x0050] mpt3sas 0000:41:00.0: AMD-Vi: Event logged [IO_PAGE_FAULT domain=0x0021 address=0xfff9b300 flags=0x0050] mpt3sas_cm0: mpt3sas_ctl_pre_reset_handler: Releasing the trace buffer due to adapter reset. mpt3sas_cm0 fault info from func: mpt3sas_base_make_ioc_ready mpt3sas_cm0: fault_state(0x2666)! mpt3sas_cm0: sending diag reset !! mpt3sas_cm0: diag reset: SUCCESS sd 18:0:0:0: [sdc] REPORT ZONES start lba 0 failed sd 18:0:0:0: [sdc] REPORT ZONES: Result: hostbyte=DID_RESET driverbyte=DRIVER_OK sd 18:0:0:0: [sdc] 0 4096-byte logical blocks: (0 B/0 B) Avoid such issue by always mapping the buffer of REPORT ZONES commands using DMA_BIDIRECTIONAL (read+write IOMMU mapping). This is done by introducing the helper function _base_scsi_dma_map() and using this helper in _base_build_sg_scmd() and _base_build_sg_scmd_ieee() instead of calling directly scsi_dma_map(). Fixes: 471ef9d4e498 ("mpt3sas: Build MPI SGL LIST on GEN2 HBAs and IEEE SGL LIST on GEN3 HBAs") Cc: stable(a)vger.kernel.org Signed-off-by: Damien Le Moal <dlemoal(a)kernel.org> Link: https://lore.kernel.org/r/20240719073913.179559-3-dlemoal@kernel.org Reviewed-by: Christoph Hellwig <hch(a)lst.de> Reviewed-by: Johannes Thumshirn <johannes.thumshirn(a)wdc.com> Signed-off-by: Martin K. Petersen <martin.petersen(a)oracle.com> diff --git a/drivers/scsi/mpt3sas/mpt3sas_base.c b/drivers/scsi/mpt3sas/mpt3sas_base.c index 1092497563b2..c8fb965a6bf0 100644 --- a/drivers/scsi/mpt3sas/mpt3sas_base.c +++ b/drivers/scsi/mpt3sas/mpt3sas_base.c @@ -2671,6 +2671,22 @@ _base_build_zero_len_sge_ieee(struct MPT3SAS_ADAPTER *ioc, void *paddr) _base_add_sg_single_ieee(paddr, sgl_flags, 0, 0, -1); } +static inline int _base_scsi_dma_map(struct scsi_cmnd *cmd) +{ + /* + * Some firmware versions byte-swap the REPORT ZONES command reply from + * ATA-ZAC devices by directly accessing in the host buffer. This does + * not respect the default command DMA direction and causes IOMMU page + * faults on some architectures with an IOMMU enforcing write mappings + * (e.g. AMD hosts). Avoid such issue by making the report zones buffer + * mapping bi-directional. + */ + if (cmd->cmnd[0] == ZBC_IN && cmd->cmnd[1] == ZI_REPORT_ZONES) + cmd->sc_data_direction = DMA_BIDIRECTIONAL; + + return scsi_dma_map(cmd); +} + /** * _base_build_sg_scmd - main sg creation routine * pcie_device is unused here! @@ -2717,7 +2733,7 @@ _base_build_sg_scmd(struct MPT3SAS_ADAPTER *ioc, sgl_flags = sgl_flags << MPI2_SGE_FLAGS_SHIFT; sg_scmd = scsi_sglist(scmd); - sges_left = scsi_dma_map(scmd); + sges_left = _base_scsi_dma_map(scmd); if (sges_left < 0) return -ENOMEM; @@ -2861,7 +2877,7 @@ _base_build_sg_scmd_ieee(struct MPT3SAS_ADAPTER *ioc, } sg_scmd = scsi_sglist(scmd); - sges_left = scsi_dma_map(scmd); + sges_left = _base_scsi_dma_map(scmd); if (sges_left < 0) return -ENOMEM;

8 months, 3 weeks

2
1
0 0

FAILED: patch "[PATCH] scsi: mpt3sas: Avoid IOMMU page faults on REPORT ZONES" failed to apply to 5.10-stable tree

by gregkh＠linuxfoundation.org

The patch below does not apply to the 5.10-stable tree. If someone wants it applied there, or to any other stable or longterm tree, then please email the backport, including the original git commit id to <stable(a)vger.kernel.org>. To reproduce the conflict and resubmit, you may use the following commands: git fetch https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/ linux-5.10.y git checkout FETCH_HEAD git cherry-pick -x 82dbb57ac8d06dfe8227ba9ab11a49de2b475ae5 # <resolve conflicts, build, test, etc.> git commit -s git send-email --to '<stable(a)vger.kernel.org>' --in-reply-to '2024081112-idly-qualify-80f3@gregkh' --subject-prefix 'PATCH 5.10.y' HEAD^.. Possible dependencies: 82dbb57ac8d0 ("scsi: mpt3sas: Avoid IOMMU page faults on REPORT ZONES") 0c25422d34b4 ("scsi: mpt3sas: Remove scsi_dma_map() error messages") thanks, greg k-h ------------------ original commit in Linus's tree ------------------ From 82dbb57ac8d06dfe8227ba9ab11a49de2b475ae5 Mon Sep 17 00:00:00 2001 From: Damien Le Moal <dlemoal(a)kernel.org> Date: Fri, 19 Jul 2024 16:39:12 +0900 Subject: [PATCH] scsi: mpt3sas: Avoid IOMMU page faults on REPORT ZONES Some firmware versions of the 9600 series SAS HBA byte-swap the REPORT ZONES command reply buffer from ATA-ZAC devices by directly accessing the buffer in the host memory. This does not respect the default command DMA direction and causes IOMMU page faults on architectures with an IOMMU enforcing write-only mappings for DMA_FROM_DEVICE DMA driection (e.g. AMD hosts). scsi 18:0:0:0: Direct-Access-ZBC ATA WDC WSH722020AL W870 PQ: 0 ANSI: 6 scsi 18:0:0:0: SATA: handle(0x0027), sas_addr(0x300062b2083e7c40), phy(0), device_name(0x5000cca29dc35e11) scsi 18:0:0:0: enclosure logical id (0x300062b208097c40), slot(0) scsi 18:0:0:0: enclosure level(0x0000), connector name( C0.0) scsi 18:0:0:0: atapi(n), ncq(y), asyn_notify(n), smart(y), fua(y), sw_preserve(y) scsi 18:0:0:0: qdepth(32), tagged(1), scsi_level(7), cmd_que(1) sd 18:0:0:0: Attached scsi generic sg2 type 20 sd 18:0:0:0: [sdc] Host-managed zoned block device mpt3sas 0000:41:00.0: AMD-Vi: Event logged [IO_PAGE_FAULT domain=0x0021 address=0xfff9b200 flags=0x0050] mpt3sas 0000:41:00.0: AMD-Vi: Event logged [IO_PAGE_FAULT domain=0x0021 address=0xfff9b300 flags=0x0050] mpt3sas_cm0: mpt3sas_ctl_pre_reset_handler: Releasing the trace buffer due to adapter reset. mpt3sas_cm0 fault info from func: mpt3sas_base_make_ioc_ready mpt3sas_cm0: fault_state(0x2666)! mpt3sas_cm0: sending diag reset !! mpt3sas_cm0: diag reset: SUCCESS sd 18:0:0:0: [sdc] REPORT ZONES start lba 0 failed sd 18:0:0:0: [sdc] REPORT ZONES: Result: hostbyte=DID_RESET driverbyte=DRIVER_OK sd 18:0:0:0: [sdc] 0 4096-byte logical blocks: (0 B/0 B) Avoid such issue by always mapping the buffer of REPORT ZONES commands using DMA_BIDIRECTIONAL (read+write IOMMU mapping). This is done by introducing the helper function _base_scsi_dma_map() and using this helper in _base_build_sg_scmd() and _base_build_sg_scmd_ieee() instead of calling directly scsi_dma_map(). Fixes: 471ef9d4e498 ("mpt3sas: Build MPI SGL LIST on GEN2 HBAs and IEEE SGL LIST on GEN3 HBAs") Cc: stable(a)vger.kernel.org Signed-off-by: Damien Le Moal <dlemoal(a)kernel.org> Link: https://lore.kernel.org/r/20240719073913.179559-3-dlemoal@kernel.org Reviewed-by: Christoph Hellwig <hch(a)lst.de> Reviewed-by: Johannes Thumshirn <johannes.thumshirn(a)wdc.com> Signed-off-by: Martin K. Petersen <martin.petersen(a)oracle.com> diff --git a/drivers/scsi/mpt3sas/mpt3sas_base.c b/drivers/scsi/mpt3sas/mpt3sas_base.c index 1092497563b2..c8fb965a6bf0 100644 --- a/drivers/scsi/mpt3sas/mpt3sas_base.c +++ b/drivers/scsi/mpt3sas/mpt3sas_base.c @@ -2671,6 +2671,22 @@ _base_build_zero_len_sge_ieee(struct MPT3SAS_ADAPTER *ioc, void *paddr) _base_add_sg_single_ieee(paddr, sgl_flags, 0, 0, -1); } +static inline int _base_scsi_dma_map(struct scsi_cmnd *cmd) +{ + /* + * Some firmware versions byte-swap the REPORT ZONES command reply from + * ATA-ZAC devices by directly accessing in the host buffer. This does + * not respect the default command DMA direction and causes IOMMU page + * faults on some architectures with an IOMMU enforcing write mappings + * (e.g. AMD hosts). Avoid such issue by making the report zones buffer + * mapping bi-directional. + */ + if (cmd->cmnd[0] == ZBC_IN && cmd->cmnd[1] == ZI_REPORT_ZONES) + cmd->sc_data_direction = DMA_BIDIRECTIONAL; + + return scsi_dma_map(cmd); +} + /** * _base_build_sg_scmd - main sg creation routine * pcie_device is unused here! @@ -2717,7 +2733,7 @@ _base_build_sg_scmd(struct MPT3SAS_ADAPTER *ioc, sgl_flags = sgl_flags << MPI2_SGE_FLAGS_SHIFT; sg_scmd = scsi_sglist(scmd); - sges_left = scsi_dma_map(scmd); + sges_left = _base_scsi_dma_map(scmd); if (sges_left < 0) return -ENOMEM; @@ -2861,7 +2877,7 @@ _base_build_sg_scmd_ieee(struct MPT3SAS_ADAPTER *ioc, } sg_scmd = scsi_sglist(scmd); - sges_left = scsi_dma_map(scmd); + sges_left = _base_scsi_dma_map(scmd); if (sges_left < 0) return -ENOMEM;

8 months, 3 weeks

2
1
0 0

[PATCH v4 RESEND] EDAC/ti: Fix possible null pointer dereference in _emif_get_id()

by Ma Ke

In _emif_get_id(), of_get_address() may return NULL which is later dereferenced. Fix this bug by adding NULL check. of_translate_address() is the same. Found by code review. Cc: stable(a)vger.kernel.org Fixes: 86a18ee21e5e ("EDAC, ti: Add support for TI keystone and DRA7xx EDAC") Signed-off-by: Ma Ke <make24(a)iscas.ac.cn> --- Changes in v4: - added the check of of_translate_address() as suggestions. Changes in v3: - added the patch operations omitted in PATCH v2 RESEND compared to PATCH v2. Sorry for my oversight. Changes in v2: - added Cc stable line. --- drivers/edac/ti_edac.c | 10 ++++++++++ 1 file changed, 10 insertions(+) diff --git a/drivers/edac/ti_edac.c b/drivers/edac/ti_edac.c index 29723c9592f7..f466f12630d3 100644 --- a/drivers/edac/ti_edac.c +++ b/drivers/edac/ti_edac.c @@ -207,14 +207,24 @@ static int _emif_get_id(struct device_node *node) int my_id = 0; addrp = of_get_address(node, 0, NULL, NULL); + if (!addrp) + return -EINVAL; + my_addr = (u32)of_translate_address(node, addrp); + if (my_addr == OF_BAD_ADDR) + return -EINVAL; for_each_matching_node(np, ti_edac_of_match) { if (np == node) continue; addrp = of_get_address(np, 0, NULL, NULL); + if (!addrp) + return -EINVAL; + addr = (u32)of_translate_address(np, addrp); + if (addr == OF_BAD_ADDR) + return -EINVAL; edac_printk(KERN_INFO, EDAC_MOD_NAME, "addr=%x, my_addr=%x\n", -- 2.25.1

8 months, 3 weeks

2
1
0 0

+ kunit-overflow-fix-ub-in-overflow_allocation_test.patch added to mm-hotfixes-unstable branch

by Andrew Morton

The patch titled Subject: kunit/overflow: fix UB in overflow_allocation_test has been added to the -mm mm-hotfixes-unstable branch. Its filename is kunit-overflow-fix-ub-in-overflow_allocation_test.patch This patch will shortly appear at https://git.kernel.org/pub/scm/linux/kernel/git/akpm/25-new.git/tree/patche… This patch will later appear in the mm-hotfixes-unstable branch at git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm Before you just go and hit "reply", please: a) Consider who else should be cc'ed b) Prefer to cc a suitable mailing list as well c) Ideally: find the original patch on the mailing list and do a reply-to-all to that, adding suitable additional cc's *** Remember to use Documentation/process/submit-checklist.rst when testing your code *** The -mm tree is included into linux-next via the mm-everything branch at git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm and is updated there every 2-3 working days ------------------------------------------------------ From: Ivan Orlov <ivan.orlov0322(a)gmail.com> Subject: kunit/overflow: fix UB in overflow_allocation_test Date: Thu, 15 Aug 2024 01:04:31 +0100 The 'device_name' array doesn't exist out of the 'overflow_allocation_test' function scope. However, it is being used as a driver name when calling 'kunit_driver_create' from 'kunit_device_register'. It produces the kernel panic with KASAN enabled. Since this variable is used in one place only, remove it and pass the device name into kunit_device_register directly as an ascii string. Link: https://lkml.kernel.org/r/20240815000431.401869-1-ivan.orlov0322@gmail.com Fixes: ca90800a91ba ("test_overflow: Add memory allocation overflow tests") Signed-off-by: Ivan Orlov <ivan.orlov0322(a)gmail.com> Tested-by: Erhard Furtner <erhard_f(a)mailbox.org> Reviewed-by: David Gow <davidgow(a)google.com> Cc: Kees Cook <kees(a)kernel.org> Cc: <stable(a)vger.kernel.org> Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> --- lib/overflow_kunit.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) --- a/lib/overflow_kunit.c~kunit-overflow-fix-ub-in-overflow_allocation_test +++ a/lib/overflow_kunit.c @@ -668,7 +668,6 @@ DEFINE_TEST_ALLOC(devm_kzalloc, devm_kf static void overflow_allocation_test(struct kunit *test) { - const char device_name[] = "overflow-test"; struct device *dev; int count = 0; @@ -678,7 +677,7 @@ static void overflow_allocation_test(str } while (0) /* Create dummy device for devm_kmalloc()-family tests. */ - dev = kunit_device_register(test, device_name); + dev = kunit_device_register(test, "overflow-test"); KUNIT_ASSERT_FALSE_MSG(test, IS_ERR(dev), "Cannot register test device\n"); _ Patches currently in -mm which might be from ivan.orlov0322(a)gmail.com are kunit-overflow-fix-ub-in-overflow_allocation_test.patch

8 months, 3 weeks

1
0
0 0

[PATCH v2] firmware: qcom_scm: Mark get_wq_ctx() as atomic call

by Unnathi Chalicheemala

From: Murali Nalajala <quic_mnalajal(a)quicinc.com> Currently get_wq_ctx() is wrongly configured as a standard call. When two SMC calls are in sleep and one SMC wakes up, it calls get_wq_ctx() to resume the corresponding sleeping thread. But if get_wq_ctx() is interrupted, goes to sleep and another SMC call is waiting to be allocated a waitq context, it leads to a deadlock. To avoid this get_wq_ctx() must be an atomic call and can't be a standard SMC call. Hence mark get_wq_ctx() as a fast call. Fixes: 6bf325992236 ("firmware: qcom: scm: Add wait-queue handling logic") Cc: stable(a)vger.kernel.org Signed-off-by: Murali Nalajala <quic_mnalajal(a)quicinc.com> Signed-off-by: Unnathi Chalicheemala <quic_uchalich(a)quicinc.com> Reviewed-by: Elliot Berman <quic_eberman(a)quicinc.com> --- Changes in v2: - Made commit message more clear. - R-b tag from Elliot. - Link to v1: https://lore.kernel.org/all/20240611-get_wq_ctx_atomic-v1-1-9189a0a7d1ba@qu… drivers/firmware/qcom/qcom_scm-smc.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/firmware/qcom/qcom_scm-smc.c b/drivers/firmware/qcom/qcom_scm-smc.c index dca5f3f1883b..2b4c2826f572 100644 --- a/drivers/firmware/qcom/qcom_scm-smc.c +++ b/drivers/firmware/qcom/qcom_scm-smc.c @@ -73,7 +73,7 @@ int scm_get_wq_ctx(u32 *wq_ctx, u32 *flags, u32 *more_pending) struct arm_smccc_res get_wq_res; struct arm_smccc_args get_wq_ctx = {0}; - get_wq_ctx.args[0] = ARM_SMCCC_CALL_VAL(ARM_SMCCC_STD_CALL, + get_wq_ctx.args[0] = ARM_SMCCC_CALL_VAL(ARM_SMCCC_FAST_CALL, ARM_SMCCC_SMC_64, ARM_SMCCC_OWNER_SIP, SCM_SMC_FNID(QCOM_SCM_SVC_WAITQ, QCOM_SCM_WAITQ_GET_WQ_CTX)); -- 2.34.1

8 months, 3 weeks

2
1
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror August 2024