August 2024 - Linux-stable-mirror

[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

1 month, 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

1 month, 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

1 month, 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

1 month, 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

1 month, 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.

1 month, 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

1 month, 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>

1 month, 2 weeks

2
5
0 0

[PATCH iwl-net 2/3] idpf: fix memleak in vport interrupt configuration

by Alexander Lobakin

From: Michal Kubiak <michal.kubiak(a)intel.com> The initialization of vport interrupt consists of two functions: 1) idpf_vport_intr_init() where a generic configuration is done 2) idpf_vport_intr_req_irq() where the irq for each q_vector is requested. The first function used to create a base name for each interrupt using "kasprintf()" call. Unfortunately, although that call allocated memory for a text buffer, that memory was never released. Fix this by removing creating the interrupt base name in 1). Instead, always create a full interrupt name in the function 2), because there is no need to create a base name separately, considering that the function 2) is never called out of idpf_vport_intr_init() context. Fixes: d4d558718266 ("idpf: initialize interrupts and enable vport") Cc: stable(a)vger.kernel.org # 6.7 Signed-off-by: Michal Kubiak <michal.kubiak(a)intel.com> Reviewed-by: Pavan Kumar Linga <pavan.kumar.linga(a)intel.com> Signed-off-by: Alexander Lobakin <aleksander.lobakin(a)intel.com> --- drivers/net/ethernet/intel/idpf/idpf_txrx.c | 19 ++++++++----------- 1 file changed, 8 insertions(+), 11 deletions(-) diff --git a/drivers/net/ethernet/intel/idpf/idpf_txrx.c b/drivers/net/ethernet/intel/idpf/idpf_txrx.c index af2879f03b8d..a2f9f252694a 100644 --- a/drivers/net/ethernet/intel/idpf/idpf_txrx.c +++ b/drivers/net/ethernet/intel/idpf/idpf_txrx.c @@ -3780,13 +3780,15 @@ void idpf_vport_intr_update_itr_ena_irq(struct idpf_q_vector *q_vector) /** * idpf_vport_intr_req_irq - get MSI-X vectors from the OS for the vport * @vport: main vport structure - * @basename: name for the vector */ -static int idpf_vport_intr_req_irq(struct idpf_vport *vport, char *basename) +static int idpf_vport_intr_req_irq(struct idpf_vport *vport) { struct idpf_adapter *adapter = vport->adapter; + const char *drv_name, *if_name, *vec_name; int vector, err, irq_num, vidx; - const char *vec_name; + + drv_name = dev_driver_string(&adapter->pdev->dev); + if_name = netdev_name(vport->netdev); for (vector = 0; vector < vport->num_q_vectors; vector++) { struct idpf_q_vector *q_vector = &vport->q_vectors[vector]; @@ -3804,8 +3806,8 @@ static int idpf_vport_intr_req_irq(struct idpf_vport *vport, char *basename) else continue; - name = kasprintf(GFP_KERNEL, "%s-%s-%d", basename, vec_name, - vidx); + name = kasprintf(GFP_KERNEL, "%s-%s-%s-%d", drv_name, if_name, + vec_name, vidx); err = request_irq(irq_num, idpf_vport_intr_clean_queues, 0, name, q_vector); @@ -4326,7 +4328,6 @@ int idpf_vport_intr_alloc(struct idpf_vport *vport) */ int idpf_vport_intr_init(struct idpf_vport *vport) { - char *int_name; int err; err = idpf_vport_intr_init_vec_idx(vport); @@ -4340,11 +4341,7 @@ int idpf_vport_intr_init(struct idpf_vport *vport) if (err) goto unroll_vectors_alloc; - int_name = kasprintf(GFP_KERNEL, "%s-%s", - dev_driver_string(&vport->adapter->pdev->dev), - vport->netdev->name); - - err = idpf_vport_intr_req_irq(vport, int_name); + err = idpf_vport_intr_req_irq(vport); if (err) goto unroll_vectors_alloc; -- 2.45.2

1 month, 2 weeks

3
2
0 0

Re: [v6.1] WARNING in ieee80211_check_rate_mask

by syzbot

syzbot suspects this issue could be fixed by backporting the following commit: commit ce04abc3fcc62cd5640af981ebfd7c4dc3bded28 git tree: upstream Author: Johannes Berg <johannes.berg(a)intel.com> Date: Fri Feb 24 09:52:19 2023 +0000 wifi: mac80211: check basic rates validity bisection log: https://syzkaller.appspot.com/x/bisect.txt?x=15d0b26d980000 kernel config: https://syzkaller.appspot.com/x/.config?x=59059e181681c079 dashboard link: https://syzkaller.appspot.com/bug?extid=07bee335584b04e7c2f8 syz repro: https://syzkaller.appspot.com/x/repro.syz?x=122bb7a5180000 C reproducer: https://syzkaller.appspot.com/x/repro.c?x=14dfa479180000 Please keep in mind that other backports might be required as well. For information about bisection process see: https://goo.gl/tpsmEJ#bisection

1 month, 2 weeks

1
0
0 0

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror August 2024