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

+ mm-huge_memory-fix-folio-split-check-for-anon-folios-in-swapcache.patch added to mm-hotfixes-unstable branch

by Andrew Morton

The patch titled Subject: mm/huge_memory: fix folio split check for anon folios in swapcache. has been added to the -mm mm-hotfixes-unstable branch. Its filename is mm-huge_memory-fix-folio-split-check-for-anon-folios-in-swapcache.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: Zi Yan <ziy(a)nvidia.com> Subject: mm/huge_memory: fix folio split check for anon folios in swapcache. Date: Wed, 5 Nov 2025 11:29:10 -0500 Both uniform and non uniform split check missed the check to prevent splitting anon folios in swapcache to non-zero order. Fix the check. Link: https://lkml.kernel.org/r/20251105162910.752266-1-ziy@nvidia.com Fixes: 58729c04cf10 ("mm/huge_memory: add buddy allocator like (non-uniform) folio_split()") Signed-off-by: Zi Yan <ziy(a)nvidia.com> Reported-by: "David Hildenbrand (Red Hat)" <david(a)kernel.org> Closes: https://lore.kernel.org/all/dc0ecc2c-4089-484f-917f-920fdca4c898@kernel.org/ Acked-by: David Hildenbrand (Red Hat) <david(a)kernel.org> Cc: Baolin Wang <baolin.wang(a)linux.alibaba.com> Cc: Barry Song <baohua(a)kernel.org> Cc: Dev Jain <dev.jain(a)arm.com> Cc: Lance Yang <lance.yang(a)linux.dev> Cc: Liam Howlett <liam.howlett(a)oracle.com> Cc: Lorenzo Stoakes <lorenzo.stoakes(a)oracle.com> Cc: Nico Pache <npache(a)redhat.com> Cc: Ryan Roberts <ryan.roberts(a)arm.com> Cc: Wei Yang <richard.weiyang(a)gmail.com> Cc: <stable(a)vger.kernel.org> Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> --- mm/huge_memory.c | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-) --- a/mm/huge_memory.c~mm-huge_memory-fix-folio-split-check-for-anon-folios-in-swapcache +++ a/mm/huge_memory.c @@ -3522,7 +3522,8 @@ bool non_uniform_split_supported(struct /* order-1 is not supported for anonymous THP. */ VM_WARN_ONCE(warns && new_order == 1, "Cannot split to order-1 folio"); - return new_order != 1; + if (new_order == 1) + return false; } else if (IS_ENABLED(CONFIG_READ_ONLY_THP_FOR_FS) && !mapping_large_folio_support(folio->mapping)) { /* @@ -3553,7 +3554,8 @@ bool uniform_split_supported(struct foli if (folio_test_anon(folio)) { VM_WARN_ONCE(warns && new_order == 1, "Cannot split to order-1 folio"); - return new_order != 1; + if (new_order == 1) + return false; } else if (new_order) { if (IS_ENABLED(CONFIG_READ_ONLY_THP_FOR_FS) && !mapping_large_folio_support(folio->mapping)) { _ Patches currently in -mm which might be from ziy(a)nvidia.com are mm-huge_memory-do-not-change-split_huge_page-target-order-silently.patch mm-huge_memory-preserve-pg_has_hwpoisoned-if-a-folio-is-split-to-0-order.patch mm-huge_memory-fix-folio-split-check-for-anon-folios-in-swapcache.patch mm-huge_memory-add-split_huge_page_to_order.patch mm-memory-failure-improve-large-block-size-folio-handling.patch mm-huge_memory-fix-kernel-doc-comments-for-folio_split-and-related.patch mm-huge_memory-fix-kernel-doc-comments-for-folio_split-and-related-fix.patch

1 month, 2 weeks

1
0
0 0

[PATCH 01/11] KVM: nSVM: Fix consistency checks for NP_ENABLE

by Yosry Ahmed

KVM currenty fails a nested VMRUN and injects VMEXIT_INVALID (aka SVM_EXIT_ERR) if L1 sets NP_ENABLE and the host does not support NPTs. On first glance, it seems like the check should actually be for guest_cpu_cap_has(X86_FEATURE_NPT) instead, as it is possible for the host to support NPTs but the guest CPUID to not advertise it. However, the consistency check is not architectural to begin with. The APM does not mention VMEXIT_INVALID if NP_ENABLE is set on a processor that does not have X86_FEATURE_NPT. Hence, NP_ENABLE should be ignored if X86_FEATURE_NPT is not available for L1. Apart from the consistency check, this is currently the case because NP_ENABLE is actually copied from VMCB01 to VMCB02, not from VMCB12. On the other hand, the APM does mention two other consistency checks for NP_ENABLE, both of which are missing (paraphrased): In Volume #2, 15.25.3 (24593—Rev. 3.42—March 2024): If VMRUN is executed with hCR0.PG cleared to zero and NP_ENABLE set to 1, VMRUN terminates with #VMEXIT(VMEXIT_INVALID) In Volume #2, 15.25.4 (24593—Rev. 3.42—March 2024): When VMRUN is executed with nested paging enabled (NP_ENABLE = 1), the following conditions are considered illegal state combinations, in addition to those mentioned in “Canonicalization and Consistency Checks”: • Any MBZ bit of nCR3 is set. • Any G_PAT.PA field has an unsupported type encoding or any reserved field in G_PAT has a nonzero value. Replace the existing consistency check with consistency checks on hCR0.PG and nCR3. The G_PAT consistency check will be addressed separately. Pass L1's CR0 to __nested_vmcb_check_controls(). In nested_vmcb_check_controls(), L1's CR0 is available through kvm_read_cr0(), as vcpu->arch.cr0 is not updated to L2's CR0 until later through nested_vmcb02_prepare_save() -> svm_set_cr0(). In svm_set_nested_state(), L1's CR0 is available in the captured save area, as svm_get_nested_state() captures L1's save area when running L2, and L1's CR0 is stashed in VMCB01 on nested VMRUN (in nested_svm_vmrun()). Fixes: 4b16184c1cca ("KVM: SVM: Initialize Nested Nested MMU context on VMRUN") Cc: stable(a)vger.kernel.org Signed-off-by: Yosry Ahmed <yosry.ahmed(a)linux.dev> --- arch/x86/kvm/svm/nested.c | 21 ++++++++++++++++----- arch/x86/kvm/svm/svm.h | 3 ++- 2 files changed, 18 insertions(+), 6 deletions(-) diff --git a/arch/x86/kvm/svm/nested.c b/arch/x86/kvm/svm/nested.c index 83de3456df708..9a534f04bdc83 100644 --- a/arch/x86/kvm/svm/nested.c +++ b/arch/x86/kvm/svm/nested.c @@ -325,7 +325,8 @@ static bool nested_svm_check_bitmap_pa(struct kvm_vcpu *vcpu, u64 pa, u32 size) } static bool __nested_vmcb_check_controls(struct kvm_vcpu *vcpu, - struct vmcb_ctrl_area_cached *control) + struct vmcb_ctrl_area_cached *control, + unsigned long l1_cr0) { if (CC(!vmcb12_is_intercept(control, INTERCEPT_VMRUN))) return false; @@ -333,8 +334,12 @@ static bool __nested_vmcb_check_controls(struct kvm_vcpu *vcpu, if (CC(control->asid == 0)) return false; - if (CC((control->nested_ctl & SVM_NESTED_CTL_NP_ENABLE) && !npt_enabled)) - return false; + if (control->nested_ctl & SVM_NESTED_CTL_NP_ENABLE) { + if (CC(!kvm_vcpu_is_legal_gpa(vcpu, control->nested_cr3))) + return false; + if (CC(!(l1_cr0 & X86_CR0_PG))) + return false; + } if (CC(!nested_svm_check_bitmap_pa(vcpu, control->msrpm_base_pa, MSRPM_SIZE))) @@ -400,7 +405,12 @@ static bool nested_vmcb_check_controls(struct kvm_vcpu *vcpu) struct vcpu_svm *svm = to_svm(vcpu); struct vmcb_ctrl_area_cached *ctl = &svm->nested.ctl; - return __nested_vmcb_check_controls(vcpu, ctl); + /* + * Make sure we did not enter guest mode yet, in which case + * kvm_read_cr0() could return L2's CR0. + */ + WARN_ON_ONCE(is_guest_mode(vcpu)); + return __nested_vmcb_check_controls(vcpu, ctl, kvm_read_cr0(vcpu)); } static @@ -1832,7 +1842,8 @@ static int svm_set_nested_state(struct kvm_vcpu *vcpu, ret = -EINVAL; __nested_copy_vmcb_control_to_cache(vcpu, &ctl_cached, ctl); - if (!__nested_vmcb_check_controls(vcpu, &ctl_cached)) + /* 'save' contains L1 state saved from before VMRUN */ + if (!__nested_vmcb_check_controls(vcpu, &ctl_cached, save->cr0)) goto out_free; /* diff --git a/arch/x86/kvm/svm/svm.h b/arch/x86/kvm/svm/svm.h index 6765a5e433cea..0a2908e22d746 100644 --- a/arch/x86/kvm/svm/svm.h +++ b/arch/x86/kvm/svm/svm.h @@ -552,7 +552,8 @@ static inline bool gif_set(struct vcpu_svm *svm) static inline bool nested_npt_enabled(struct vcpu_svm *svm) { - return svm->nested.ctl.nested_ctl & SVM_NESTED_CTL_NP_ENABLE; + return guest_cpu_cap_has(&svm->vcpu, X86_FEATURE_NPT) && + svm->nested.ctl.nested_ctl & SVM_NESTED_CTL_NP_ENABLE; } static inline bool nested_vnmi_enabled(struct vcpu_svm *svm) -- 2.51.2.1026.g39e6a42477-goog

1 month, 2 weeks

1
1
0 0

Inquiry from Varelt SRL Company Sales Order

by VARELT IMPORT SRL

1 month, 2 weeks

1
0
0 0

Re: Patch "iio: light: isl29125: Use iio_push_to_buffers_with_ts() to allow source size runtime check" has been added to the 6.17-stable tree

by Jonathan Cameron

On Tue, 4 Nov 2025 18:36:44 -0500 Sasha Levin <sashal(a)kernel.org> wrote: > This is a note to let you know that I've just added the patch titled > > iio: light: isl29125: Use iio_push_to_buffers_with_ts() to allow source size runtime check > > 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: > iio-light-isl29125-use-iio_push_to_buffers_with_ts-t.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. > This isn't a fix. Harmless if another fix needs it for context but in of itself not otherwise appropriate for stable. The hardening is against code bugs and there isn't one here - longer term we want to deprecate and remove the old interface. J > > > commit 72afc12515b357d26a5ce4f0149379ef797e3e37 > Author: Jonathan Cameron <Jonathan.Cameron(a)huawei.com> > Date: Sat Aug 2 17:44:29 2025 +0100 > > iio: light: isl29125: Use iio_push_to_buffers_with_ts() to allow source size runtime check > > [ Upstream commit f0ffec3b4fa7e430f92302ee233c79aeb021fe14 ] > > Also move the structure used as the source to the stack as it is only 16 > bytes and not the target of an DMA or similar. > > Reviewed-by: Matti Vaittinen <mazziesaccount(a)gmail.com> > Reviewed-by: Andy Shevchenko <andy(a)kernel.org> > Link: https://patch.msgid.link/20250802164436.515988-10-jic23@kernel.org > Signed-off-by: Jonathan Cameron <Jonathan.Cameron(a)huawei.com> > Signed-off-by: Sasha Levin <sashal(a)kernel.org> > > diff --git a/drivers/iio/light/isl29125.c b/drivers/iio/light/isl29125.c > index 6bc23b164cc55..3acb8a4f1d120 100644 > --- a/drivers/iio/light/isl29125.c > +++ b/drivers/iio/light/isl29125.c > @@ -51,11 +51,6 @@ > struct isl29125_data { > struct i2c_client *client; > u8 conf1; > - /* Ensure timestamp is naturally aligned */ > - struct { > - u16 chans[3]; > - aligned_s64 timestamp; > - } scan; > }; > > #define ISL29125_CHANNEL(_color, _si) { \ > @@ -179,6 +174,11 @@ static irqreturn_t isl29125_trigger_handler(int irq, void *p) > struct iio_dev *indio_dev = pf->indio_dev; > struct isl29125_data *data = iio_priv(indio_dev); > int i, j = 0; > + /* Ensure timestamp is naturally aligned */ > + struct { > + u16 chans[3]; > + aligned_s64 timestamp; > + } scan = { }; > > iio_for_each_active_channel(indio_dev, i) { > int ret = i2c_smbus_read_word_data(data->client, > @@ -186,10 +186,10 @@ static irqreturn_t isl29125_trigger_handler(int irq, void *p) > if (ret < 0) > goto done; > > - data->scan.chans[j++] = ret; > + scan.chans[j++] = ret; > } > > - iio_push_to_buffers_with_timestamp(indio_dev, &data->scan, > + iio_push_to_buffers_with_ts(indio_dev, &scan, sizeof(scan), > iio_get_time_ns(indio_dev)); > > done: >

1 month, 2 weeks

2
1
0 0

[PATCH 0/2] media: staging: imx: fix multiple video input

by Michael Tretter

If the IMX media pipeline is configured to receive multiple video inputs, the second input stream may be broken on start. This happens if the IMX CSI hardware has to be reconfigured for the second stream, while the first stream is already running. The IMX CSI driver configures the IMX CSI in the link_validate callback. The media pipeline is only validated on the first start. Thus, any later start of the media pipeline skips the validation and directly starts streaming. This may leave the hardware in an inconsistent state compared to the driver configuration. Moving the hardware configuration to the stream start to make sure that the hardware is configured correctly. Patch 1 removes the caching of the upstream mbus_config in csi_link_validate and explicitly request the mbus_config in csi_start, to get rid of this implicit dependency. Patch 2 actually moves the hardware register setting from csi_link_validate to csi_start to fix the skipped hardware reconfiguration. Signed-off-by: Michael Tretter <michael.tretter(a)pengutronix.de> --- Michael Tretter (2): media: staging: imx: request mbus_config in csi_start media: staging: imx: configure src_mux in csi_start drivers/staging/media/imx/imx-media-csi.c | 84 ++++++++++++++++++------------- 1 file changed, 48 insertions(+), 36 deletions(-) --- base-commit: 27afd6e066cfd80ddbe22a4a11b99174ac89cced change-id: 20251105-media-imx-fixes-acef77c7ba12 Best regards, -- Michael Tretter <m.tretter(a)pengutronix.de>

1 month, 2 weeks

3
5
0 0

[PATCH] iio: trigger: Fix error handling in viio_trigger_alloc

by Ma Ke

viio_trigger_alloc() initializes the device with device_initialize() but uses kfree() directly in error paths, which bypasses the device's release callback iio_trig_release(). This could lead to memory leaks and inconsistent device state. Replace kfree(trig) with put_device(&trig->dev) in error paths to ensure proper cleanup through the device's release callback. Found by code review. Cc: stable(a)vger.kernel.org Fixes: 2c99f1a09da3 ("iio: trigger: clean up viio_trigger_alloc()") Signed-off-by: Ma Ke <make24(a)iscas.ac.cn> --- drivers/iio/industrialio-trigger.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/iio/industrialio-trigger.c b/drivers/iio/industrialio-trigger.c index 54416a384232..981e19757870 100644 --- a/drivers/iio/industrialio-trigger.c +++ b/drivers/iio/industrialio-trigger.c @@ -597,7 +597,7 @@ struct iio_trigger *viio_trigger_alloc(struct device *parent, free_descs: irq_free_descs(trig->subirq_base, CONFIG_IIO_CONSUMERS_PER_TRIGGER); free_trig: - kfree(trig); + put_device(&trig->dev); return NULL; } -- 2.17.1

1 month, 2 weeks

2
2
0 0

[PATCH net v7] virtio-net: fix received length check in big packets

by Bui Quang Minh

Since commit 4959aebba8c0 ("virtio-net: use mtu size as buffer length for big packets"), when guest gso is off, the allocated size for big packets is not MAX_SKB_FRAGS * PAGE_SIZE anymore but depends on negotiated MTU. The number of allocated frags for big packets is stored in vi->big_packets_num_skbfrags. Because the host announced buffer length can be malicious (e.g. the host vhost_net driver's get_rx_bufs is modified to announce incorrect length), we need a check in virtio_net receive path. Currently, the check is not adapted to the new change which can lead to NULL page pointer dereference in the below while loop when receiving length that is larger than the allocated one. This commit fixes the received length check corresponding to the new change. Fixes: 4959aebba8c0 ("virtio-net: use mtu size as buffer length for big packets") Cc: stable(a)vger.kernel.org Signed-off-by: Bui Quang Minh <minhquangbui99(a)gmail.com> --- Changes in v7: - Fix typos - Link to v6: https://lore.kernel.org/netdev/20251028143116.4532-1-minhquangbui99@gmail.c… Changes in v6: - Fix the length check - Link to v5: https://lore.kernel.org/netdev/20251024150649.22906-1-minhquangbui99@gmail.… Changes in v5: - Move the length check to receive_big - Link to v4: https://lore.kernel.org/netdev/20251022160623.51191-1-minhquangbui99@gmail.… Changes in v4: - Remove unrelated changes, add more comments - Link to v3: https://lore.kernel.org/netdev/20251021154534.53045-1-minhquangbui99@gmail.… Changes in v3: - Convert BUG_ON to WARN_ON_ONCE - Link to v2: https://lore.kernel.org/netdev/20250708144206.95091-1-minhquangbui99@gmail.… Changes in v2: - Remove incorrect give_pages call - Link to v1: https://lore.kernel.org/netdev/20250706141150.25344-1-minhquangbui99@gmail.… --- drivers/net/virtio_net.c | 25 ++++++++++++------------- 1 file changed, 12 insertions(+), 13 deletions(-) diff --git a/drivers/net/virtio_net.c b/drivers/net/virtio_net.c index a757cbcab87f..421b9aa190a0 100644 --- a/drivers/net/virtio_net.c +++ b/drivers/net/virtio_net.c @@ -910,17 +910,6 @@ static struct sk_buff *page_to_skb(struct virtnet_info *vi, goto ok; } - /* - * Verify that we can indeed put this data into a skb. - * This is here to handle cases when the device erroneously - * tries to receive more than is possible. This is usually - * the case of a broken device. - */ - if (unlikely(len > MAX_SKB_FRAGS * PAGE_SIZE)) { - net_dbg_ratelimited("%s: too much data\n", skb->dev->name); - dev_kfree_skb(skb); - return NULL; - } BUG_ON(offset >= PAGE_SIZE); while (len) { unsigned int frag_size = min((unsigned)PAGE_SIZE - offset, len); @@ -2107,9 +2096,19 @@ static struct sk_buff *receive_big(struct net_device *dev, struct virtnet_rq_stats *stats) { struct page *page = buf; - struct sk_buff *skb = - page_to_skb(vi, rq, page, 0, len, PAGE_SIZE, 0); + struct sk_buff *skb; + + /* Make sure that len does not exceed the size allocated in + * add_recvbuf_big. + */ + if (unlikely(len > (vi->big_packets_num_skbfrags + 1) * PAGE_SIZE)) { + pr_debug("%s: rx error: len %u exceeds allocated size %lu\n", + dev->name, len, + (vi->big_packets_num_skbfrags + 1) * PAGE_SIZE); + goto err; + } + skb = page_to_skb(vi, rq, page, 0, len, PAGE_SIZE, 0); u64_stats_add(&stats->bytes, len - vi->hdr_len); if (unlikely(!skb)) goto err; -- 2.43.0

1 month, 2 weeks

5
5
0 0

[PATCH] RDMA/rtrs: server: Fix error handling in get_or_create_srv

by Ma Ke

get_or_create_srv() fails to call put_device() after device_initialize() when memory allocation fails. This could cause reference count leaks during error handling, preventing proper device cleanup and resulting in memory leaks. Found by code review. Cc: stable(a)vger.kernel.org Fixes: 9cb837480424 ("RDMA/rtrs: server: main functionality") Signed-off-by: Ma Ke <make24(a)iscas.ac.cn> --- drivers/infiniband/ulp/rtrs/rtrs-srv.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/infiniband/ulp/rtrs/rtrs-srv.c b/drivers/infiniband/ulp/rtrs/rtrs-srv.c index ef4abdea3c2d..9ecc6343455d 100644 --- a/drivers/infiniband/ulp/rtrs/rtrs-srv.c +++ b/drivers/infiniband/ulp/rtrs/rtrs-srv.c @@ -1450,7 +1450,7 @@ static struct rtrs_srv_sess *get_or_create_srv(struct rtrs_srv_ctx *ctx, kfree(srv->chunks); err_free_srv: - kfree(srv); + put_device(&srv->dev); return ERR_PTR(-ENOMEM); } -- 2.17.1

1 month, 2 weeks

5
5
0 0

[PATCH net v4 2/3] net,mptcp: fix proto fallback detection with BPF

by Jiayuan Chen

The sockmap feature allows bpf syscall from userspace, or based on bpf sockops, replacing the sk_prot of sockets during protocol stack processing with sockmap's custom read/write interfaces. ''' tcp_rcv_state_process() syn_recv_sock()/subflow_syn_recv_sock() tcp_init_transfer(BPF_SOCK_OPS_PASSIVE_ESTABLISHED_CB) bpf_skops_established <== sockops bpf_sock_map_update(sk) <== call bpf helper tcp_bpf_update_proto() <== update sk_prot ''' When the server has MPTCP enabled but the client sends a TCP SYN without MPTCP, subflow_syn_recv_sock() performs a fallback on the subflow, replacing the subflow sk's sk_prot with the native sk_prot. ''' subflow_syn_recv_sock() subflow_ulp_fallback() subflow_drop_ctx() mptcp_subflow_ops_undo_override() ''' Then, this subflow can be normally used by sockmap, which replaces the native sk_prot with sockmap's custom sk_prot. The issue occurs when the user executes accept::mptcp_stream_accept::mptcp_fallback_tcp_ops(). Here, it uses sk->sk_prot to compare with the native sk_prot, but this is incorrect when sockmap is used, as we may incorrectly set sk->sk_socket->ops. This fix uses the more generic sk_family for the comparison instead. Additionally, this also prevents a WARNING from occurring: ------------[ cut here ]------------ WARNING: CPU: 1 PID: 388 at net/mptcp/protocol.c:68 \ mptcp_stream_accept+0x34c/0x380 Modules linked in: RIP: 0010:mptcp_stream_accept+0x34c/0x380 RSP: 0018:ffffc90000cf3cf8 EFLAGS: 00010202 PKRU: 55555554 Call Trace: <TASK> do_accept+0xeb/0x190 ? __x64_sys_pselect6+0x61/0x80 ? _raw_spin_unlock+0x12/0x30 ? alloc_fd+0x11e/0x190 __sys_accept4+0x8c/0x100 __x64_sys_accept+0x1f/0x30 x64_sys_call+0x202f/0x20f0 do_syscall_64+0x72/0x9a0 ? switch_fpu_return+0x60/0xf0 ? irqentry_exit_to_user_mode+0xdb/0x1e0 ? irqentry_exit+0x3f/0x50 ? clear_bhb_loop+0x50/0xa0 ? clear_bhb_loop+0x50/0xa0 ? clear_bhb_loop+0x50/0xa0 entry_SYSCALL_64_after_hwframe+0x76/0x7e </TASK> ---[ end trace 0000000000000000 ]--- result from ./scripts/decode_stacktrace.sh: ------------[ cut here ]------------ WARNING: CPU: 0 PID: 337 at net/mptcp/protocol.c:68 mptcp_stream_accept \ (net-next/net/mptcp/protocol.c:4005) Modules linked in: ... PKRU: 55555554 Call Trace: <TASK> do_accept (net-next/net/socket.c:1989) __sys_accept4 (net-next/net/socket.c:2028 net-next/net/socket.c:2057) __x64_sys_accept (net-next/net/socket.c:2067) x64_sys_call (net-next/arch/x86/entry/syscall_64.c:41) do_syscall_64 (net-next/arch/x86/entry/syscall_64.c:63 \ net-next/arch/x86/entry/syscall_64.c:94) entry_SYSCALL_64_after_hwframe (net-next/arch/x86/entry/entry_64.S:130) RIP: 0033:0x7f87ac92b83d ---[ end trace 0000000000000000 ]--- Fixes: 0b4f33def7bb ("mptcp: fix tcp fallback crash") Cc: <stable(a)vger.kernel.org> Signed-off-by: Jiayuan Chen <jiayuan.chen(a)linux.dev> Reviewed-by: Jakub Sitnicki <jakub(a)cloudflare.com> --- net/mptcp/protocol.c | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/net/mptcp/protocol.c b/net/mptcp/protocol.c index 4cd5df01446e..b5e5e130b158 100644 --- a/net/mptcp/protocol.c +++ b/net/mptcp/protocol.c @@ -61,11 +61,13 @@ static u64 mptcp_wnd_end(const struct mptcp_sock *msk) static const struct proto_ops *mptcp_fallback_tcp_ops(const struct sock *sk) { + unsigned short family = READ_ONCE(sk->sk_family); + #if IS_ENABLED(CONFIG_MPTCP_IPV6) - if (sk->sk_prot == &tcpv6_prot) + if (family == AF_INET6) return &inet6_stream_ops; #endif - WARN_ON_ONCE(sk->sk_prot != &tcp_prot); + WARN_ON_ONCE(family != AF_INET); return &inet_stream_ops; } -- 2.43.0

1 month, 2 weeks

2
1
0 0

[PATCH net v4 1/3] mptcp: disallow MPTCP subflows from sockmap

by Jiayuan Chen

The sockmap feature allows bpf syscall from userspace using , or based on bpf sockops, replacing the sk_prot of sockets during protocol stack processing with sockmap's custom read/write interfaces. ''' tcp_rcv_state_process() subflow_syn_recv_sock() tcp_init_transfer(BPF_SOCK_OPS_PASSIVE_ESTABLISHED_CB) bpf_skops_established <== sockops bpf_sock_map_update(sk) <== call bpf helper tcp_bpf_update_proto() <== update sk_prot ''' Consider two scenarios: 1. When the server has MPTCP enabled and the client also requests MPTCP, the sk passed to the BPF program is a subflow sk. Since subflows only handle partial data, replacing their sk_prot is meaningless and will cause traffic disruption. 2. When the server has MPTCP enabled but the client sends a TCP SYN without MPTCP, subflow_syn_recv_sock() performs a fallback on the subflow, replacing the subflow sk's sk_prot with the native sk_prot. ''' subflow_ulp_fallback() subflow_drop_ctx() mptcp_subflow_ops_undo_override() ''' Subsequently, accept::mptcp_stream_accept::mptcp_fallback_tcp_ops() converts the subflow to plain TCP. For the first case, we should prevent it from being combined with sockmap by setting sk_prot->psock_update_sk_prot to NULL, which will be blocked by sockmap's own flow. For the second case, since subflow_syn_recv_sock() has already restored sk_prot to native tcp_prot/tcpv6_prot, no further action is needed. Fixes: 0b4f33def7bb ("mptcp: fix tcp fallback crash") Cc: <stable(a)vger.kernel.org> Signed-off-by: Jiayuan Chen <jiayuan.chen(a)linux.dev> --- net/mptcp/subflow.c | 8 ++++++++ 1 file changed, 8 insertions(+) diff --git a/net/mptcp/subflow.c b/net/mptcp/subflow.c index 30961b3d1702..ddd0fc6fcf45 100644 --- a/net/mptcp/subflow.c +++ b/net/mptcp/subflow.c @@ -2144,6 +2144,10 @@ void __init mptcp_subflow_init(void) tcp_prot_override = tcp_prot; tcp_prot_override.release_cb = tcp_release_cb_override; tcp_prot_override.diag_destroy = tcp_abort_override; +#ifdef CONFIG_BPF_SYSCALL + /* Disable sockmap processing for subflows */ + tcp_prot_override.psock_update_sk_prot = NULL; +#endif #if IS_ENABLED(CONFIG_MPTCP_IPV6) /* In struct mptcp_subflow_request_sock, we assume the TCP request sock @@ -2180,6 +2184,10 @@ void __init mptcp_subflow_init(void) tcpv6_prot_override = tcpv6_prot; tcpv6_prot_override.release_cb = tcp_release_cb_override; tcpv6_prot_override.diag_destroy = tcp_abort_override; +#ifdef CONFIG_BPF_SYSCALL + /* Disable sockmap processing for subflows */ + tcpv6_prot_override.psock_update_sk_prot = NULL; +#endif #endif mptcp_diag_subflow_init(&subflow_ulp_ops); -- 2.43.0

1 month, 2 weeks

2
1
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror