October 2024 - Linux-stable-mirror

[PATCH 0/2] rust: lockdep: Fix soundness issue affecting LockClassKeys

by Mitchell Levy via B4 Relay

This series is aimed at fixing a soundness issue with how dynamically allocated LockClassKeys are handled. Currently, LockClassKeys can be used without being Pin'd, which can break lockdep since it relies on address stability. Similarly, these keys are not automatically (de)registered with lockdep. At the suggestion of Alice Ryhl, this series includes a patch for -stable kernels that disables dynamically allocated keys. This prevents backported patches from using the unsound implementation. Currently, this series requires that all dynamically allocated LockClassKeys have a lifetime of 'static (i.e., they must be leaked after allocation). This is because Lock does not currently keep a reference to the LockClassKey, instead passing it to C via FFI. This causes a problem because the rust compiler would allow creating a 'static Lock with a 'a LockClassKey (with 'a < 'static) while C would expect the LockClassKey to live as long as the lock. This problem represents an avenue for future work. --- Changes from RFC: - Split into two commits so that dynamically allocated LockClassKeys are removed from stable kernels. (Thanks Alice Ryhl) - Extract calls to C lockdep functions into helpers so things build properly when LOCKDEP=n. (Thanks Benno Lossin) - Remove extraneous `get_ref()` calls. (Thanks Benno Lossin) - Provide better documentation for `new_dynamic()`. (Thanks Benno Lossin) - Ran rustfmt to fix formatting and some extraneous changes. (Thanks Alice Ryhl and Benno Lossin) - Link to RFC: https://lore.kernel.org/r/20240905-rust-lockdep-v1-1-d2c9c21aa8b2@gmail.com --- Mitchell Levy (2): rust: lockdep: Remove support for dynamically allocated LockClassKeys rust: lockdep: Use Pin for all LockClassKey usages rust/helpers/helpers.c | 1 + rust/helpers/sync.c | 13 +++++++++++++ rust/kernel/lib.rs | 2 +- rust/kernel/sync.rs | 34 ++++++++++++++++++++++++---------- rust/kernel/sync/condvar.rs | 11 +++++++---- rust/kernel/sync/lock.rs | 4 ++-- rust/kernel/workqueue.rs | 2 +- 7 files changed, 49 insertions(+), 18 deletions(-) --- base-commit: 9852d85ec9d492ebef56dc5f229416c925758edc change-id: 20240905-rust-lockdep-d3e30521c8ba Best regards, -- Mitchell Levy <levymitchell0(a)gmail.com>

2 weeks

2
2
0 0

reply: [PATCH AUTOSEL 6.11 47/76] fs: nfs: fix missing refcnt by replacing folio_set_private by folio_attach_private

by 黄朝阳 (Zhaoyang Huang)

>From: Zhaoyang Huang <zhaoyang.huang(a)unisoc.com> > >[ Upstream commit 03e02b94171b1985dd0aa184296fe94425b855a3 ] > >This patch is inspired by a code review of fs codes which aims at folio's extra >refcnt that could introduce unwanted behavious when judging refcnt, such >as[1].That is, the folio passed to mapping_evict_folio carries the refcnts from >find_lock_entries, page_cache, corresponding to PTEs and folio's private if has. >However, current code doesn't take the refcnt for folio's private which could >have mapping_evict_folio miss the one to only PTE and lead to call >filemap_release_folio wrongly. > >[1] >long mapping_evict_folio(struct address_space *mapping, struct folio *folio) >{ ... >//current code will misjudge here if there is one pte on the folio which is be >deemed as the one as folio's private > if (folio_ref_count(folio) > > folio_nr_pages(folio) + folio_has_private(folio) + >1) > return 0; > if (!filemap_release_folio(folio, 0)) > return 0; > > return remove_mapping(mapping, folio); } > >Signed-off-by: Zhaoyang Huang <zhaoyang.huang(a)unisoc.com> >Signed-off-by: Anna Schumaker <anna.schumaker(a)oracle.com> >Signed-off-by: Sasha Levin <sashal(a)kernel.org> Sorry, this patch should be dropped since Trond has explained that there is no need to grab refcnt here as nfs_page has hold the refcount on this folio. >--- > fs/nfs/write.c | 6 ++---- > 1 file changed, 2 insertions(+), 4 deletions(-) > >diff --git a/fs/nfs/write.c b/fs/nfs/write.c index >d074d0ceb4f01..80c6ded5f74c6 100644 >--- a/fs/nfs/write.c >+++ b/fs/nfs/write.c >@@ -772,8 +772,7 @@ static void nfs_inode_add_request(struct nfs_page >*req) > nfs_lock_request(req); > spin_lock(&mapping->i_private_lock); > set_bit(PG_MAPPED, &req->wb_flags); >- folio_set_private(folio); >- folio->private = req; >+ folio_attach_private(folio, req); > spin_unlock(&mapping->i_private_lock); > atomic_long_inc(&nfsi->nrequests); > /* this a head request for a page group - mark it as having an @@ >-797,8 +796,7 @@ static void nfs_inode_remove_request(struct nfs_page >*req) > > spin_lock(&mapping->i_private_lock); > if (likely(folio)) { >- folio->private = NULL; >- folio_clear_private(folio); >+ folio_detach_private(folio); > clear_bit(PG_MAPPED, >&req->wb_head->wb_flags); > } > spin_unlock(&mapping->i_private_lock); >-- >2.43.0

2 weeks

1
0
0 0

[PATCH v2] ext4: fix off by one issue in alloc_flex_gd()

by libaokun＠huaweicloud.com

From: Baokun Li <libaokun1(a)huawei.com> Wesley reported an issue: ================================================================== EXT4-fs (dm-5): resizing filesystem from 7168 to 786432 blocks ------------[ cut here ]------------ kernel BUG at fs/ext4/resize.c:324! CPU: 9 UID: 0 PID: 3576 Comm: resize2fs Not tainted 6.11.0+ #27 RIP: 0010:ext4_resize_fs+0x1212/0x12d0 Call Trace: __ext4_ioctl+0x4e0/0x1800 ext4_ioctl+0x12/0x20 __x64_sys_ioctl+0x99/0xd0 x64_sys_call+0x1206/0x20d0 do_syscall_64+0x72/0x110 entry_SYSCALL_64_after_hwframe+0x76/0x7e ================================================================== While reviewing the patch, Honza found that when adjusting resize_bg in alloc_flex_gd(), it was possible for flex_gd->resize_bg to be bigger than flexbg_size. The reproduction of the problem requires the following: o_group = flexbg_size * 2 * n; o_size = (o_group + 1) * group_size; n_group: [o_group + flexbg_size, o_group + flexbg_size * 2) o_size = (n_group + 1) * group_size; Take n=0,flexbg_size=16 as an example: last:15 |o---------------|--------------n-| o_group:0 resize to n_group:30 The corresponding reproducer is: img=test.img truncate -s 600M $img mkfs.ext4 -F $img -b 1024 -G 16 8M dev=`losetup -f --show $img` mkdir -p /tmp/test mount $dev /tmp/test resize2fs $dev 248M Delete the problematic plus 1 to fix the issue, and add a WARN_ON_ONCE() to prevent the issue from happening again. Reported-by: Wesley Hershberger <wesley.hershberger(a)canonical.com> Closes: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2081231 Reported-by: Stéphane Graber <stgraber(a)stgraber.org> Closes: https://lore.kernel.org/all/20240925143325.518508-1-aleksandr.mikhalitsyn@c… Tested-by: Alexander Mikhalitsyn <aleksandr.mikhalitsyn(a)canonical.com> Tested-by: Eric Sandeen <sandeen(a)redhat.com> Fixes: 665d3e0af4d3 ("ext4: reduce unnecessary memory allocation in alloc_flex_gd()") Cc: stable(a)vger.kernel.org Signed-off-by: Baokun Li <libaokun1(a)huawei.com> --- Changes since v1: * Add missing WARN_ON_ONCE(). * Correct the comment of alloc_flex_gd(). fs/ext4/resize.c | 18 ++++++++++-------- 1 file changed, 10 insertions(+), 8 deletions(-) diff --git a/fs/ext4/resize.c b/fs/ext4/resize.c index e04eb08b9060..a2704f064361 100644 --- a/fs/ext4/resize.c +++ b/fs/ext4/resize.c @@ -230,8 +230,8 @@ struct ext4_new_flex_group_data { #define MAX_RESIZE_BG 16384 /* - * alloc_flex_gd() allocates a ext4_new_flex_group_data with size of - * @flexbg_size. + * alloc_flex_gd() allocates an ext4_new_flex_group_data that satisfies the + * resizing from @o_group to @n_group, its size is typically @flexbg_size. * * Returns NULL on failure otherwise address of the allocated structure. */ @@ -239,25 +239,27 @@ static struct ext4_new_flex_group_data *alloc_flex_gd(unsigned int flexbg_size, ext4_group_t o_group, ext4_group_t n_group) { ext4_group_t last_group; + unsigned int max_resize_bg; struct ext4_new_flex_group_data *flex_gd; flex_gd = kmalloc(sizeof(*flex_gd), GFP_NOFS); if (flex_gd == NULL) goto out3; - if (unlikely(flexbg_size > MAX_RESIZE_BG)) - flex_gd->resize_bg = MAX_RESIZE_BG; - else - flex_gd->resize_bg = flexbg_size; + max_resize_bg = umin(flexbg_size, MAX_RESIZE_BG); + flex_gd->resize_bg = max_resize_bg; /* Avoid allocating large 'groups' array if not needed */ last_group = o_group | (flex_gd->resize_bg - 1); if (n_group <= last_group) - flex_gd->resize_bg = 1 << fls(n_group - o_group + 1); + flex_gd->resize_bg = 1 << fls(n_group - o_group); else if (n_group - last_group < flex_gd->resize_bg) - flex_gd->resize_bg = 1 << max(fls(last_group - o_group + 1), + flex_gd->resize_bg = 1 << max(fls(last_group - o_group), fls(n_group - last_group)); + if (WARN_ON_ONCE(flex_gd->resize_bg > max_resize_bg)) + flex_gd->resize_bg = max_resize_bg; + flex_gd->groups = kmalloc_array(flex_gd->resize_bg, sizeof(struct ext4_new_group_data), GFP_NOFS); -- 2.39.2

2 weeks

5
4
0 0

+ selftests-mm-replace-atomic_bool-with-pthread_barrier_t.patch added to mm-hotfixes-unstable branch

by Andrew Morton

The patch titled Subject: selftests/mm: replace atomic_bool with pthread_barrier_t has been added to the -mm mm-hotfixes-unstable branch. Its filename is selftests-mm-replace-atomic_bool-with-pthread_barrier_t.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: Edward Liaw <edliaw(a)google.com> Subject: selftests/mm: replace atomic_bool with pthread_barrier_t Date: Thu, 3 Oct 2024 21:17:10 +0000 Patch series "selftests/mm: fix deadlock after pthread_create". On Android arm, pthread_create followed by a fork caused a deadlock in the case where the fork required work to be completed by the created thread. Update the synchronization primitive to use pthread_barrier instead of atomic_bool. Apply the same fix to the wp-fork-with-event test. This patch (of 2): Swap synchronization primitive with pthread_barrier, so that stdatomic.h does not need to be included. The synchronization is needed on Android ARM64; we see a deadlock with pthread_create when the parent thread races forward before the child has a chance to start doing work. Link: https://lkml.kernel.org/r/20241003211716.371786-1-edliaw@google.com Link: https://lkml.kernel.org/r/20241003211716.371786-2-edliaw@google.com Fixes: 8c864371b2a1 ("selftests/mm: fix ARM related issue with fork after pthread_create") Signed-off-by: Edward Liaw <edliaw(a)google.com> Cc: Lokesh Gidra <lokeshgidra(a)google.com> Cc: Peter Xu <peterx(a)redhat.com> Cc: Shuah Khan <shuah(a)kernel.org> Cc: <stable(a)vger.kernel.org> Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> --- tools/testing/selftests/mm/uffd-common.c | 5 +++-- tools/testing/selftests/mm/uffd-common.h | 3 +-- tools/testing/selftests/mm/uffd-unit-tests.c | 14 ++++++++------ 3 files changed, 12 insertions(+), 10 deletions(-) --- a/tools/testing/selftests/mm/uffd-common.c~selftests-mm-replace-atomic_bool-with-pthread_barrier_t +++ a/tools/testing/selftests/mm/uffd-common.c @@ -18,7 +18,7 @@ bool test_uffdio_wp = true; unsigned long long *count_verify; uffd_test_ops_t *uffd_test_ops; uffd_test_case_ops_t *uffd_test_case_ops; -atomic_bool ready_for_fork; +pthread_barrier_t ready_for_fork; static int uffd_mem_fd_create(off_t mem_size, bool hugetlb) { @@ -519,7 +519,8 @@ void *uffd_poll_thread(void *arg) pollfd[1].fd = pipefd[cpu*2]; pollfd[1].events = POLLIN; - ready_for_fork = true; + /* Ready for parent thread to fork */ + pthread_barrier_wait(&ready_for_fork); for (;;) { ret = poll(pollfd, 2, -1); --- a/tools/testing/selftests/mm/uffd-common.h~selftests-mm-replace-atomic_bool-with-pthread_barrier_t +++ a/tools/testing/selftests/mm/uffd-common.h @@ -33,7 +33,6 @@ #include <inttypes.h> #include <stdint.h> #include <sys/random.h> -#include <stdatomic.h> #include "../kselftest.h" #include "vm_util.h" @@ -105,7 +104,7 @@ extern bool map_shared; extern bool test_uffdio_wp; extern unsigned long long *count_verify; extern volatile bool test_uffdio_copy_eexist; -extern atomic_bool ready_for_fork; +extern pthread_barrier_t ready_for_fork; extern uffd_test_ops_t anon_uffd_test_ops; extern uffd_test_ops_t shmem_uffd_test_ops; --- a/tools/testing/selftests/mm/uffd-unit-tests.c~selftests-mm-replace-atomic_bool-with-pthread_barrier_t +++ a/tools/testing/selftests/mm/uffd-unit-tests.c @@ -774,7 +774,7 @@ static void uffd_sigbus_test_common(bool char c; struct uffd_args args = { 0 }; - ready_for_fork = false; + pthread_barrier_init(&ready_for_fork, NULL, 2); fcntl(uffd, F_SETFL, uffd_flags | O_NONBLOCK); @@ -791,8 +791,9 @@ static void uffd_sigbus_test_common(bool if (pthread_create(&uffd_mon, NULL, uffd_poll_thread, &args)) err("uffd_poll_thread create"); - while (!ready_for_fork) - ; /* Wait for the poll_thread to start executing before forking */ + /* Wait for child thread to start before forking */ + pthread_barrier_wait(&ready_for_fork); + pthread_barrier_destroy(&ready_for_fork); pid = fork(); if (pid < 0) @@ -833,7 +834,7 @@ static void uffd_events_test_common(bool char c; struct uffd_args args = { 0 }; - ready_for_fork = false; + pthread_barrier_init(&ready_for_fork, NULL, 2); fcntl(uffd, F_SETFL, uffd_flags | O_NONBLOCK); if (uffd_register(uffd, area_dst, nr_pages * page_size, @@ -844,8 +845,9 @@ static void uffd_events_test_common(bool if (pthread_create(&uffd_mon, NULL, uffd_poll_thread, &args)) err("uffd_poll_thread create"); - while (!ready_for_fork) - ; /* Wait for the poll_thread to start executing before forking */ + /* Wait for child thread to start before forking */ + pthread_barrier_wait(&ready_for_fork); + pthread_barrier_destroy(&ready_for_fork); pid = fork(); if (pid < 0) _ Patches currently in -mm which might be from edliaw(a)google.com are selftests-mm-replace-atomic_bool-with-pthread_barrier_t.patch selftests-mm-fix-deadlock-for-fork-after-pthread_create-on-arm.patch

2 weeks

1
0
0 0

[PATCH 2/3] Bluetooth: Call iso_exit() on module unload

by Aaron Thompson

From: Aaron Thompson <dev(a)aaront.org> If iso_init() has been called, iso_exit() must be called on module unload. Without that, the struct proto that iso_init() registered with proto_register() becomes invalid, which could cause unpredictable problems later. In my case, with CONFIG_LIST_HARDENED and CONFIG_BUG_ON_DATA_CORRUPTION enabled, loading the module again usually triggers this BUG(): list_add corruption. next->prev should be prev (ffffffffb5355fd0), but was 0000000000000068. (next=ffffffffc0a010d0). ------------[ cut here ]------------ kernel BUG at lib/list_debug.c:29! Oops: invalid opcode: 0000 [#1] PREEMPT SMP PTI CPU: 1 PID: 4159 Comm: modprobe Not tainted 6.10.11-4+bt2-ao-desktop #1 RIP: 0010:__list_add_valid_or_report+0x61/0xa0 ... __list_add_valid_or_report+0x61/0xa0 proto_register+0x299/0x320 hci_sock_init+0x16/0xc0 [bluetooth] bt_init+0x68/0xd0 [bluetooth] __pfx_bt_init+0x10/0x10 [bluetooth] do_one_initcall+0x80/0x2f0 do_init_module+0x8b/0x230 __do_sys_init_module+0x15f/0x190 do_syscall_64+0x68/0x110 ... Cc: stable(a)vger.kernel.org Fixes: ccf74f2390d6 ("Bluetooth: Add BTPROTO_ISO socket type") Signed-off-by: Aaron Thompson <dev(a)aaront.org> --- net/bluetooth/mgmt.c | 1 + 1 file changed, 1 insertion(+) diff --git a/net/bluetooth/mgmt.c b/net/bluetooth/mgmt.c index e4f564d6f6fb..78a164fab3e1 100644 --- a/net/bluetooth/mgmt.c +++ b/net/bluetooth/mgmt.c @@ -10487,6 +10487,7 @@ int mgmt_init(void) void mgmt_exit(void) { + iso_exit(); hci_mgmt_chan_unregister(&chan); } -- 2.39.5

2 weeks

2
2
0 0

[PATCH v3 net] net: Fix an unsafe loop on the list

by Anastasia Kovaleva

The kernel may crash when deleting a genetlink family if there are still listeners for that family: Oops: Kernel access of bad area, sig: 11 [#1] ... NIP [c000000000c080bc] netlink_update_socket_mc+0x3c/0xc0 LR [c000000000c0f764] __netlink_clear_multicast_users+0x74/0xc0 Call Trace: __netlink_clear_multicast_users+0x74/0xc0 genl_unregister_family+0xd4/0x2d0 Change the unsafe loop on the list to a safe one, because inside the loop there is an element removal from this list. Fixes: b8273570f802 ("genetlink: fix netns vs. netlink table locking (2)") Cc: stable(a)vger.kernel.org Signed-off-by: Anastasia Kovaleva <a.kovaleva(a)yadro.com> Reviewed-by: Dmitry Bogdanov <d.bogdanov(a)yadro.com> --- v3: remove trailing "\", change spaces to tab v2: add CC tag for stable --- include/net/sock.h | 2 ++ net/netlink/af_netlink.c | 3 ++- 2 files changed, 4 insertions(+), 1 deletion(-) diff --git a/include/net/sock.h b/include/net/sock.h index c58ca8dd561b..db29c39e19a7 100644 --- a/include/net/sock.h +++ b/include/net/sock.h @@ -894,6 +894,8 @@ static inline void sk_add_bind_node(struct sock *sk, hlist_for_each_entry_safe(__sk, tmp, list, sk_node) #define sk_for_each_bound(__sk, list) \ hlist_for_each_entry(__sk, list, sk_bind_node) +#define sk_for_each_bound_safe(__sk, tmp, list) \ + hlist_for_each_entry_safe(__sk, tmp, list, sk_bind_node) /** * sk_for_each_entry_offset_rcu - iterate over a list at a given struct offset diff --git a/net/netlink/af_netlink.c b/net/netlink/af_netlink.c index 0b7a89db3ab7..0a9287fadb47 100644 --- a/net/netlink/af_netlink.c +++ b/net/netlink/af_netlink.c @@ -2136,8 +2136,9 @@ void __netlink_clear_multicast_users(struct sock *ksk, unsigned int group) { struct sock *sk; struct netlink_table *tbl = &nl_table[ksk->sk_protocol]; + struct hlist_node *tmp; - sk_for_each_bound(sk, &tbl->mc_list) + sk_for_each_bound_safe(sk, tmp, &tbl->mc_list) netlink_update_socket_mc(nlk_sk(sk), group, 0); } -- 2.40.1

2 weeks

3
2
0 0

[PATCH 5.15.y] 9p: add missing locking around taking dentry fid list

by Samasth Norway Ananda

From: Dominique Martinet <asmadeus(a)codewreck.org> commit c898afdc15645efb555acb6d85b484eb40a45409 upstream. Fix a use-after-free on dentry's d_fsdata fid list when a thread looks up a fid through dentry while another thread unlinks it: UAF thread: refcount_t: addition on 0; use-after-free. p9_fid_get linux/./include/net/9p/client.h:262 v9fs_fid_find+0x236/0x280 linux/fs/9p/fid.c:129 v9fs_fid_lookup_with_uid linux/fs/9p/fid.c:181 v9fs_fid_lookup+0xbf/0xc20 linux/fs/9p/fid.c:314 v9fs_vfs_getattr_dotl+0xf9/0x360 linux/fs/9p/vfs_inode_dotl.c:400 vfs_statx+0xdd/0x4d0 linux/fs/stat.c:248 Freed by: p9_fid_destroy (inlined) p9_client_clunk+0xb0/0xe0 linux/net/9p/client.c:1456 p9_fid_put linux/./include/net/9p/client.h:278 v9fs_dentry_release+0xb5/0x140 linux/fs/9p/vfs_dentry.c:55 v9fs_remove+0x38f/0x620 linux/fs/9p/vfs_inode.c:518 vfs_unlink+0x29a/0x810 linux/fs/namei.c:4335 The problem is that d_fsdata was not accessed under d_lock, because d_release() normally is only called once the dentry is otherwise no longer accessible but since we also call it explicitly in v9fs_remove that lock is required: move the hlist out of the dentry under lock then unref its fids once they are no longer accessible. Fixes: 154372e67d40 ("fs/9p: fix create-unlink-getattr idiom") Cc: stable(a)vger.kernel.org Reported-by: Meysam Firouzi Reported-by: Amirmohammad Eftekhar Reviewed-by: Christian Schoenebeck <linux_oss(a)crudebyte.com> Message-ID: <20240521122947.1080227-1-asmadeus(a)codewreck.org> Signed-off-by: Dominique Martinet <asmadeus(a)codewreck.org> [Samasth: backport to 5.15.y] Signed-off-by: Samasth Norway Ananda <samasth.norway.ananda(a)oracle.com> Conflicts: fs/9p/vfs_dentry.c keep p9_client_clunk instead of introducing the helper function p9_fid_get/put from commit b48dbb998d70 ("9p fid refcount: add p9_fid_get/put wrappers") --- This is a fix for CVE-2024-39463, minor conflict resolution involved. --- fs/9p/vfs_dentry.c | 9 +++++++-- 1 file changed, 7 insertions(+), 2 deletions(-) diff --git a/fs/9p/vfs_dentry.c b/fs/9p/vfs_dentry.c index c2736af97884f..afcf4711ac2a8 100644 --- a/fs/9p/vfs_dentry.c +++ b/fs/9p/vfs_dentry.c @@ -52,12 +52,17 @@ static int v9fs_cached_dentry_delete(const struct dentry *dentry) static void v9fs_dentry_release(struct dentry *dentry) { struct hlist_node *p, *n; + struct hlist_head head; p9_debug(P9_DEBUG_VFS, " dentry: %pd (%p)\n", dentry, dentry); - hlist_for_each_safe(p, n, (struct hlist_head *)&dentry->d_fsdata) + + spin_lock(&dentry->d_lock); + hlist_move_list((struct hlist_head *)&dentry->d_fsdata, &head); + spin_unlock(&dentry->d_lock); + + hlist_for_each_safe(p, n, &head) p9_client_clunk(hlist_entry(p, struct p9_fid, dlist)); - dentry->d_fsdata = NULL; } static int v9fs_lookup_revalidate(struct dentry *dentry, unsigned int flags) -- 2.46.0

2 weeks

1
0
0 0

+ fixes-null-pointer-dereference-in-pfnmap_lockdep_assert.patch added to mm-hotfixes-unstable branch

by Andrew Morton

The patch titled Subject: mm: fix null pointer dereference in pfnmap_lockdep_assert has been added to the -mm mm-hotfixes-unstable branch. Its filename is fixes-null-pointer-dereference-in-pfnmap_lockdep_assert.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: Manas <manas18244(a)iiitd.ac.in> Subject: mm: fix null pointer dereference in pfnmap_lockdep_assert Date: Fri, 04 Oct 2024 23:12:16 +0530 syzbot has pointed to a possible null pointer dereference in pfnmap_lockdep_assert. vm_file member of vm_area_struct is being dereferenced without any checks. This fix assigns mapping only if vm_file is not NULL. Peter said (https://lkml.kernel.org/r/Zv8HRA5mnhVevBN_@x1n): : If I read the stack right, the crash was before mmap() of the new vma : happens, instead it's during unmap() of one existing vma which existed and : overlapped with the new vma's mapping range: : : follow_phys arch/x86/mm/pat/memtype.c:956 [inline] : get_pat_info+0x182/0x3f0 arch/x86/mm/pat/memtype.c:988 : untrack_pfn+0x327/0x640 arch/x86/mm/pat/memtype.c:1101 : unmap_single_vma+0x1f6/0x2b0 mm/memory.c:1834 : unmap_vmas+0x3cc/0x5f0 mm/memory.c:1900 : unmap_region+0x214/0x380 mm/vma.c:354 <--------------- here : mmap_region+0x22f9/0x2990 mm/mmap.c:1573 : do_mmap+0x8f0/0x1000 mm/mmap.c:496 : vm_mmap_pgoff+0x1dd/0x3d0 mm/util.c:588 : ksys_mmap_pgoff+0x4eb/0x720 mm/mmap.c:542 : do_syscall_x64 arch/x86/entry/common.c:52 [inline] : do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83 : entry_SYSCALL_64_after_hwframe+0x77/0x7f : : It looks like the vma that was overwritten by the new file vma mapping : could be a VM_PFNMAP vma (I'm guessing vvar or something similar..), : that's where untrack_pfn() got kicked off. In this case, the vma being : overwritten and to be unmapped can have ->vm_file==NULL (while ->vm_ops : non-NULL; /me looking at __install_special_mapping()). Link: https://lkml.kernel.org/r/20241004-fix-null-deref-v4-1-d0a8ec01ac85@iiitd.a… Reported-by: syzbot+093d096417e7038a689b(a)syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=093d096417e7038a689b Cc: Anup Sharma <anupnewsmail(a)gmail.com> Cc: Shuah Khan <skhan(a)linuxfoundation.org> Cc: Matthew Wilcox <willy(a)infradead.org> Cc: <stable(a)vger.kernel.org> Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> --- mm/memory.c | 7 +++++-- 1 file changed, 5 insertions(+), 2 deletions(-) --- a/mm/memory.c~fixes-null-pointer-dereference-in-pfnmap_lockdep_assert +++ a/mm/memory.c @@ -6355,10 +6355,13 @@ static inline void pfnmap_args_setup(str static inline void pfnmap_lockdep_assert(struct vm_area_struct *vma) { #ifdef CONFIG_LOCKDEP - struct address_space *mapping = vma->vm_file->f_mapping; + struct address_space *mapping = NULL; + + if (vma->vm_file) + mapping = vma->vm_file->f_mapping; if (mapping) - lockdep_assert(lockdep_is_held(&vma->vm_file->f_mapping->i_mmap_rwsem) || + lockdep_assert(lockdep_is_held(&mapping->i_mmap_rwsem) || lockdep_is_held(&vma->vm_mm->mmap_lock)); else lockdep_assert(lockdep_is_held(&vma->vm_mm->mmap_lock)); _ Patches currently in -mm which might be from manas18244(a)iiitd.ac.in are fixes-null-pointer-dereference-in-pfnmap_lockdep_assert.patch

2 weeks

1
0
0 0

[PATCH 1/2] firmware: qcom: scm: suppress download mode error

by Johan Hovold

Stop spamming the logs with errors about missing mechanism for setting the so called download (or dump) mode for users that have not requested that feature to be enabled in the first place. This avoids the follow error being logged on boot as well as on shutdown when the feature it not available and download mode has not been enabled on the kernel command line: qcom_scm firmware:scm: No available mechanism for setting download mode Fixes: 79cb2cb8d89b ("firmware: qcom: scm: Disable SDI and write no dump to dump mode") Fixes: 781d32d1c970 ("firmware: qcom_scm: Clear download bit during reboot") Cc: Mukesh Ojha <quic_mojha(a)quicinc.com> Cc: stable(a)vger.kernel.org # 6.4 Signed-off-by: Johan Hovold <johan+linaro(a)kernel.org> --- drivers/firmware/qcom/qcom_scm.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/firmware/qcom/qcom_scm.c b/drivers/firmware/qcom/qcom_scm.c index 10986cb11ec0..e2ac595902ed 100644 --- a/drivers/firmware/qcom/qcom_scm.c +++ b/drivers/firmware/qcom/qcom_scm.c @@ -545,7 +545,7 @@ static void qcom_scm_set_download_mode(u32 dload_mode) } else if (__qcom_scm_is_call_available(__scm->dev, QCOM_SCM_SVC_BOOT, QCOM_SCM_BOOT_SET_DLOAD_MODE)) { ret = __qcom_scm_set_dload_mode(__scm->dev, !!dload_mode); - } else { + } else if (dload_mode) { dev_err(__scm->dev, "No available mechanism for setting download mode\n"); } -- 2.45.2

2 weeks

2
1
0 0

[PATCH] drm/amd/display: fix hibernate entry for DCN35+

by Hamza Mahfooz

Since, two suspend-resume cycles are required to enter hibernate and, since we only need to enable idle optimizations in the first cycle (which is pretty much equivalent to s2idle). We can check in_s0ix, to prevent the system from entering idle optimizations before it actually enters hibernate (from display's perspective). Cc: stable(a)vger.kernel.org # 6.10+ Signed-off-by: Hamza Mahfooz <hamza.mahfooz(a)amd.com> --- drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 7 ++++--- 1 file changed, 4 insertions(+), 3 deletions(-) diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c index 4651b884d8d9..546a168a2fbf 100644 --- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c +++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c @@ -2996,10 +2996,11 @@ static int dm_suspend(struct amdgpu_ip_block *ip_block) hpd_rx_irq_work_suspend(dm); - if (adev->dm.dc->caps.ips_support) - dc_allow_idle_optimizations(adev->dm.dc, true); - dc_set_power_state(dm->dc, DC_ACPI_CM_POWER_STATE_D3); + + if (dm->dc->caps.ips_support && adev->in_s0ix) + dc_allow_idle_optimizations(dm->dc, true); + dc_dmub_srv_set_power_state(dm->dc->ctx->dmub_srv, DC_ACPI_CM_POWER_STATE_D3); return 0; -- 2.46.0

2 weeks, 1 day

2
3
0 0

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror October 2024