February 2025 - Linux-stable-mirror

[PATCH 6.6 0/2] Set the bpf_net_context before invoking BPF XDP in the TUN driver

by Ricardo Cañuelo Navarro

A private syzbot instance reported "KASAN: slab-use-after-free Read in dev_map_enqueue" under some runtime environments. Upstream patch fecef4cd42c6 ("tun: Assign missing bpf_net_context") fixes the issue. In order to bring this patch to stable v6.6 it's also necessary to bring upstream patch 401cb7dae813 ("net: Reference bpf_redirect_info via task_struct on PREEMPT_RT.") as a dependency. Signed-off-by: Ricardo Cañuelo Navarro <rcn(a)igalia.com> --- Sebastian Andrzej Siewior (2): net: Reference bpf_redirect_info via task_struct on PREEMPT_RT. tun: Assign missing bpf_net_context. drivers/net/tun.c | 7 +++++++ include/linux/filter.h | 56 +++++++++++++++++++++++++++++++++++++++++--------- include/linux/sched.h | 3 +++ kernel/bpf/cpumap.c | 3 +++ kernel/bpf/devmap.c | 9 +++++++- kernel/fork.c | 1 + net/bpf/test_run.c | 11 +++++++++- net/core/dev.c | 33 ++++++++++++++++++++++++++++- net/core/filter.c | 41 +++++++++++------------------------- net/core/lwt_bpf.c | 3 +++ 10 files changed, 125 insertions(+), 42 deletions(-) --- base-commit: c0249d3a0c3cf082d56f4285647ddba19ef604a7 change-id: 20250224-20250204-kasan-slab-use-after-free-read-in-dev_map_enqueue__submit-b907af839805 Best regards, -- Ricardo Cañuelo Navarro <rcn(a)igalia.com>

1 week

3
7
0 0

FAILED: patch "[PATCH] gve: set xdp redirect target only when it is available" failed to apply to 6.6-stable tree

by gregkh＠linuxfoundation.org

The patch below does not apply to the 6.6-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.6.y git checkout FETCH_HEAD git cherry-pick -x 415cadd505464d9a11ff5e0f6e0329c127849da5 # <resolve conflicts, build, test, etc.> git commit -s git send-email --to '<stable(a)vger.kernel.org>' --in-reply-to '2025022437-molecular-next-d0f6@gregkh' --subject-prefix 'PATCH 6.6.y' HEAD^.. Possible dependencies: thanks, greg k-h ------------------ original commit in Linus's tree ------------------ From 415cadd505464d9a11ff5e0f6e0329c127849da5 Mon Sep 17 00:00:00 2001 From: Joshua Washington <joshwash(a)google.com> Date: Fri, 14 Feb 2025 14:43:59 -0800 Subject: [PATCH] gve: set xdp redirect target only when it is available Before this patch the NETDEV_XDP_ACT_NDO_XMIT XDP feature flag is set by default as part of driver initialization, and is never cleared. However, this flag differs from others in that it is used as an indicator for whether the driver is ready to perform the ndo_xdp_xmit operation as part of an XDP_REDIRECT. Kernel helpers xdp_features_(set|clear)_redirect_target exist to convey this meaning. This patch ensures that the netdev is only reported as a redirect target when XDP queues exist to forward traffic. Fixes: 39a7f4aa3e4a ("gve: Add XDP REDIRECT support for GQI-QPL format") Cc: stable(a)vger.kernel.org Reviewed-by: Praveen Kaligineedi <pkaligineedi(a)google.com> Reviewed-by: Jeroen de Borst <jeroendb(a)google.com> Signed-off-by: Joshua Washington <joshwash(a)google.com> Link: https://patch.msgid.link/20250214224417.1237818-1-joshwash@google.com Signed-off-by: Jakub Kicinski <kuba(a)kernel.org> diff --git a/drivers/net/ethernet/google/gve/gve.h b/drivers/net/ethernet/google/gve/gve.h index 8167cc5fb0df..78d2a19593d1 100644 --- a/drivers/net/ethernet/google/gve/gve.h +++ b/drivers/net/ethernet/google/gve/gve.h @@ -1116,6 +1116,16 @@ static inline u32 gve_xdp_tx_start_queue_id(struct gve_priv *priv) return gve_xdp_tx_queue_id(priv, 0); } +static inline bool gve_supports_xdp_xmit(struct gve_priv *priv) +{ + switch (priv->queue_format) { + case GVE_GQI_QPL_FORMAT: + return true; + default: + return false; + } +} + /* gqi napi handler defined in gve_main.c */ int gve_napi_poll(struct napi_struct *napi, int budget); diff --git a/drivers/net/ethernet/google/gve/gve_main.c b/drivers/net/ethernet/google/gve/gve_main.c index 533e659b15b3..92237fb0b60c 100644 --- a/drivers/net/ethernet/google/gve/gve_main.c +++ b/drivers/net/ethernet/google/gve/gve_main.c @@ -1903,6 +1903,8 @@ static void gve_turndown(struct gve_priv *priv) /* Stop tx queues */ netif_tx_disable(priv->dev); + xdp_features_clear_redirect_target(priv->dev); + gve_clear_napi_enabled(priv); gve_clear_report_stats(priv); @@ -1972,6 +1974,9 @@ static void gve_turnup(struct gve_priv *priv) napi_schedule(&block->napi); } + if (priv->num_xdp_queues && gve_supports_xdp_xmit(priv)) + xdp_features_set_redirect_target(priv->dev, false); + gve_set_napi_enabled(priv); } @@ -2246,7 +2251,6 @@ static void gve_set_netdev_xdp_features(struct gve_priv *priv) if (priv->queue_format == GVE_GQI_QPL_FORMAT) { xdp_features = NETDEV_XDP_ACT_BASIC; xdp_features |= NETDEV_XDP_ACT_REDIRECT; - xdp_features |= NETDEV_XDP_ACT_NDO_XMIT; xdp_features |= NETDEV_XDP_ACT_XSK_ZEROCOPY; } else { xdp_features = 0;

1 week

3
2
0 0

[PATCH 6.1.y] media: mtk-vcodec: potential null pointer deference in SCP

by jianqi.ren.cn＠windriver.com

From: Fullway Wang <fullwaywang(a)outlook.com> [ Upstream commit 53dbe08504442dc7ba4865c09b3bbf5fe849681b ] The return value of devm_kzalloc() needs to be checked to avoid NULL pointer deference. This is similar to CVE-2022-3113. Link: https://lore.kernel.org/linux-media/PH7PR20MB5925094DAE3FD750C7E39E01BF712@… Signed-off-by: Fullway Wang <fullwaywang(a)outlook.com> Signed-off-by: Mauro Carvalho Chehab <mchehab(a)kernel.org> [ To fix CVE-2024-40973, change the file path from drivers/media/platform/mediatek/vcodec/common/mtk_vcodec_fw_scp.c to drivers/media/platform/mediatek/vcodec/mtk_vcodec_fw_scp.c and minor conflict resolution ] Signed-off-by: Jianqi Ren <jianqi.ren.cn(a)windriver.com> Signed-off-by: He Zhe <zhe.he(a)windriver.com> --- Verified the build test. --- drivers/media/platform/mediatek/vcodec/mtk_vcodec_fw_scp.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/media/platform/mediatek/vcodec/mtk_vcodec_fw_scp.c b/drivers/media/platform/mediatek/vcodec/mtk_vcodec_fw_scp.c index d8e66b645bd8..27f08b1d34d1 100644 --- a/drivers/media/platform/mediatek/vcodec/mtk_vcodec_fw_scp.c +++ b/drivers/media/platform/mediatek/vcodec/mtk_vcodec_fw_scp.c @@ -65,6 +65,8 @@ struct mtk_vcodec_fw *mtk_vcodec_fw_scp_init(struct mtk_vcodec_dev *dev) } fw = devm_kzalloc(&dev->plat_dev->dev, sizeof(*fw), GFP_KERNEL); + if (!fw) + return ERR_PTR(-ENOMEM); fw->type = SCP; fw->ops = &mtk_vcodec_rproc_msg; fw->scp = scp; -- 2.25.1

1 week

2
1
0 0

[PATCH 5.10] crypto: tcrypt - Fix missing return value check

by Denis Arefev

From: Tianjia Zhang <tianjia.zhang(a)linux.alibaba.com> commit 7b3d52683b3a47c0ba1dfd6b5994a3a795b06972 upstream. There are several places where the return value check of crypto_aead_setkey and crypto_aead_setauthsize were lost. It is necessary to add these checks. At the same time, move the crypto_aead_setauthsize() call out of the loop, and only need to call it once after load transform. Fixes: 53f52d7aecb4 ("crypto: tcrypt - Added speed tests for AEAD crypto alogrithms in tcrypt test suite") Signed-off-by: Tianjia Zhang <tianjia.zhang(a)linux.alibaba.com> Reviewed-by: Vitaly Chikunov <vt(a)altlinux.org> Signed-off-by: Herbert Xu <herbert(a)gondor.apana.org.au> [Denis: minor fix to resolve merge conflict.] Signed-off-by: Denis Arefev <arefev(a)swemel.ru> --- crypto/tcrypt.c | 29 +++++++++++++++++++---------- 1 file changed, 19 insertions(+), 10 deletions(-) diff --git a/crypto/tcrypt.c b/crypto/tcrypt.c index 7972d2784b3b..580c50afa587 100644 --- a/crypto/tcrypt.c +++ b/crypto/tcrypt.c @@ -290,6 +290,11 @@ static void test_mb_aead_speed(const char *algo, int enc, int secs, } ret = crypto_aead_setauthsize(tfm, authsize); + if (ret) { + pr_err("alg: aead: Failed to setauthsize for %s: %d\n", algo, + ret); + goto out_free_tfm; + } for (i = 0; i < num_mb; ++i) if (testmgr_alloc_buf(data[i].xbuf)) { @@ -315,7 +320,7 @@ static void test_mb_aead_speed(const char *algo, int enc, int secs, for (i = 0; i < num_mb; ++i) { data[i].req = aead_request_alloc(tfm, GFP_KERNEL); if (!data[i].req) { - pr_err("alg: skcipher: Failed to allocate request for %s\n", + pr_err("alg: aead: Failed to allocate request for %s\n", algo); while (i--) aead_request_free(data[i].req); @@ -565,13 +570,19 @@ static void test_aead_speed(const char *algo, int enc, unsigned int secs, sgout = &sg[9]; tfm = crypto_alloc_aead(algo, 0, 0); - if (IS_ERR(tfm)) { pr_err("alg: aead: Failed to load transform for %s: %ld\n", algo, PTR_ERR(tfm)); goto out_notfm; } + ret = crypto_aead_setauthsize(tfm, authsize); + if (ret) { + pr_err("alg: aead: Failed to setauthsize for %s: %d\n", algo, + ret); + goto out_noreq; + } + crypto_init_wait(&wait); printk(KERN_INFO "\ntesting speed of %s (%s) %s\n", algo, get_driver_name(crypto_aead, tfm), e); @@ -607,8 +618,13 @@ static void test_aead_speed(const char *algo, int enc, unsigned int secs, break; } } + ret = crypto_aead_setkey(tfm, key, *keysize); - ret = crypto_aead_setauthsize(tfm, authsize); + if (ret) { + pr_err("setkey() failed flags=%x: %d\n", + crypto_aead_get_flags(tfm), ret); + goto out; + } iv_len = crypto_aead_ivsize(tfm); if (iv_len) @@ -618,15 +634,8 @@ static void test_aead_speed(const char *algo, int enc, unsigned int secs, printk(KERN_INFO "test %u (%d bit key, %d byte blocks): ", i, *keysize * 8, *b_size); - memset(tvmem[0], 0xff, PAGE_SIZE); - if (ret) { - pr_err("setkey() failed flags=%x\n", - crypto_aead_get_flags(tfm)); - goto out; - } - sg_init_aead(sg, xbuf, *b_size + (enc ? 0 : authsize), assoc, aad_size); -- 2.43.0

1 week

2
1
0 0

FAILED: patch "[PATCH] arm64: dts: rockchip: Disable DMA for uart5 on px30-ringneck" failed to apply to 6.6-stable tree

by gregkh＠linuxfoundation.org

The patch below does not apply to the 6.6-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.6.y git checkout FETCH_HEAD git cherry-pick -x 5ae4dca718eacd0a56173a687a3736eb7e627c77 # <resolve conflicts, build, test, etc.> git commit -s git send-email --to '<stable(a)vger.kernel.org>' --in-reply-to '2025022438-automated-recycled-cc12@gregkh' --subject-prefix 'PATCH 6.6.y' HEAD^.. Possible dependencies: thanks, greg k-h ------------------ original commit in Linus's tree ------------------ From 5ae4dca718eacd0a56173a687a3736eb7e627c77 Mon Sep 17 00:00:00 2001 From: Lukasz Czechowski <lukasz.czechowski(a)thaumatec.com> Date: Tue, 21 Jan 2025 13:56:04 +0100 Subject: [PATCH] arm64: dts: rockchip: Disable DMA for uart5 on px30-ringneck MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit UART controllers without flow control seem to behave unstable in case DMA is enabled. The issues were indicated in the message: https://lore.kernel.org/linux-arm-kernel/CAMdYzYpXtMocCtCpZLU_xuWmOp2Ja_v0A… In case of PX30-uQ7 Ringneck SoM, it was noticed that after couple of hours of UART communication, the CPU stall was occurring, leading to the system becoming unresponsive. After disabling the DMA, extensive UART communication tests for up to two weeks were performed, and no issues were further observed. The flow control pins for uart5 are not available on PX30-uQ7 Ringneck, as configured by pinctrl-0, so the DMA nodes were removed on SoM dtsi. Cc: stable(a)vger.kernel.org Fixes: c484cf93f61b ("arm64: dts: rockchip: add PX30-µQ7 (Ringneck) SoM with Haikou baseboard") Reviewed-by: Quentin Schulz <quentin.schulz(a)cherry.de> Signed-off-by: Lukasz Czechowski <lukasz.czechowski(a)thaumatec.com> Link: https://lore.kernel.org/r/20250121125604.3115235-3-lukasz.czechowski@thauma… Signed-off-by: Heiko Stuebner <heiko(a)sntech.de> diff --git a/arch/arm64/boot/dts/rockchip/px30-ringneck.dtsi b/arch/arm64/boot/dts/rockchip/px30-ringneck.dtsi index 2c87005c89bd..e80412abec08 100644 --- a/arch/arm64/boot/dts/rockchip/px30-ringneck.dtsi +++ b/arch/arm64/boot/dts/rockchip/px30-ringneck.dtsi @@ -397,6 +397,8 @@ &u2phy_host { }; &uart5 { + /delete-property/ dmas; + /delete-property/ dma-names; pinctrl-0 = <&uart5_xfer>; };

1 week

5
4
0 0

[PATCH v6.1-v5.4 1/1] pfifo_tail_enqueue: Drop new packet when sch->limit == 0

by Lee Jones

[ Upstream commit 647cef20e649c576dff271e018d5d15d998b629d ] Expected behaviour: In case we reach scheduler's limit, pfifo_tail_enqueue() will drop a packet in scheduler's queue and decrease scheduler's qlen by one. Then, pfifo_tail_enqueue() enqueue new packet and increase scheduler's qlen by one. Finally, pfifo_tail_enqueue() return `NET_XMIT_CN` status code. Weird behaviour: In case we set `sch->limit == 0` and trigger pfifo_tail_enqueue() on a scheduler that has no packet, the 'drop a packet' step will do nothing. This means the scheduler's qlen still has value equal 0. Then, we continue to enqueue new packet and increase scheduler's qlen by one. In summary, we can leverage pfifo_tail_enqueue() to increase qlen by one and return `NET_XMIT_CN` status code. The problem is: Let's say we have two qdiscs: Qdisc_A and Qdisc_B. - Qdisc_A's type must have '->graft()' function to create parent/child relationship. Let's say Qdisc_A's type is `hfsc`. Enqueue packet to this qdisc will trigger `hfsc_enqueue`. - Qdisc_B's type is pfifo_head_drop. Enqueue packet to this qdisc will trigger `pfifo_tail_enqueue`. - Qdisc_B is configured to have `sch->limit == 0`. - Qdisc_A is configured to route the enqueued's packet to Qdisc_B. Enqueue packet through Qdisc_A will lead to: - hfsc_enqueue(Qdisc_A) -> pfifo_tail_enqueue(Qdisc_B) - Qdisc_B->q.qlen += 1 - pfifo_tail_enqueue() return `NET_XMIT_CN` - hfsc_enqueue() check for `NET_XMIT_SUCCESS` and see `NET_XMIT_CN` => hfsc_enqueue() don't increase qlen of Qdisc_A. The whole process lead to a situation where Qdisc_A->q.qlen == 0 and Qdisc_B->q.qlen == 1. Replace 'hfsc' with other type (for example: 'drr') still lead to the same problem. This violate the design where parent's qlen should equal to the sum of its childrens'qlen. Bug impact: This issue can be used for user->kernel privilege escalation when it is reachable. Fixes: 57dbb2d83d10 ("sched: add head drop fifo queue") Reported-by: Quang Le <quanglex97(a)gmail.com> Signed-off-by: Quang Le <quanglex97(a)gmail.com> Signed-off-by: Cong Wang <cong.wang(a)bytedance.com> Link: https://patch.msgid.link/20250204005841.223511-2-xiyou.wangcong@gmail.com Signed-off-by: Jakub Kicinski <kuba(a)kernel.org> Signed-off-by: Sasha Levin <sashal(a)kernel.org> [Lee: Backported to linux-6.6.y - fixed a minor surrounding diff conflict] (cherry picked from commit e40cb34b7f247fe2e366fd192700d1b4f38196ca) Signed-off-by: Lee Jones <lee(a)kernel.org> --- - Applies cleanly to v6.1, v5.15, v5.10 and v5.4 net/sched/sch_fifo.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/net/sched/sch_fifo.c b/net/sched/sch_fifo.c index e1040421b797..af5f2ab69b8d 100644 --- a/net/sched/sch_fifo.c +++ b/net/sched/sch_fifo.c @@ -39,6 +39,9 @@ static int pfifo_tail_enqueue(struct sk_buff *skb, struct Qdisc *sch, { unsigned int prev_backlog; + if (unlikely(READ_ONCE(sch->limit) == 0)) + return qdisc_drop(skb, sch, to_free); + if (likely(sch->q.qlen < sch->limit)) return qdisc_enqueue_tail(skb, sch); -- 2.48.1.658.g4767266eb4-goog

1 week

1
0
0 0

[BUG] r8188eu: Potential deadlocks in rtw_wx_set_wap/essid functions

by Gui-Dong Han

Hello maintainers, I would like to report a potential lock ordering issue in the r8188eu driver. This may lead to deadlocks under certain conditions. The functions rtw_wx_set_wap() and rtw_wx_set_essid() acquire locks in an order that contradicts the established locking hierarchy observed in other parts of the driver: 1. They first take &pmlmepriv->scanned_queue.lock 2. Then call rtw_set_802_11_infrastructure_mode() which takes &pmlmepriv->lock This is inverted compared to the common pattern seen in functions like rtw_joinbss_event_prehandle(), rtw_createbss_cmd_callback(), and others, which typically: 1. Take &pmlmepriv->lock first 2. Then take &pmlmepriv->scanned_queue.lock This lock inversion creates a potential deadlock scenario when these code paths execute concurrently. Moreover, the call chain: rtw_wx_set_* -> rtw_set_802_11_infrastructure_mode() -> rtw_free_assoc_resources() could lead to recursive acquisition of &pmlmepriv->scanned_queue.lock, potentially causing self-deadlock even without concurrency. This issue exists in longterm kernels containing the r8188eu driver: 5.4.y (until 5.4.290) 5.10.y (until 5.10.234) 5.15.y (until 5.15.178) 6.1.y (until 6.1.129) The r8188eu driver has been removed from upstream, but older maintained versions (5.4.x–6.1.x) still include this driver and are affected. This issue was identified through static analysis. While I've verified the locking patterns through code review, I'm not sufficiently familiar with the driver's internals to propose a safe fix. Thank you for your attention to this matter. Best regards, Gui-Dong Han

1 week

3
2
0 0

[PATCH 5.10.y 0/3] vsock: fix use-after free and null-ptr-deref

by Luigi Leonardi

Hi all, This series backports three upstream commits: - 135ffc7 "bpf, vsock: Invoke proto::close on close()" - fcdd224 "vsock: Keep the binding until socket destruction" - 78dafe1 "vsock: Orphan socket after transport release" Although this version of the kernel does not support sockmap, I think backporting this patch can be useful to reduce conflicts in future backports [1]. It does not harm the system. The comment it introduces in the code can be misleading. I added some words in the commit to explain the situation. The other two commits are untouched, fixing a use-after free[2] and a null-ptr-deref[3] respectively. [1]https://lore.kernel.org/stable/f7lr3ftzo66sl6phlcygh4xx4spga4b6je37fhawjr… [2]https://lore.kernel.org/all/20250128-vsock-transport-vs-autobind-v3-0-1cf… [3]https://lore.kernel.org/all/20250210-vsock-linger-nullderef-v3-0-ef6244d0… Cheers, Luigi To: Stefano Garzarella <sgarzare(a)redhat.com> To: Michal Luczaj <mhal(a)rbox.co> To: stable(a)vger.kernel.org Signed-off-by: Luigi Leonardi <leonardi(a)redhat.com> --- Michal Luczaj (3): bpf, vsock: Invoke proto::close on close() vsock: Keep the binding until socket destruction vsock: Orphan socket after transport release net/vmw_vsock/af_vsock.c | 77 +++++++++++++++++++++++++++++++----------------- 1 file changed, 50 insertions(+), 27 deletions(-) --- base-commit: f0a53361993a94f602df6f35e78149ad2ac12c89 change-id: 20250220-backport_fix_5_10-0ae85f834bc4 Best regards, -- Luigi Leonardi <leonardi(a)redhat.com>

1 week

1
3
0 0

[PATCH 1/3] perf/x86: Fix low freq setting issue

by kan.liang＠linux.intel.com

From: Kan Liang <kan.liang(a)linux.intel.com> Perf doesn't work with a low freq. perf record -e cpu_core/instructions/ppp -F 120 Error: The sys_perf_event_open() syscall returned with 22 (Invalid argument) for event (cpu_core/instructions/ppp). "dmesg | grep -i perf" may provide additional information. The limit_period() check avoids a low sampling period on a counter. It doesn't intend to limit the frequency. The check in the x86_pmu_hw_config() should be limited to non-freq mode. The attr.sample_period and attr.sample_freq are union. The attr.sample_period should not be used to indicate the freq mode. Fixes: c46e665f0377 ("perf/x86: Add INST_RETIRED.ALL workarounds") Closes: https://lore.kernel.org/lkml/20250115154949.3147-1-ravi.bangoria@amd.com/ Signed-off-by: Kan Liang <kan.liang(a)linux.intel.com> Cc: Andi Kleen <ak(a)linux.intel.com> Cc: Ravi Bangoria <ravi.bangoria(a)amd.com> Cc: stable(a)vger.kernel.org --- arch/x86/events/core.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/x86/events/core.c b/arch/x86/events/core.c index 7b6430e5a77b..20ad5cca6ad2 100644 --- a/arch/x86/events/core.c +++ b/arch/x86/events/core.c @@ -630,7 +630,7 @@ int x86_pmu_hw_config(struct perf_event *event) if (event->attr.type == event->pmu->type) event->hw.config |= x86_pmu_get_event_config(event); - if (event->attr.sample_period && x86_pmu.limit_period) { + if (!event->attr.freq && x86_pmu.limit_period) { s64 left = event->attr.sample_period; x86_pmu.limit_period(event, &left); if (left > event->attr.sample_period) -- 2.38.1

1 week

3
5
0 0

[PATCH 6.1.y 0/3] vsock: fix use-after free and null-ptr-deref

by Luigi Leonardi

Hi all, This series backports three upstream commits: - 135ffc7 "bpf, vsock: Invoke proto::close on close()" - fcdd224 "vsock: Keep the binding until socket destruction" - 78dafe1 "vsock: Orphan socket after transport release" Although this version of the kernel does not support sockmap, I think backporting this patch can be useful to reduce conflicts in future backports [1]. It does not harm the system. The comment it introduces in the code can be misleading. I added some words in the commit to explain the situation. The other two commits are untouched, fixing a use-after free[2] and a null-ptr-deref[3] respectively. [1]https://lore.kernel.org/stable/f7lr3ftzo66sl6phlcygh4xx4spga4b6je37fhawjr… [2]https://lore.kernel.org/all/20250128-vsock-transport-vs-autobind-v3-0-1cf… [3]https://lore.kernel.org/all/20250210-vsock-linger-nullderef-v3-0-ef6244d0… Cheers, Luigi To: Stefano Garzarella <sgarzare(a)redhat.com> To: Michal Luczaj <mhal(a)rbox.co> To: stable(a)vger.kernel.org Signed-off-by: Luigi Leonardi <leonardi(a)redhat.com> --- Michal Luczaj (3): bpf, vsock: Invoke proto::close on close() vsock: Keep the binding until socket destruction vsock: Orphan socket after transport release net/vmw_vsock/af_vsock.c | 77 +++++++++++++++++++++++++++++++----------------- 1 file changed, 50 insertions(+), 27 deletions(-) --- base-commit: 0cbb5f65e52f3e66410a7fe0edf75e1b2bf41e80 change-id: 20250220-backport_fix-9a9a58f64f14 Best regards, -- Luigi Leonardi <leonardi(a)redhat.com>

1 week

1
3
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror February 2025