- Linux-stable-mirror - lists.linaro.org

[PATCH] ksmbd: fix leak of transform buffer on encrypt_resp() failure

by Qianchang Zhao

When encrypt_resp() fails at the send path, we only set STATUS_DATA_ERROR but leave the transform buffer allocated (work->tr_buf in this tree). Repeating this path leaks kernel memory and can lead to OOM (DoS) when encryption is required. Reproduced on: Linux v6.18-rc2 (self-built test kernel) Fix by freeing the transform buffer and forcing plaintext error reply. Reported-by: Qianchang Zhao <pioooooooooip(a)gmail.com> Reported-by: Zhitong Liu <liuzhitong1993(a)gmail.com> Cc: stable(a)vger.kernel.org Signed-off-by: Qianchang Zhao <pioooooooooip(a)gmail.com> --- fs/smb/server/server.c | 8 +++++++- 1 file changed, 7 insertions(+), 1 deletion(-) diff --git a/fs/smb/server/server.c b/fs/smb/server/server.c index 40420544c..15dd13e76 100644 --- a/fs/smb/server/server.c +++ b/fs/smb/server/server.c @@ -244,8 +244,14 @@ static void __handle_ksmbd_work(struct ksmbd_work *work, if (work->sess && work->sess->enc && work->encrypted && conn->ops->encrypt_resp) { rc = conn->ops->encrypt_resp(work); - if (rc < 0) + if (rc < 0) { conn->ops->set_rsp_status(work, STATUS_DATA_ERROR); + work->encrypted = false; + if (work->tr_buf) { + kvfree(work->tr_buf); + work->tr_buf = NULL; + } + } } if (work->sess) ksmbd_user_session_put(work->sess); -- 2.34.1

1 month

1
0
0 0

[PATCH] ksmbd: fix leak of transform buffer on encrypt_resp() failure

by Qianchang Zhao

When encrypt_resp() fails at the send path, we only set STATUS_DATA_ERROR but leave the transform buffer allocated (work->tr_buf in this tree). Repeating this path leaks kernel memory and can lead to OOM (DoS) when encryption is required. Reproduced on: Linux v6.18-rc2 (self-built test kernel) Fix by freeing the transform buffer and forcing plaintext error reply. Reported-by: Qianchang Zhao <pioooooooooip(a)gmail.com> Reported-by: Zhitong Liu <liuzhitong1993(a)gmail.com> Cc: stable(a)vger.kernel.org Signed-off-by: Qianchang Zhao <pioooooooooip(a)gmail.com> --- fs/smb/server/server.c | 8 +++++++- 1 file changed, 7 insertions(+), 1 deletion(-) diff --git a/fs/smb/server/server.c b/fs/smb/server/server.c index 40420544c..15dd13e76 100644 --- a/fs/smb/server/server.c +++ b/fs/smb/server/server.c @@ -244,8 +244,14 @@ static void __handle_ksmbd_work(struct ksmbd_work *work, if (work->sess && work->sess->enc && work->encrypted && conn->ops->encrypt_resp) { rc = conn->ops->encrypt_resp(work); - if (rc < 0) + if (rc < 0) { conn->ops->set_rsp_status(work, STATUS_DATA_ERROR); + work->encrypted = false; + if (work->tr_buf) { + kvfree(work->tr_buf); + work->tr_buf = NULL; + } + } } if (work->sess) ksmbd_user_session_put(work->sess); -- 2.34.1

1 month

1
0
0 0

[PATCH] btrfs: fix resource leak in do_walk_down()

by Zhen Ni

When check_next_block_uptodate() fails, do_walk_down() returns directly without cleaning up the locked extent buffer allocated earlier, causing memory and lock leaks. Fix by using the existing out_unlock cleanup path instead of direct return. Fixes: 562d425454e8 ("btrfs: factor out eb uptodate check from do_walk_down()") Cc: stable(a)vger.kernel.org Signed-off-by: Zhen Ni <zhen.ni(a)easystack.cn> --- fs/btrfs/extent-tree.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/fs/btrfs/extent-tree.c b/fs/btrfs/extent-tree.c index dc4ca98c3780..742e476bf815 100644 --- a/fs/btrfs/extent-tree.c +++ b/fs/btrfs/extent-tree.c @@ -5770,7 +5770,7 @@ static noinline int do_walk_down(struct btrfs_trans_handle *trans, ret = check_next_block_uptodate(trans, root, path, wc, next); if (ret) - return ret; + goto out_unlock; level--; ASSERT(level == btrfs_header_level(next)); -- 2.20.1

1 month

2
1
0 0

Re: Patch "rust: kunit: allow `cfg` on `test`s" has been added to the 6.17-stable tree

by Miguel Ojeda

On Tue, Nov 4, 2025 at 2:16 PM Sasha Levin <sashal(a)kernel.org> wrote: > > This is a note to let you know that I've just added the patch titled > > rust: kunit: allow `cfg` on `test`s > > to the 6.17-stable tree which can be found at: > http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… > > The filename of the patch is: > rust-kunit-allow-cfg-on-test-s.patch > and it can be found in the queue-6.17 subdirectory. > > If you, or anyone else, feels it should not be added to the stable tree, > please let <stable(a)vger.kernel.org> know about it. It probably doesn't hurt, but if we don't have any test that needs it, then we could skip it, i.e. it is essentially a feature. Thanks! Cheers, Miguel

1 month

1
0
0 0

[PATCH RFC 6.1/6.6 CANDIDATE] mm: introduce memalloc_flags_{save,restore}

by Long Li

From: Kent Overstreet <kent.overstreet(a)linux.dev> commit 3f6d5e6a468d02676244b868b210433831846127 upstream. Our proliferation of memalloc_*_{save,restore} APIs is getting a bit silly, this adds a generic version and converts the existing save/restore functions to wrappers. Signed-off-by: Kent Overstreet <kent.overstreet(a)linux.dev> Cc: Vlastimil Babka <vbabka(a)suse.cz> Cc: Matthew Wilcox <willy(a)infradead.org> Cc: Michal Hocko <mhocko(a)kernel.org> Cc: Darrick J. Wong <djwong(a)kernel.org> Cc: linux-mm(a)kvack.org Acked-by: Vlastimil Babka <vbabka(a)suse.cz> Signed-off-by: Long Li <leo.lilong(a)huawei.com> --- We encountered a deadlock issue in our internal version caused by PF_MEMALLOC_NOFS being unexpectedly cleared during inode inactive transaction. This issue appears to still exist in 6.1/6.6 lts version. In the mainline kernel, before commit [2] f2e812c1522d ("xfs: don't use current->journal_info") was merged, we relied on current->journal_info to check for transaction recursion. During transaction rollback/commit, only the last transaction commit would call xfs_trans_clear_context(tp) to restore the nofs flag, which worked correctly. After this patch was merged, we no longer check for transaction recursion, so each transaction rollback/commit calls xfs_trans_clear_context(tp) to restore the nofs flag. At this point, tp->t_pflags is set to 0 (except for the last one tp), and memalloc_nofs_restore(0) will not clear the PF_MEMALLOC_NOFS flag during transaction rollback, this is also correct. However, this also implies that the above patch depends on commit [1] 3f6d5e6a468d ("mm: introduce memalloc_flags_{save,restore}"), because that patch modified the semantics of the memalloc_nofs_{save,restore} interface, and only after this modification can it ensure that memalloc_nofs_restore(0) won't clear the PF_MEMALLOC_NOFS flag. In our 6.1/6.6 LTS versions, we directly backported commit [2] without backporting commit [1], which leads to confusion with the PF_MEMALLOC_NOFS flag during transaction rollback, for example as follows: xfs_inodegc_worker nofs_flag = memalloc_nofs_save(); //set PF_MEMALLOC_NOFS in current->flags xfs_inactive xfs_attr_inactive(ip) xfs_trans_alloc(mp, &M_RES(mp)->tr_attrinval, 0, 0, 0, &trans) xfs_trans_set_context(tp) //tp->t_pflags ==> 1 xfs_trans_commit(trans) __xfs_trans_commit(tp) xfs_defer_trans_roll xfs_trans_roll *tpp = xfs_trans_dup(trans) xfs_trans_switch_context(tp, ntp) new_tp->t_pflags = old_tp->t_pflags; //new_tp->t_pflags ==> 1 old_tp->t_pflags = 0; //old_tp->t_pflags ==> 0 __xfs_trans_commit(trans) //commit old_tp xfs_trans_free(tp); //free old_tp xfs_trans_clear_context(tp) memalloc_nofs_restore(0) //clear PF_MEMALLOC_NOFS in current->flags ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ < commit new_tp > xfs_trans_free(tp) //free new_tp memalloc_nofs_restore(1) //set PF_MEMALLOC_NOFS in current->flags memalloc_nofs_restore(nofs_flag); //clear PF_MEMALLOC_NOFS in current->flags So backport commit [1] 3f6d5e6a468d ("mm: introduce memalloc_flags_{save,restore}") to 6.1/6.6 lts. [1] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… [2] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… include/linux/sched/mm.h | 43 ++++++++++++++++++++++++---------------- 1 file changed, 26 insertions(+), 17 deletions(-) diff --git a/include/linux/sched/mm.h b/include/linux/sched/mm.h index 8d89c8c4fac1..10792d374785 100644 --- a/include/linux/sched/mm.h +++ b/include/linux/sched/mm.h @@ -306,6 +306,24 @@ static inline void might_alloc(gfp_t gfp_mask) might_sleep_if(gfpflags_allow_blocking(gfp_mask)); } +/** + * memalloc_flags_save - Add a PF_* flag to current->flags, save old value + * + * This allows PF_* flags to be conveniently added, irrespective of current + * value, and then the old version restored with memalloc_flags_restore(). + */ +static inline unsigned memalloc_flags_save(unsigned flags) +{ + unsigned oldflags = ~current->flags & flags; + current->flags |= flags; + return oldflags; +} + +static inline void memalloc_flags_restore(unsigned flags) +{ + current->flags &= ~flags; +} + /** * memalloc_noio_save - Marks implicit GFP_NOIO allocation scope. * @@ -319,9 +337,7 @@ static inline void might_alloc(gfp_t gfp_mask) */ static inline unsigned int memalloc_noio_save(void) { - unsigned int flags = current->flags & PF_MEMALLOC_NOIO; - current->flags |= PF_MEMALLOC_NOIO; - return flags; + return memalloc_flags_save(PF_MEMALLOC_NOIO); } /** @@ -334,7 +350,7 @@ static inline unsigned int memalloc_noio_save(void) */ static inline void memalloc_noio_restore(unsigned int flags) { - current->flags = (current->flags & ~PF_MEMALLOC_NOIO) | flags; + memalloc_flags_restore(flags); } /** @@ -350,9 +366,7 @@ static inline void memalloc_noio_restore(unsigned int flags) */ static inline unsigned int memalloc_nofs_save(void) { - unsigned int flags = current->flags & PF_MEMALLOC_NOFS; - current->flags |= PF_MEMALLOC_NOFS; - return flags; + return memalloc_flags_save(PF_MEMALLOC_NOFS); } /** @@ -365,32 +379,27 @@ static inline unsigned int memalloc_nofs_save(void) */ static inline void memalloc_nofs_restore(unsigned int flags) { - current->flags = (current->flags & ~PF_MEMALLOC_NOFS) | flags; + memalloc_flags_restore(flags); } static inline unsigned int memalloc_noreclaim_save(void) { - unsigned int flags = current->flags & PF_MEMALLOC; - current->flags |= PF_MEMALLOC; - return flags; + return memalloc_flags_save(PF_MEMALLOC); } static inline void memalloc_noreclaim_restore(unsigned int flags) { - current->flags = (current->flags & ~PF_MEMALLOC) | flags; + memalloc_flags_restore(flags); } static inline unsigned int memalloc_pin_save(void) { - unsigned int flags = current->flags & PF_MEMALLOC_PIN; - - current->flags |= PF_MEMALLOC_PIN; - return flags; + return memalloc_flags_save(PF_MEMALLOC_PIN); } static inline void memalloc_pin_restore(unsigned int flags) { - current->flags = (current->flags & ~PF_MEMALLOC_PIN) | flags; + memalloc_flags_restore(flags); } #ifdef CONFIG_MEMCG -- 2.39.2

1 month

1
0
0 0

[PATCH v5 1/5] vfat: fix missing sb_min_blocksize() return value checks

by Yongpeng Yang

From: Yongpeng Yang <yangyongpeng(a)xiaomi.com> When emulating an nvme device on qemu with both logical_block_size and physical_block_size set to 8 KiB, but without format, a kernel panic was triggered during the early boot stage while attempting to mount a vfat filesystem. [95553.682035] EXT4-fs (nvme0n1): unable to set blocksize [95553.684326] EXT4-fs (nvme0n1): unable to set blocksize [95553.686501] EXT4-fs (nvme0n1): unable to set blocksize [95553.696448] ISOFS: unsupported/invalid hardware sector size 8192 [95553.697117] ------------[ cut here ]------------ [95553.697567] kernel BUG at fs/buffer.c:1582! [95553.697984] Oops: invalid opcode: 0000 [#1] SMP NOPTI [95553.698602] CPU: 0 UID: 0 PID: 7212 Comm: mount Kdump: loaded Not tainted 6.18.0-rc2+ #38 PREEMPT(voluntary) [95553.699511] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.3-0-ga6ed6b701f0a-prebuilt.qemu.org 04/01/2014 [95553.700534] RIP: 0010:folio_alloc_buffers+0x1bb/0x1c0 [95553.701018] Code: 48 8b 15 e8 93 18 02 65 48 89 35 e0 93 18 02 48 83 c4 10 5b 41 5c 41 5d 41 5e 41 5f 5d 31 d2 31 c9 31 f6 31 ff c3 cc cc cc cc <0f> 0b 90 66 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 0f [95553.702648] RSP: 0018:ffffd1b0c676f990 EFLAGS: 00010246 [95553.703132] RAX: ffff8cfc4176d820 RBX: 0000000000508c48 RCX: 0000000000000001 [95553.703805] RDX: 0000000000002000 RSI: 0000000000000000 RDI: 0000000000000000 [95553.704481] RBP: ffffd1b0c676f9c8 R08: 0000000000000000 R09: 0000000000000000 [95553.705148] R10: 0000000000000000 R11: 0000000000000000 R12: 0000000000000001 [95553.705816] R13: 0000000000002000 R14: fffff8bc8257e800 R15: 0000000000000000 [95553.706483] FS: 000072ee77315840(0000) GS:ffff8cfdd2c8d000(0000) knlGS:0000000000000000 [95553.707248] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [95553.707782] CR2: 00007d8f2a9e5a20 CR3: 0000000039d0c006 CR4: 0000000000772ef0 [95553.708439] PKRU: 55555554 [95553.708734] Call Trace: [95553.709015] <TASK> [95553.709266] __getblk_slow+0xd2/0x230 [95553.709641] ? find_get_block_common+0x8b/0x530 [95553.710084] bdev_getblk+0x77/0xa0 [95553.710449] __bread_gfp+0x22/0x140 [95553.710810] fat_fill_super+0x23a/0xfc0 [95553.711216] ? __pfx_setup+0x10/0x10 [95553.711580] ? __pfx_vfat_fill_super+0x10/0x10 [95553.712014] vfat_fill_super+0x15/0x30 [95553.712401] get_tree_bdev_flags+0x141/0x1e0 [95553.712817] get_tree_bdev+0x10/0x20 [95553.713177] vfat_get_tree+0x15/0x20 [95553.713550] vfs_get_tree+0x2a/0x100 [95553.713910] vfs_cmd_create+0x62/0xf0 [95553.714273] __do_sys_fsconfig+0x4e7/0x660 [95553.714669] __x64_sys_fsconfig+0x20/0x40 [95553.715062] x64_sys_call+0x21ee/0x26a0 [95553.715453] do_syscall_64+0x80/0x670 [95553.715816] ? __fs_parse+0x65/0x1e0 [95553.716172] ? fat_parse_param+0x103/0x4b0 [95553.716587] ? vfs_parse_fs_param_source+0x21/0xa0 [95553.717034] ? __do_sys_fsconfig+0x3d9/0x660 [95553.717548] ? __x64_sys_fsconfig+0x20/0x40 [95553.717957] ? x64_sys_call+0x21ee/0x26a0 [95553.718360] ? do_syscall_64+0xb8/0x670 [95553.718734] ? __x64_sys_fsconfig+0x20/0x40 [95553.719141] ? x64_sys_call+0x21ee/0x26a0 [95553.719545] ? do_syscall_64+0xb8/0x670 [95553.719922] ? x64_sys_call+0x1405/0x26a0 [95553.720317] ? do_syscall_64+0xb8/0x670 [95553.720702] ? __x64_sys_close+0x3e/0x90 [95553.721080] ? x64_sys_call+0x1b5e/0x26a0 [95553.721478] ? do_syscall_64+0xb8/0x670 [95553.721841] ? irqentry_exit+0x43/0x50 [95553.722211] ? exc_page_fault+0x90/0x1b0 [95553.722681] entry_SYSCALL_64_after_hwframe+0x76/0x7e [95553.723166] RIP: 0033:0x72ee774f3afe [95553.723562] Code: 73 01 c3 48 8b 0d 0a 33 0f 00 f7 d8 64 89 01 48 83 c8 ff c3 0f 1f 84 00 00 00 00 00 f3 0f 1e fa 49 89 ca b8 af 01 00 00 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d da 32 0f 00 f7 d8 64 89 01 48 [95553.725188] RSP: 002b:00007ffe97148978 EFLAGS: 00000246 ORIG_RAX: 00000000000001af [95553.725892] RAX: ffffffffffffffda RBX: 00005dcfe53d0080 RCX: 000072ee774f3afe [95553.726526] RDX: 0000000000000000 RSI: 0000000000000006 RDI: 0000000000000003 [95553.727176] RBP: 00007ffe97148ac0 R08: 0000000000000000 R09: 000072ee775e7ac0 [95553.727818] R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000 [95553.728459] R13: 00005dcfe53d04b0 R14: 000072ee77670b00 R15: 00005dcfe53d1a28 [95553.729086] </TASK> The panic occurs as follows: 1. logical_block_size is 8KiB, causing {struct super_block *sb}->s_blocksize is initialized to 0. vfat_fill_super - fat_fill_super - sb_min_blocksize - sb_set_blocksize //return 0 when size is 8KiB. 2. __bread_gfp is called with size == 0, causing folio_alloc_buffers() to compute an offset equal to folio_size(folio), which triggers a BUG_ON. fat_fill_super - sb_bread - __bread_gfp // size == {struct super_block *sb}->s_blocksize == 0 - bdev_getblk - __getblk_slow - grow_buffers - grow_dev_folio - folio_alloc_buffers // size == 0 - folio_set_bh //offset == folio_size(folio) and panic To fix this issue, add proper return value checks for sb_min_blocksize(). Cc: <stable(a)vger.kernel.org> # v6.15 Fixes: a64e5a596067bd ("bdev: add back PAGE_SIZE block size validation for sb_set_blocksize()") Reviewed-by: Matthew Wilcox <willy(a)infradead.org> Reviewed-by: Darrick J. Wong <djwong(a)kernel.org> Reviewed-by: Jan Kara <jack(a)suse.cz> Reviewed-by: OGAWA Hirofumi <hirofumi(a)mail.parknet.co.jp> Signed-off-by: Yongpeng Yang <yangyongpeng(a)xiaomi.com> --- v5: - add cc tag for 5th patch v4: - split the changes into 5 patches v3: - remove the unnecessary blocksize variable definition v2: - add the __must_check mark to sb_min_blocksize() and include the Fixes tag --- fs/fat/inode.c | 6 +++++- 1 file changed, 5 insertions(+), 1 deletion(-) diff --git a/fs/fat/inode.c b/fs/fat/inode.c index 9648ed097816..9cfe20a3daaf 100644 --- a/fs/fat/inode.c +++ b/fs/fat/inode.c @@ -1595,8 +1595,12 @@ int fat_fill_super(struct super_block *sb, struct fs_context *fc, setup(sb); /* flavour-specific stuff that needs options */ + error = -EINVAL; + if (!sb_min_blocksize(sb, 512)) { + fat_msg(sb, KERN_ERR, "unable to set blocksize"); + goto out_fail; + } error = -EIO; - sb_min_blocksize(sb, 512); bh = sb_bread(sb, 0); if (bh == NULL) { fat_msg(sb, KERN_ERR, "unable to read boot sector"); -- 2.43.0

1 month

4
14
0 0

FAILED: patch "[PATCH] mptcp: fix MSG_PEEK stream corruption" failed to apply to 6.12-stable tree

by gregkh＠linuxfoundation.org

The patch below does not apply to the 6.12-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-6.12.y git checkout FETCH_HEAD git cherry-pick -x 8e04ce45a8db7a080220e86e249198fa676b83dc # <resolve conflicts, build, test, etc.> git commit -s git send-email --to '<stable(a)vger.kernel.org>' --in-reply-to '2025110208-pond-pouring-512d@gregkh' --subject-prefix 'PATCH 6.12.y' HEAD^.. Possible dependencies: thanks, greg k-h ------------------ original commit in Linus's tree ------------------ From 8e04ce45a8db7a080220e86e249198fa676b83dc Mon Sep 17 00:00:00 2001 From: Paolo Abeni <pabeni(a)redhat.com> Date: Tue, 28 Oct 2025 09:16:53 +0100 Subject: [PATCH] mptcp: fix MSG_PEEK stream corruption If a MSG_PEEK | MSG_WAITALL read operation consumes all the bytes in the receive queue and recvmsg() need to waits for more data - i.e. it's a blocking one - upon arrival of the next packet the MPTCP protocol will start again copying the oldest data present in the receive queue, corrupting the data stream. Address the issue explicitly tracking the peeked sequence number, restarting from the last peeked byte. Fixes: ca4fb892579f ("mptcp: add MSG_PEEK support") Cc: stable(a)vger.kernel.org Signed-off-by: Paolo Abeni <pabeni(a)redhat.com> Reviewed-by: Geliang Tang <geliang(a)kernel.org> Tested-by: Geliang Tang <geliang(a)kernel.org> Reviewed-by: Mat Martineau <martineau(a)kernel.org> Signed-off-by: Matthieu Baerts (NGI0) <matttbe(a)kernel.org> Link: https://patch.msgid.link/20251028-net-mptcp-send-timeout-v1-2-38ffff5a9ec8@… Signed-off-by: Jakub Kicinski <kuba(a)kernel.org> diff --git a/net/mptcp/protocol.c b/net/mptcp/protocol.c index 655a2a45224f..2535788569ab 100644 --- a/net/mptcp/protocol.c +++ b/net/mptcp/protocol.c @@ -1945,22 +1945,36 @@ static int mptcp_sendmsg(struct sock *sk, struct msghdr *msg, size_t len) static void mptcp_rcv_space_adjust(struct mptcp_sock *msk, int copied); -static int __mptcp_recvmsg_mskq(struct sock *sk, - struct msghdr *msg, - size_t len, int flags, +static int __mptcp_recvmsg_mskq(struct sock *sk, struct msghdr *msg, + size_t len, int flags, int copied_total, struct scm_timestamping_internal *tss, int *cmsg_flags) { struct mptcp_sock *msk = mptcp_sk(sk); struct sk_buff *skb, *tmp; + int total_data_len = 0; int copied = 0; skb_queue_walk_safe(&sk->sk_receive_queue, skb, tmp) { - u32 offset = MPTCP_SKB_CB(skb)->offset; + u32 delta, offset = MPTCP_SKB_CB(skb)->offset; u32 data_len = skb->len - offset; - u32 count = min_t(size_t, len - copied, data_len); + u32 count; int err; + if (flags & MSG_PEEK) { + /* skip already peeked skbs */ + if (total_data_len + data_len <= copied_total) { + total_data_len += data_len; + continue; + } + + /* skip the already peeked data in the current skb */ + delta = copied_total - total_data_len; + offset += delta; + data_len -= delta; + } + + count = min_t(size_t, len - copied, data_len); if (!(flags & MSG_TRUNC)) { err = skb_copy_datagram_msg(skb, offset, msg, count); if (unlikely(err < 0)) { @@ -1977,16 +1991,14 @@ static int __mptcp_recvmsg_mskq(struct sock *sk, copied += count; - if (count < data_len) { - if (!(flags & MSG_PEEK)) { + if (!(flags & MSG_PEEK)) { + msk->bytes_consumed += count; + if (count < data_len) { MPTCP_SKB_CB(skb)->offset += count; MPTCP_SKB_CB(skb)->map_seq += count; - msk->bytes_consumed += count; + break; } - break; - } - if (!(flags & MSG_PEEK)) { /* avoid the indirect call, we know the destructor is sock_rfree */ skb->destructor = NULL; skb->sk = NULL; @@ -1994,7 +2006,6 @@ static int __mptcp_recvmsg_mskq(struct sock *sk, sk_mem_uncharge(sk, skb->truesize); __skb_unlink(skb, &sk->sk_receive_queue); skb_attempt_defer_free(skb); - msk->bytes_consumed += count; } if (copied >= len) @@ -2191,7 +2202,8 @@ static int mptcp_recvmsg(struct sock *sk, struct msghdr *msg, size_t len, while (copied < len) { int err, bytes_read; - bytes_read = __mptcp_recvmsg_mskq(sk, msg, len - copied, flags, &tss, &cmsg_flags); + bytes_read = __mptcp_recvmsg_mskq(sk, msg, len - copied, flags, + copied, &tss, &cmsg_flags); if (unlikely(bytes_read < 0)) { if (!copied) copied = bytes_read;

1 month

3
5
0 0

[PATCH 6.12.y-5.10.y] selftests: mptcp: connect modes: re-add exec mode

by Matthieu Baerts (NGI0)

It looks like the execution permissions (+x) got lost during the backports of these new files. The issue is that some CIs don't execute these tests without that. Fixes: 37848a456fc3 ("selftests: mptcp: connect: also cover alt modes") Fixes: fdf0f60a2bb0 ("selftests: mptcp: connect: also cover checksum") Signed-off-by: Matthieu Baerts (NGI0) <matttbe(a)kernel.org> --- I'm not sure why they got lost, maybe Quilt doesn't support that? But then, can this patch still be applied? The same patch can be applied up to v5.10. In v5.10, only mptcp_connect_mmap.sh file is present, but I can send a dedicated patch for v5.10. --- tools/testing/selftests/net/mptcp/mptcp_connect_checksum.sh | 0 tools/testing/selftests/net/mptcp/mptcp_connect_mmap.sh | 0 tools/testing/selftests/net/mptcp/mptcp_connect_sendfile.sh | 0 3 files changed, 0 insertions(+), 0 deletions(-) mode change 100644 => 100755 tools/testing/selftests/net/mptcp/mptcp_connect_checksum.sh mode change 100644 => 100755 tools/testing/selftests/net/mptcp/mptcp_connect_mmap.sh mode change 100644 => 100755 tools/testing/selftests/net/mptcp/mptcp_connect_sendfile.sh diff --git a/tools/testing/selftests/net/mptcp/mptcp_connect_checksum.sh b/tools/testing/selftests/net/mptcp/mptcp_connect_checksum.sh old mode 100644 new mode 100755 diff --git a/tools/testing/selftests/net/mptcp/mptcp_connect_mmap.sh b/tools/testing/selftests/net/mptcp/mptcp_connect_mmap.sh old mode 100644 new mode 100755 diff --git a/tools/testing/selftests/net/mptcp/mptcp_connect_sendfile.sh b/tools/testing/selftests/net/mptcp/mptcp_connect_sendfile.sh old mode 100644 new mode 100755 -- 2.51.0

1 month

3
2
0 0

[PATCH 1/2] ASoC: codecs: Use component driver suspend/resume

by Claudiu

From: Claudiu Beznea <claudiu.beznea.uj(a)bp.renesas.com> Since snd_soc_suspend() is invoked through snd_soc_pm_ops->suspend(), and snd_soc_pm_ops is associated with the soc_driver (defined in sound/soc/soc-core.c), and there is no parent-child relationship between the soc_driver and the DA7213 codec driver, the power management subsystem does not enforce a specific suspend/resume order between the DA7213 driver and the soc_driver. Because of this, the different codec component functionalities, called from snd_soc_resume() to reconfigure various functions, can race with the DA7213 resume function, leading to misapplied configuration. This occasionally results in clipped sound. Fix this by moving the regmap cache operations into struct snd_soc_component_driver::{suspend, resume}. This ensures the proper configuration sequence is handled by the ASoC subsystem. Cc: stable(a)vger.kernel.org Fixes: 431e040065c8 ("ASoC: da7213: Add suspend to RAM support") Signed-off-by: Claudiu Beznea <claudiu.beznea.uj(a)bp.renesas.com> --- sound/soc/codecs/da7213.c | 38 +++++++++++++++++++++++++------------- 1 file changed, 25 insertions(+), 13 deletions(-) diff --git a/sound/soc/codecs/da7213.c b/sound/soc/codecs/da7213.c index c1657f348ad9..051806982bbe 100644 --- a/sound/soc/codecs/da7213.c +++ b/sound/soc/codecs/da7213.c @@ -2124,11 +2124,31 @@ static int da7213_probe(struct snd_soc_component *component) return 0; } +static int da7213_suspend(struct snd_soc_component *component) +{ + struct da7213_priv *da7213 = snd_soc_component_get_drvdata(component); + + regcache_cache_only(da7213->regmap, true); + regcache_mark_dirty(da7213->regmap); + + return 0; +} + +static int da7213_resume(struct snd_soc_component *component) +{ + struct da7213_priv *da7213 = snd_soc_component_get_drvdata(component); + + regcache_cache_only(da7213->regmap, false); + return regcache_sync(da7213->regmap); +} + static const struct snd_soc_component_driver soc_component_dev_da7213 = { .probe = da7213_probe, .set_bias_level = da7213_set_bias_level, .controls = da7213_snd_controls, .num_controls = ARRAY_SIZE(da7213_snd_controls), + .suspend = da7213_suspend, + .resume = da7213_resume, .dapm_widgets = da7213_dapm_widgets, .num_dapm_widgets = ARRAY_SIZE(da7213_dapm_widgets), .dapm_routes = da7213_audio_map, @@ -2228,27 +2248,19 @@ static int da7213_runtime_suspend(struct device *dev) { struct da7213_priv *da7213 = dev_get_drvdata(dev); - regcache_cache_only(da7213->regmap, true); - regcache_mark_dirty(da7213->regmap); - regulator_bulk_disable(DA7213_NUM_SUPPLIES, da7213->supplies); - - return 0; + return regulator_bulk_disable(DA7213_NUM_SUPPLIES, da7213->supplies); } static int da7213_runtime_resume(struct device *dev) { struct da7213_priv *da7213 = dev_get_drvdata(dev); - int ret; - ret = regulator_bulk_enable(DA7213_NUM_SUPPLIES, da7213->supplies); - if (ret < 0) - return ret; - regcache_cache_only(da7213->regmap, false); - return regcache_sync(da7213->regmap); + return regulator_bulk_enable(DA7213_NUM_SUPPLIES, da7213->supplies); } -static DEFINE_RUNTIME_DEV_PM_OPS(da7213_pm, da7213_runtime_suspend, - da7213_runtime_resume, NULL); +static const struct dev_pm_ops da7213_pm = { + RUNTIME_PM_OPS(da7213_runtime_suspend, da7213_runtime_resume, NULL) +}; static const struct i2c_device_id da7213_i2c_id[] = { { "da7213" }, -- 2.43.0

1 month

5
7
0 0

[PATCH] ksmbd: fix leak of transform buffer on encrypt_resp() failure

by Qianchang Zhao

When encrypt_resp() fails at the send path, we only set STATUS_DATA_ERROR but leave the transform buffer allocated (work->tr_buf in this tree). Repeating this path leaks kernel memory and can lead to OOM (DoS) when encryption is required. Reproduced on: Linux v6.18-rc2 (self-built test kernel) Fix by freeing the transform buffer and forcing plaintext error reply. Reported-by: Qianchang Zhao <pioooooooooip(a)gmail.com> Reported-by: Zhitong Liu <liuzhitong1993(a)gmail.com> Cc: stable(a)vger.kernel.org Signed-off-by: Qianchang Zhao <pioooooooooip(a)gmail.com> --- fs/smb/server/server.c | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/fs/smb/server/server.c b/fs/smb/server/server.c index 7b01c7589..15dd13e76 100644 --- a/fs/smb/server/server.c +++ b/fs/smb/server/server.c @@ -246,11 +246,11 @@ static void __handle_ksmbd_work(struct ksmbd_work *work, rc = conn->ops->encrypt_resp(work); if (rc < 0) { conn->ops->set_rsp_status(work, STATUS_DATA_ERROR); - work->encrypted = false; - if (work->tr_buf) { - kvfree(work->tr_buf); - work->tr_buf = NULL; - } + work->encrypted = false; + if (work->tr_buf) { + kvfree(work->tr_buf); + work->tr_buf = NULL; + } } } if (work->sess) -- 2.34.1

1 month

2
1
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror