March 2022 - Linux-stable-mirror

Cherry-pick request to fix CVE-2022-0886 in v5.10 and v5.4

by Vaibhav Rustagi

Hi Greg, To fix CVE-2022-0886 in v5.10 and v5.4, we need to cherry-pick the commit "esp: Fix possible buffer overflow in ESP transformation" (ebe48d368e97d007bfeb76fcb065d6cfc4c96645). The commit didn't apply cleanly in v5.10 and v5.4 and therefore, patches for both the kernel versions are attached. In order to backport the original commit, following changes are done: - v5.10: - "SKB_FRAG_PAGE_ORDER" declaration is moved from "net/core/sock.c" to "include/net/sock.c" - v5.4: - "SKB_FRAG_PAGE_ORDER" declaration is moved from "net/core/sock.c" to "include/net/sock.c" - Ignore changes introduced due to `xfrm: add support for UDPv6 encapsulation of ESP` in esp6_output_head() Can you help in cherry-picking the commit to above stable branches? Thanks, Vaibhav

2 years, 9 months

2
6
0 0

FAILED: patch "[PATCH] cgroup-v1: Correct privileges check in release_agent writes" failed to apply to 5.10-stable tree

by gregkh＠linuxfoundation.org

The patch below does not apply to the 5.10-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>. thanks, greg k-h ------------------ original commit in Linus's tree ------------------ From 467a726b754f474936980da793b4ff2ec3e382a7 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Michal=20Koutn=C3=BD?= <mkoutny(a)suse.com> Date: Thu, 17 Feb 2022 17:11:28 +0100 Subject: [PATCH] cgroup-v1: Correct privileges check in release_agent writes MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit The idea is to check: a) the owning user_ns of cgroup_ns, b) capabilities in init_user_ns. The commit 24f600856418 ("cgroup-v1: Require capabilities to set release_agent") got this wrong in the write handler of release_agent since it checked user_ns of the opener (may be different from the owning user_ns of cgroup_ns). Secondly, to avoid possibly confused deputy, the capability of the opener must be checked. Fixes: 24f600856418 ("cgroup-v1: Require capabilities to set release_agent") Cc: stable(a)vger.kernel.org Link: https://lore.kernel.org/stable/20220216121142.GB30035@blackbody.suse.cz/ Signed-off-by: Michal Koutný <mkoutny(a)suse.com> Reviewed-by: Masami Ichikawa(CIP) <masami.ichikawa(a)cybertrust.co.jp> Signed-off-by: Tejun Heo <tj(a)kernel.org> diff --git a/kernel/cgroup/cgroup-v1.c b/kernel/cgroup/cgroup-v1.c index 0e877dbcfeea..afc6c0e9c966 100644 --- a/kernel/cgroup/cgroup-v1.c +++ b/kernel/cgroup/cgroup-v1.c @@ -546,6 +546,7 @@ static ssize_t cgroup_release_agent_write(struct kernfs_open_file *of, char *buf, size_t nbytes, loff_t off) { struct cgroup *cgrp; + struct cgroup_file_ctx *ctx; BUILD_BUG_ON(sizeof(cgrp->root->release_agent_path) < PATH_MAX); @@ -553,8 +554,9 @@ static ssize_t cgroup_release_agent_write(struct kernfs_open_file *of, * Release agent gets called with all capabilities, * require capabilities to set release agent. */ - if ((of->file->f_cred->user_ns != &init_user_ns) || - !capable(CAP_SYS_ADMIN)) + ctx = of->priv; + if ((ctx->ns->user_ns != &init_user_ns) || + !file_ns_capable(of->file, &init_user_ns, CAP_SYS_ADMIN)) return -EPERM; cgrp = cgroup_kn_lock_live(of->kn, false);

2 years, 9 months

3
7
0 0

Apply "exfat: avoid incorrectly releasing for root inode" to stable 5.10

by Tadeusz Struk

Hi, Please apply 839a534f1e85 ("exfat: avoid incorrectly releasing for root inode") to stable 5.10.y Syzbot can still trigger a BUG: https://syzkaller.appspot.com/bug?id=0896bca762e93f26a3922dc0822313a7be65a3… It is already applied to all versions above 5.10. -- Thanks, Tadeusz

2 years, 9 months

2
1
0 0

apply commit net: ipv6: fix skb_over_panic in __ip6_append_data to stable

by Tadeusz Struk

Hi, Please apply commit 5e34af4142ff ("net: ipv6: fix skb_over_panic in __ip6_append_data") to stable: 5.15, 5.10, 5.4, 4.19, 4.14, 4.9. It applies to all versions. -- Thanks, Tadeusz

2 years, 9 months

2
1
0 0

[PATCH] nfc: st21nfca: Fix potential buffer overflows in EVT_TRANSACTION

by Denis Efremov

From: Jordy Zomer <jordy(a)pwning.systems> It appears that there are some buffer overflows in EVT_TRANSACTION. This happens because the length parameters that are passed to memcpy come directly from skb->data and are not guarded in any way. Link: https://lore.kernel.org/all/20220111164451.3232987-1-jordy@pwning.systems/#t Fixes: 26fc6c7f02cb ("NFC: st21nfca: Add HCI transaction event support") Cc: stable(a)vger.kernel.org # 4.0+ Signed-off-by: Jordy Zomer <jordy(a)pwning.systems> Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski(a)canonical.com> Signed-off-by: David S. Miller <davem(a)davemloft.net> Signed-off-by: Denis Efremov <denis.e.efremov(a)oracle.com> --- CVE-2022-26490 was assigned to this patch. It looks like it's not in the stable trees yet. I only added Link:/Fixes:/Cc: stable... to the commit's message. drivers/nfc/st21nfca/se.c | 10 ++++++++++ 1 file changed, 10 insertions(+) diff --git a/drivers/nfc/st21nfca/se.c b/drivers/nfc/st21nfca/se.c index a43fc4117fa5..c922f10d0d7b 100644 --- a/drivers/nfc/st21nfca/se.c +++ b/drivers/nfc/st21nfca/se.c @@ -316,6 +316,11 @@ int st21nfca_connectivity_event_received(struct nfc_hci_dev *hdev, u8 host, return -ENOMEM; transaction->aid_len = skb->data[1]; + + /* Checking if the length of the AID is valid */ + if (transaction->aid_len > sizeof(transaction->aid)) + return -EINVAL; + memcpy(transaction->aid, &skb->data[2], transaction->aid_len); @@ -325,6 +330,11 @@ int st21nfca_connectivity_event_received(struct nfc_hci_dev *hdev, u8 host, return -EPROTO; transaction->params_len = skb->data[transaction->aid_len + 3]; + + /* Total size is allocated (skb->len - 2) minus fixed array members */ + if (transaction->params_len > ((skb->len - 2) - sizeof(struct nfc_evt_transaction))) + return -EINVAL; + memcpy(transaction->params, skb->data + transaction->aid_len + 4, transaction->params_len); -- 2.35.1

2 years, 9 months

2
3
0 0

nfsd patches to fix deadlock

by Khazhy Kumykov

Please consider the following 2 patches for stable 5.4. They applied cleanly to 5.4.y for me, and fix a deadlock we have experienced. (See discussion at https://lore.kernel.org/linux-nfs/a9cf9bcd72a187127b73042a9369e17bd5a0e93d.… ). These patches are from 5.5, so newer kernels should not need it. I looked at 4.19, and it looks like this issue should not exist in that kernel (we don't have filecache.c and it's associated shrinker). I have not looked at older kernels, but presume the issue also does not apply there. 9542e6a643fc ("nfsd: Containerise filecache laundrette") 36ebbdb96b69 ("nfsd: cleanup nfsd_file_lru_dispose()")

2 years, 9 months

2
1
0 0

Re: [PATCH] net: stmmac: dwmac-qcom-ethqos: Enable RGMII functional clock on resume

by Bhupesh Sharma

+Cc: stable tree as I think this is an important fix for stmmac dwmac-qcom-ethernet driver and affects ethernet functionality on QCOM boards which use this driver. More below.. On Wed, 23 Mar 2022 at 09:01, Bjorn Andersson <bjorn.andersson(a)linaro.org> wrote: > > When the Qualcomm ethqos driver is properly described in its associated > GDSC power-domain, the hardware will be powered down and loose its state > between qcom_ethqos_probe() and stmmac_init_dma_engine(). > > The result of this is that the functional clock from the RGMII IO macro > is no longer provides and the DMA software reset in dwmac4_dma_reset() > will time out, due to lacking clock signal. > > Re-enable the functional clock, as part of the Qualcomm specific clock > enablement sequence to avoid this problem. > > The final clock configuration will be adjusted by ethqos_fix_mac_speed() > once the link is being brought up. > > Fixes: a7c30e62d4b8 ("net: stmmac: Add driver for Qualcomm ethqos") > Signed-off-by: Bjorn Andersson <bjorn.andersson(a)linaro.org> > --- > drivers/net/ethernet/stmicro/stmmac/dwmac-qcom-ethqos.c | 7 +++++++ > 1 file changed, 7 insertions(+) > > diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac-qcom-ethqos.c b/drivers/net/ethernet/stmicro/stmmac/dwmac-qcom-ethqos.c > index 0cc28c79cc61..835caa15d55f 100644 > --- a/drivers/net/ethernet/stmicro/stmmac/dwmac-qcom-ethqos.c > +++ b/drivers/net/ethernet/stmicro/stmmac/dwmac-qcom-ethqos.c > @@ -487,6 +487,13 @@ static int ethqos_clks_config(void *priv, bool enabled) > dev_err(&ethqos->pdev->dev, "rgmii_clk enable failed\n"); > return ret; > } > + > + /* Enable functional clock to prevent DMA reset to timeout due > + * to lacking PHY clock after the hardware block has been power > + * cycled. The actual configuration will be adjusted once > + * ethqos_fix_mac_speed() is invoked. > + */ > + ethqos_set_func_clk_en(ethqos); > } else { > clk_disable_unprepare(ethqos->rgmii_clk); > } > -- > 2.33.1 Thanks for the catch, Bjorn. I tested this on the SA8155p-ADP board and the eth interface can be moved from 'on' to 'off' state and vice-versa properly after this change and we no longer need the EMAC GDSC quirk, so: Tested-and-Reviewed-by: Bhupesh Sharma <bhupesh.sharma(a)linaro.org> Regards.

2 years, 9 months

2
1
0 0

[PATCH] drm/amd/display: Program color range and encoding correctly for DCN2+

by Harry Wentland

[Why] DCN2 CNVC programming did not respect the input_color_space and was therefore programming the wrong CSC matrix for YUV to RGB conversion, leading to a wrong image. In particular blacks for limited range videos would show as dark grey. [How] Do what DCN1 does and use the input_color_space info in dpp_setup if it's available. Signed-off-by: Harry Wentland <harry.wentland(a)amd.com> Cc: stable(a)vger.kernel.org Cc: hersenxs.wu(a)amd.com Cc: Ikshwaku.Chauhan(a)amd.com Cc: Nicholas.Kazlauskas(a)amd.com Cc: CHANDAN.VURDIGERENATARAJ(a)amd.com --- drivers/gpu/drm/amd/display/dc/dcn20/dcn20_dpp.c | 3 +++ drivers/gpu/drm/amd/display/dc/dcn201/dcn201_dpp.c | 3 +++ drivers/gpu/drm/amd/display/dc/dcn30/dcn30_dpp.c | 3 +++ 3 files changed, 9 insertions(+) diff --git a/drivers/gpu/drm/amd/display/dc/dcn20/dcn20_dpp.c b/drivers/gpu/drm/amd/display/dc/dcn20/dcn20_dpp.c index 970b65efeac1..eaa7032f0f1a 100644 --- a/drivers/gpu/drm/amd/display/dc/dcn20/dcn20_dpp.c +++ b/drivers/gpu/drm/amd/display/dc/dcn20/dcn20_dpp.c @@ -212,6 +212,9 @@ static void dpp2_cnv_setup ( break; } + /* Set default color space based on format if none is given. */ + color_space = input_color_space ? input_color_space : color_space; + if (is_2bit == 1 && alpha_2bit_lut != NULL) { REG_UPDATE(ALPHA_2BIT_LUT, ALPHA_2BIT_LUT0, alpha_2bit_lut->lut0); REG_UPDATE(ALPHA_2BIT_LUT, ALPHA_2BIT_LUT1, alpha_2bit_lut->lut1); diff --git a/drivers/gpu/drm/amd/display/dc/dcn201/dcn201_dpp.c b/drivers/gpu/drm/amd/display/dc/dcn201/dcn201_dpp.c index 8b6505b7dca8..f50ab961bc17 100644 --- a/drivers/gpu/drm/amd/display/dc/dcn201/dcn201_dpp.c +++ b/drivers/gpu/drm/amd/display/dc/dcn201/dcn201_dpp.c @@ -153,6 +153,9 @@ static void dpp201_cnv_setup( break; } + /* Set default color space based on format if none is given. */ + color_space = input_color_space ? input_color_space : color_space; + if (is_2bit == 1 && alpha_2bit_lut != NULL) { REG_UPDATE(ALPHA_2BIT_LUT, ALPHA_2BIT_LUT0, alpha_2bit_lut->lut0); REG_UPDATE(ALPHA_2BIT_LUT, ALPHA_2BIT_LUT1, alpha_2bit_lut->lut1); diff --git a/drivers/gpu/drm/amd/display/dc/dcn30/dcn30_dpp.c b/drivers/gpu/drm/amd/display/dc/dcn30/dcn30_dpp.c index ab3918c0a15b..0dcc07531643 100644 --- a/drivers/gpu/drm/amd/display/dc/dcn30/dcn30_dpp.c +++ b/drivers/gpu/drm/amd/display/dc/dcn30/dcn30_dpp.c @@ -294,6 +294,9 @@ static void dpp3_cnv_setup ( break; } + /* Set default color space based on format if none is given. */ + color_space = input_color_space ? input_color_space : color_space; + if (is_2bit == 1 && alpha_2bit_lut != NULL) { REG_UPDATE(ALPHA_2BIT_LUT, ALPHA_2BIT_LUT0, alpha_2bit_lut->lut0); REG_UPDATE(ALPHA_2BIT_LUT, ALPHA_2BIT_LUT1, alpha_2bit_lut->lut1); -- 2.35.1

2 years, 9 months

3
2
0 0

[PATCH] drm/edid: fix CEA extension byte #3 parsing

by Jani Nikula

Only an EDID CEA extension has byte #3, while the CTA DisplayID Data Block does not. Don't interpret bogus data for color formats. For most displays it's probably an unlikely scenario you'd have a CTA DisplayID Data Block without a CEA extension, but they do exist. Fixes: e28ad544f462 ("drm/edid: parse CEA blocks embedded in DisplayID") Cc: <stable(a)vger.kernel.org> # v4.15 Cc: Shawn C Lee <shawn.c.lee(a)intel.com> Cc: Ville Syrjälä <ville.syrjala(a)linux.intel.com> Signed-off-by: Jani Nikula <jani.nikula(a)intel.com> --- commit e28ad544f462 was merged in v5.3, but it has Cc: stable for v4.15. This is also fixed in my CEA data block iteration series [1], but we'll want the simple fix for stable first. Hum, CTA is formerly CEA, I and the code seem to use both, should we use only one or the other? [1] https://patchwork.freedesktop.org/series/101659/ --- drivers/gpu/drm/drm_edid.c | 12 ++++++++---- 1 file changed, 8 insertions(+), 4 deletions(-) diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c index 561f53831e29..ccf7031a6797 100644 --- a/drivers/gpu/drm/drm_edid.c +++ b/drivers/gpu/drm/drm_edid.c @@ -5187,10 +5187,14 @@ static void drm_parse_cea_ext(struct drm_connector *connector, /* The existence of a CEA block should imply RGB support */ info->color_formats = DRM_COLOR_FORMAT_RGB444; - if (edid_ext[3] & EDID_CEA_YCRCB444) - info->color_formats |= DRM_COLOR_FORMAT_YCBCR444; - if (edid_ext[3] & EDID_CEA_YCRCB422) - info->color_formats |= DRM_COLOR_FORMAT_YCBCR422; + + /* CTA DisplayID Data Block does not have byte #3 */ + if (edid_ext[0] == CEA_EXT) { + if (edid_ext[3] & EDID_CEA_YCRCB444) + info->color_formats |= DRM_COLOR_FORMAT_YCBCR444; + if (edid_ext[3] & EDID_CEA_YCRCB422) + info->color_formats |= DRM_COLOR_FORMAT_YCBCR422; + } if (cea_db_offsets(edid_ext, &start, &end)) return; -- 2.30.2

2 years, 9 months

2
3
0 0

[v3] drm/edid: check basic audio support on CEA extension block

by Lee Shawn C

From: Cooper Chiou <cooper.chiou(a)intel.com> Tag code stored in bit7:5 for CTA block byte[3] is not the same as CEA extension block definition. Only check CEA block has basic audio support. v3: update commit message. Cc: stable(a)vger.kernel.org Cc: Jani Nikula <jani.nikula(a)intel.com> Cc: Shawn C Lee <shawn.c.lee(a)intel.com> Cc: intel-gfx <intel-gfx(a)lists.freedesktop.org> Signed-off-by: Cooper Chiou <cooper.chiou(a)intel.com> Signed-off-by: Lee Shawn C <shawn.c.lee(a)intel.com> Fixes: e28ad544f462 ("drm/edid: parse CEA blocks embedded in DisplayID") Reviewed-by: Jani Nikula <jani.nikula(a)intel.com> --- drivers/gpu/drm/drm_edid.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c index 561f53831e29..f07af6786cec 100644 --- a/drivers/gpu/drm/drm_edid.c +++ b/drivers/gpu/drm/drm_edid.c @@ -4859,7 +4859,8 @@ bool drm_detect_monitor_audio(struct edid *edid) if (!edid_ext) goto end; - has_audio = ((edid_ext[3] & EDID_BASIC_AUDIO) != 0); + has_audio = (edid_ext[0] == CEA_EXT && + (edid_ext[3] & EDID_BASIC_AUDIO) != 0); if (has_audio) { DRM_DEBUG_KMS("Monitor has basic audio support\n"); -- 2.17.1

2 years, 9 months

2
1
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror March 2022