August 2024 - Linux-stable-mirror

FAILED: patch "[PATCH] ipv4: fix source address selection with route leak" failed to apply to 5.15-stable tree

by gregkh＠linuxfoundation.org

The patch below does not apply to the 5.15-stable tree. If someone wants it applied there, or to any other stable or longterm tree, then please email the backport, including the original git commit id to <stable(a)vger.kernel.org>. To reproduce the conflict and resubmit, you may use the following commands: git fetch https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/ linux-5.15.y git checkout FETCH_HEAD git cherry-pick -x 6807352353561187a718e87204458999dbcbba1b # <resolve conflicts, build, test, etc.> git commit -s git send-email --to '<stable(a)vger.kernel.org>' --in-reply-to '2024072916-pastrami-suction-5192@gregkh' --subject-prefix 'PATCH 5.15.y' HEAD^.. Possible dependencies: 680735235356 ("ipv4: fix source address selection with route leak") thanks, greg k-h ------------------ original commit in Linus's tree ------------------ From 6807352353561187a718e87204458999dbcbba1b Mon Sep 17 00:00:00 2001 From: Nicolas Dichtel <nicolas.dichtel(a)6wind.com> Date: Wed, 10 Jul 2024 10:14:27 +0200 Subject: [PATCH] ipv4: fix source address selection with route leak By default, an address assigned to the output interface is selected when the source address is not specified. This is problematic when a route, configured in a vrf, uses an interface from another vrf (aka route leak). The original vrf does not own the selected source address. Let's add a check against the output interface and call the appropriate function to select the source address. CC: stable(a)vger.kernel.org Fixes: 8cbb512c923d ("net: Add source address lookup op for VRF") Signed-off-by: Nicolas Dichtel <nicolas.dichtel(a)6wind.com> Reviewed-by: David Ahern <dsahern(a)kernel.org> Link: https://patch.msgid.link/20240710081521.3809742-2-nicolas.dichtel@6wind.com Signed-off-by: Jakub Kicinski <kuba(a)kernel.org> diff --git a/net/ipv4/fib_semantics.c b/net/ipv4/fib_semantics.c index f669da98d11d..8956026bc0a2 100644 --- a/net/ipv4/fib_semantics.c +++ b/net/ipv4/fib_semantics.c @@ -2270,6 +2270,15 @@ void fib_select_path(struct net *net, struct fib_result *res, fib_select_default(fl4, res); check_saddr: - if (!fl4->saddr) - fl4->saddr = fib_result_prefsrc(net, res); + if (!fl4->saddr) { + struct net_device *l3mdev; + + l3mdev = dev_get_by_index_rcu(net, fl4->flowi4_l3mdev); + + if (!l3mdev || + l3mdev_master_dev_rcu(FIB_RES_DEV(*res)) == l3mdev) + fl4->saddr = fib_result_prefsrc(net, res); + else + fl4->saddr = inet_select_addr(l3mdev, 0, RT_SCOPE_LINK); + } }

8 months, 2 weeks

2
1
0 0

[PATCH 1/3] drm/amdgpu: Forward soft recovery errors to userspace

by Joshua Ashton

As we discussed before[1], soft recovery should be forwarded to userspace, or we can get into a really bad state where apps will keep submitting hanging command buffers cascading us to a hard reset. 1: https://lore.kernel.org/all/bf23d5ed-9a6b-43e7-84ee-8cbfd0d60f18@froggi.es/ Signed-off-by: Joshua Ashton <joshua(a)froggi.es> Cc: Friedrich Vock <friedrich.vock(a)gmx.de> Cc: Bas Nieuwenhuizen <bas(a)basnieuwenhuizen.nl> Cc: Christian König <christian.koenig(a)amd.com> Cc: André Almeida <andrealmeid(a)igalia.com> Cc: stable(a)vger.kernel.org --- drivers/gpu/drm/amd/amdgpu/amdgpu_job.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_job.c b/drivers/gpu/drm/amd/amdgpu/amdgpu_job.c index 4b3000c21ef2..aebf59855e9f 100644 --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_job.c +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_job.c @@ -262,9 +262,8 @@ amdgpu_job_prepare_job(struct drm_sched_job *sched_job, struct dma_fence *fence = NULL; int r; - /* Ignore soft recovered fences here */ r = drm_sched_entity_error(s_entity); - if (r && r != -ENODATA) + if (r) goto error; if (!fence && job->gang_submit) -- 2.44.0

8 months, 2 weeks

5
10
0 0

[PATCH net v1] net: wan: fsl_qmc_hdlc: Discard received CRC

by Herve Codina

Received frame from QMC contains the CRC. Upper layers don't need this CRC and tcpdump mentioned trailing junk data due to this CRC presence. As some other HDLC driver, simply discard this CRC. Fixes: d0f2258e79fd ("net: wan: Add support for QMC HDLC") Cc: stable(a)vger.kernel.org Signed-off-by: Herve Codina <herve.codina(a)bootlin.com> --- drivers/net/wan/fsl_qmc_hdlc.c | 24 ++++++++++++++++++------ 1 file changed, 18 insertions(+), 6 deletions(-) diff --git a/drivers/net/wan/fsl_qmc_hdlc.c b/drivers/net/wan/fsl_qmc_hdlc.c index 64b4bfa6fea7..8fcfbde31a1c 100644 --- a/drivers/net/wan/fsl_qmc_hdlc.c +++ b/drivers/net/wan/fsl_qmc_hdlc.c @@ -250,6 +250,7 @@ static void qmc_hcld_recv_complete(void *context, size_t length, unsigned int fl struct qmc_hdlc_desc *desc = context; struct net_device *netdev; struct qmc_hdlc *qmc_hdlc; + size_t crc_size; int ret; netdev = desc->netdev; @@ -268,15 +269,26 @@ static void qmc_hcld_recv_complete(void *context, size_t length, unsigned int fl if (flags & QMC_RX_FLAG_HDLC_CRC) /* CRC error */ netdev->stats.rx_crc_errors++; kfree_skb(desc->skb); - } else { - netdev->stats.rx_packets++; - netdev->stats.rx_bytes += length; + goto re_queue; + } - skb_put(desc->skb, length); - desc->skb->protocol = hdlc_type_trans(desc->skb, netdev); - netif_rx(desc->skb); + /* Discard the CRC */ + crc_size = qmc_hdlc->is_crc32 ? 4 : 2; + if (length < crc_size) { + netdev->stats.rx_length_errors++; + kfree_skb(desc->skb); + goto re_queue; } + length -= crc_size; + + netdev->stats.rx_packets++; + netdev->stats.rx_bytes += length; + + skb_put(desc->skb, length); + desc->skb->protocol = hdlc_type_trans(desc->skb, netdev); + netif_rx(desc->skb); +re_queue: /* Re-queue a transfer using the same descriptor */ ret = qmc_hdlc_recv_queue(qmc_hdlc, desc, desc->dma_size); if (ret) { -- 2.45.0

8 months, 2 weeks

4
3
0 0

[PATCH v4 RESEND] drm/client: fix null pointer dereference in drm_client_modeset_probe

by Ma Ke

In drm_client_modeset_probe(), the return value of drm_mode_duplicate() is assigned to modeset->mode, which will lead to a possible NULL pointer dereference on failure of drm_mode_duplicate(). Add a check to avoid npd. Cc: stable(a)vger.kernel.org Fixes: cf13909aee05 ("drm/fb-helper: Move out modeset config code") Signed-off-by: Ma Ke <make24(a)iscas.ac.cn> --- Changes in v4: - modified patch, set ret and break to handle error rightly. Changes in v3: - modified patch as suggestions, returned error directly when failing to get modeset->mode. Changes in v2: - added the recipient's email address, due to the prolonged absence of a response from the recipients. - added Cc stable. --- drivers/gpu/drm/drm_client_modeset.c | 5 +++++ 1 file changed, 5 insertions(+) diff --git a/drivers/gpu/drm/drm_client_modeset.c b/drivers/gpu/drm/drm_client_modeset.c index 31af5cf37a09..cee5eafbfb81 100644 --- a/drivers/gpu/drm/drm_client_modeset.c +++ b/drivers/gpu/drm/drm_client_modeset.c @@ -880,6 +880,11 @@ int drm_client_modeset_probe(struct drm_client_dev *client, unsigned int width, kfree(modeset->mode); modeset->mode = drm_mode_duplicate(dev, mode); + if (!modeset->mode) { + ret = -ENOMEM; + break; + } + drm_connector_get(connector); modeset->connectors[modeset->num_connectors++] = connector; modeset->x = offset->x; -- 2.25.1

8 months, 2 weeks

2
2
0 0

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

by Ma Ke

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

8 months, 2 weeks

2
1
0 0

[PATCH RESEND] EDAC/altera: Fix possible null pointer dereference

by Ma Ke

In altr_s10_sdram_check_ecc_deps(), of_get_address() may return NULL which is later dereferenced. Fix this bug by adding NULL check. Cc: stable(a)vger.kernel.org Fixes: e1bca853dddc ("EDAC/altera: Add SDRAM ECC check for U-Boot") Signed-off-by: Ma Ke <make24(a)iscas.ac.cn> --- drivers/edac/altera_edac.c | 11 +++++++++-- 1 file changed, 9 insertions(+), 2 deletions(-) diff --git a/drivers/edac/altera_edac.c b/drivers/edac/altera_edac.c index fe89f5c4837f..d6bf0eebeb41 100644 --- a/drivers/edac/altera_edac.c +++ b/drivers/edac/altera_edac.c @@ -1086,6 +1086,7 @@ static int altr_s10_sdram_check_ecc_deps(struct altr_edac_device_dev *device) struct arm_smccc_res result; struct device_node *np; phys_addr_t sdram_addr; + const __be32 *sdram_addrp; u32 read_reg; int ret; @@ -1093,8 +1094,14 @@ static int altr_s10_sdram_check_ecc_deps(struct altr_edac_device_dev *device) if (!np) goto sdram_err; - sdram_addr = of_translate_address(np, of_get_address(np, 0, - NULL, NULL)); + sdram_addrp = of_get_address(np, 0, NULL, NULL); + if (!sdram_addrp) + return -EINVAL; + + sdram_addr = of_translate_address(np, sdram_addrp); + if (!sdram_addr) + return -EINVAL; + of_node_put(np); sdram_ecc_addr = (unsigned long)sdram_addr + prv->ecc_en_ofst; arm_smccc_smc(INTEL_SIP_SMC_REG_READ, sdram_ecc_addr, -- 2.25.1

8 months, 2 weeks

2
1
0 0

[PATCH RESEND] drm/nouveau: fix a possible null pointer dereference

by Ma Ke

In ch7006_encoder_get_modes(), the return value of drm_mode_duplicate() is used directly in drm_mode_probed_add(), which will lead to a NULL pointer dereference on failure of drm_mode_duplicate(). Add a check to avoid npd. Cc: stable(a)vger.kernel.org Fixes: 6ee738610f41 ("drm/nouveau: Add DRM driver for NVIDIA GPUs") Signed-off-by: Ma Ke <make24(a)iscas.ac.cn> --- drivers/gpu/drm/i2c/ch7006_drv.c | 8 ++++++-- 1 file changed, 6 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/i2c/ch7006_drv.c b/drivers/gpu/drm/i2c/ch7006_drv.c index 131512a5f3bd..48bf6e4e8bdb 100644 --- a/drivers/gpu/drm/i2c/ch7006_drv.c +++ b/drivers/gpu/drm/i2c/ch7006_drv.c @@ -229,6 +229,7 @@ static int ch7006_encoder_get_modes(struct drm_encoder *encoder, { struct ch7006_priv *priv = to_ch7006_priv(encoder); const struct ch7006_mode *mode; + struct drm_display_mode *encoder_mode = NULL; int n = 0; for (mode = ch7006_modes; mode->mode.clock; mode++) { @@ -236,8 +237,11 @@ static int ch7006_encoder_get_modes(struct drm_encoder *encoder, ~mode->valid_norms & 1<<priv->norm) continue; - drm_mode_probed_add(connector, - drm_mode_duplicate(encoder->dev, &mode->mode)); + encoder_mode = drm_mode_duplicate(encoder->dev, &mode->mode); + if (!encoder_mode) + return 0; + + drm_mode_probed_add(connector, encoder_mode); n++; } -- 2.25.1

8 months, 2 weeks

1
0
0 0

Kazakhstan Crude Oil Product Offer REF:fqgzib01

by Antonov|DPR

Dear stable, I hope this message finds you well. My name is Antonov, and I am a sales representative authorized by leading refineries in Kazakhstan to negotiate the sale of crude oil products worldwide. If you are interested in purchasing crude oil products, we can facilitate the process. The refinery has sufficient product allocation to supply to serious buyers. We currently offer a range of products including Petcoke, Ultra- Low Sulphur Diesel, East Siberia-Pacific Ocean (ESPO) Blend, Russian Light Cycle Oil (LCO), LNG, LPG, Jet Fuel, and more. All our products meet SGS and GOST-R standards, and we guarantee timely delivery. Thank you for your attention. I look forward to your response and to discussing further details. Best regards, Antonov Message REF1: ieztudr02Q Message Timestamp: 8/2/2024 4:19:59 a.m.

8 months, 2 weeks

1
0
0 0

[PATCH v2 RESEND] dmaengine: moxart: handle irq_of_parse_and_map() errors

by Ma Ke

Zero and negative number is not a valid IRQ for in-kernel code and the irq_of_parse_and_map() function returns zero on error. So this check for valid IRQs should only accept values > 0. Cc: stable(a)vger.kernel.org Fixes: 2d9e31b9412c ("dmaengine: moxart: remove NO_IRQ") Signed-off-by: Ma Ke <make24(a)iscas.ac.cn> --- Changes in v2: - added Cc stable line; - added Fixes line. --- drivers/dma/moxart-dma.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/dma/moxart-dma.c b/drivers/dma/moxart-dma.c index 66dc6d31b603..16dd3c5aba4d 100644 --- a/drivers/dma/moxart-dma.c +++ b/drivers/dma/moxart-dma.c @@ -568,7 +568,7 @@ static int moxart_probe(struct platform_device *pdev) return -ENOMEM; irq = irq_of_parse_and_map(node, 0); - if (!irq) { + if (irq <= 0) { dev_err(dev, "no IRQ resource\n"); return -EINVAL; } -- 2.25.1

8 months, 2 weeks

1
0
0 0

[PATCH net 0/7] mptcp: fix endpoints with 'signal' and 'subflow' flags

by Matthieu Baerts (NGI0)

When looking at improving the user experience around the MPTCP endpoints setup, I noticed that setting an endpoint with both the 'signal' and the 'subflow' flags -- as it has been done in the past by users according to bug reports we got -- was resulting on only announcing the endpoint, but not using it to create subflows: the 'subflow' flag was then ignored. My initial thought was to modify IPRoute2 to warn the user when the two flags were set, but it doesn't sound normal to ignore one of them. I then looked at modifying the kernel not to allow having the two flags set, but when discussing about that with Mat, we thought it was maybe not ideal to do that, as there might be use-cases, we might break some configs. Then I saw it was working before v5.17. So instead, I fixed the support on the kernel side (patch 5) using Paolo's suggestion. This also includes a fix on the options side (patch 1: for v5.11+), an explicit deny of some options combinations (patch 2: for v5.18+), and some refactoring (patches 3 and 4) to ease the inclusion of the patch 5. While at it, I added a new selftest (patch 7) to validate this case -- including a modification of the chk_add_nr helper to inverse the sides were the counters are checked (patch 6) -- and allowed ADD_ADDR echo just after the MP_JOIN 3WHS. The selftests modification have the same Fixes tag as the previous commit, but no 'Cc: Stable': if the backport can work, that's good -- but it still need to be verified by running the selftests -- if not, no need to worry, many CIs will use the selftests from the last stable version to validate previous stable releases. Signed-off-by: Matthieu Baerts (NGI0) <matttbe(a)kernel.org> --- Matthieu Baerts (NGI0) (7): mptcp: fully established after ADD_ADDR echo on MPJ mptcp: pm: deny endp with signal + subflow + port mptcp: pm: reduce indentation blocks mptcp: pm: don't try to create sf if alloc failed mptcp: pm: do not ignore 'subflow' if 'signal' flag is also set selftests: mptcp: join: ability to invert ADD_ADDR check selftests: mptcp: join: test both signal & subflow net/mptcp/options.c | 3 +- net/mptcp/pm_netlink.c | 47 +++++++++++++-------- tools/testing/selftests/net/mptcp/mptcp_join.sh | 55 ++++++++++++++++++------- 3 files changed, 73 insertions(+), 32 deletions(-) --- base-commit: 0bf50cead4c4710d9f704778c32ab8af47ddf070 change-id: 20240731-upstream-net-20240731-mptcp-endp-subflow-signal-181d640cf5e8 Best regards, -- Matthieu Baerts (NGI0) <matttbe(a)kernel.org>

8 months, 2 weeks

2
5
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror August 2024