April 2023 - Linux-stable-mirror

FAILED: patch "[PATCH] nvme-pci: add NVME_QUIRK_BOGUS_NID for T-FORCE Z330 SSD" 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 74391b3e69855e7dd65a9cef36baf5fc1345affd # <resolve conflicts, build, test, etc.> git commit -s git send-email --to '<stable(a)vger.kernel.org>' --in-reply-to '2023041705-dreaded-verify-10da@gregkh' --subject-prefix 'PATCH 5.15.y' HEAD^.. Possible dependencies: 74391b3e6985 ("nvme-pci: add NVME_QUIRK_BOGUS_NID for T-FORCE Z330 SSD") 1231363aec86 ("nvme-pci: mark Lexar NM760 as IGNORE_DEV_SUBNQN") 80b2624094c8 ("nvme-pci: add NVME_QUIRK_BOGUS_NID for Lexar NM760") 200dccd07df2 ("nvme-pci: add NVME_QUIRK_BOGUS_NID for Lexar NM610") d6c52fa3e955 ("nvme-pci: Crucial P2 has bogus namespace ids") 6b961bce50e4 ("nvme-pci: avoid the deepest sleep state on ZHITAI TiPro7000 SSDs") 3765fad50896 ("nvme-pci: add NVME_QUIRK_BOGUS_NID for ADATA XPG GAMMIX S50") a98a945b80f8 ("nvme-pci: disable namespace identifiers for the MAXIO MAP1002/1202") thanks, greg k-h ------------------ original commit in Linus's tree ------------------ From 74391b3e69855e7dd65a9cef36baf5fc1345affd Mon Sep 17 00:00:00 2001 From: Duy Truong <dory(a)dory.moe> Date: Thu, 13 Apr 2023 17:55:48 -0700 Subject: [PATCH] nvme-pci: add NVME_QUIRK_BOGUS_NID for T-FORCE Z330 SSD Added a quirk to fix the TeamGroup T-Force Cardea Zero Z330 SSDs reporting duplicate NGUIDs. Signed-off-by: Duy Truong <dory(a)dory.moe> Cc: stable(a)vger.kernel.org Signed-off-by: Christoph Hellwig <hch(a)lst.de> diff --git a/drivers/nvme/host/pci.c b/drivers/nvme/host/pci.c index 282d808400c5..cd7873de3121 100644 --- a/drivers/nvme/host/pci.c +++ b/drivers/nvme/host/pci.c @@ -3443,6 +3443,8 @@ static const struct pci_device_id nvme_id_table[] = { { PCI_DEVICE(0x1d97, 0x2269), /* Lexar NM760 */ .driver_data = NVME_QUIRK_BOGUS_NID | NVME_QUIRK_IGNORE_DEV_SUBNQN, }, + { PCI_DEVICE(0x10ec, 0x5763), /* TEAMGROUP T-FORCE CARDEA ZERO Z330 SSD */ + .driver_data = NVME_QUIRK_BOGUS_NID, }, { PCI_DEVICE(PCI_VENDOR_ID_AMAZON, 0x0061), .driver_data = NVME_QUIRK_DMA_ADDRESS_BITS_48, }, { PCI_DEVICE(PCI_VENDOR_ID_AMAZON, 0x0065),

1 year, 6 months

2
1
0 0

FAILED: patch "[PATCH] nvme-pci: add NVME_QUIRK_BOGUS_NID for T-FORCE Z330 SSD" failed to apply to 6.1-stable tree

by gregkh＠linuxfoundation.org

The patch below does not apply to the 6.1-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.1.y git checkout FETCH_HEAD git cherry-pick -x 74391b3e69855e7dd65a9cef36baf5fc1345affd # <resolve conflicts, build, test, etc.> git commit -s git send-email --to '<stable(a)vger.kernel.org>' --in-reply-to '2023041704-perch-bullion-073e@gregkh' --subject-prefix 'PATCH 6.1.y' HEAD^.. Possible dependencies: 74391b3e6985 ("nvme-pci: add NVME_QUIRK_BOGUS_NID for T-FORCE Z330 SSD") 1231363aec86 ("nvme-pci: mark Lexar NM760 as IGNORE_DEV_SUBNQN") thanks, greg k-h ------------------ original commit in Linus's tree ------------------ From 74391b3e69855e7dd65a9cef36baf5fc1345affd Mon Sep 17 00:00:00 2001 From: Duy Truong <dory(a)dory.moe> Date: Thu, 13 Apr 2023 17:55:48 -0700 Subject: [PATCH] nvme-pci: add NVME_QUIRK_BOGUS_NID for T-FORCE Z330 SSD Added a quirk to fix the TeamGroup T-Force Cardea Zero Z330 SSDs reporting duplicate NGUIDs. Signed-off-by: Duy Truong <dory(a)dory.moe> Cc: stable(a)vger.kernel.org Signed-off-by: Christoph Hellwig <hch(a)lst.de> diff --git a/drivers/nvme/host/pci.c b/drivers/nvme/host/pci.c index 282d808400c5..cd7873de3121 100644 --- a/drivers/nvme/host/pci.c +++ b/drivers/nvme/host/pci.c @@ -3443,6 +3443,8 @@ static const struct pci_device_id nvme_id_table[] = { { PCI_DEVICE(0x1d97, 0x2269), /* Lexar NM760 */ .driver_data = NVME_QUIRK_BOGUS_NID | NVME_QUIRK_IGNORE_DEV_SUBNQN, }, + { PCI_DEVICE(0x10ec, 0x5763), /* TEAMGROUP T-FORCE CARDEA ZERO Z330 SSD */ + .driver_data = NVME_QUIRK_BOGUS_NID, }, { PCI_DEVICE(PCI_VENDOR_ID_AMAZON, 0x0061), .driver_data = NVME_QUIRK_DMA_ADDRESS_BITS_48, }, { PCI_DEVICE(PCI_VENDOR_ID_AMAZON, 0x0065),

1 year, 6 months

2
1
0 0

[PATCH] bluetooth: Perform careful capability checks in hci_sock_ioctl()

by Ruihan Li

Previously, capability was checked using capable(), which verified that the caller of the ioctl system call had the required capability. In addition, the result of the check would be stored in the HCI_SOCK_TRUSTED flag, making it persistent for the socket. However, malicious programs can abuse this approach by deliberately sharing an HCI socket with a privileged task. The HCI socket will be marked as trusted when the privileged task occasionally makes an ioctl call. This problem can be solved by using sk_capable() to check capability, which ensures that not only the current task but also the socket opener has the specified capability, thus reducing the risk of privilege escalation through the previously identified vulnerability. Cc: stable(a)vger.kernel.org Fixes: f81f5b2db869 ("Bluetooth: Send control open and close messages for HCI raw sockets") Signed-off-by: Ruihan Li <lrh2000(a)pku.edu.cn> --- net/bluetooth/hci_sock.c | 9 ++++++++- 1 file changed, 8 insertions(+), 1 deletion(-) diff --git a/net/bluetooth/hci_sock.c b/net/bluetooth/hci_sock.c index 065812232..f597fe0db 100644 --- a/net/bluetooth/hci_sock.c +++ b/net/bluetooth/hci_sock.c @@ -1003,7 +1003,14 @@ static int hci_sock_ioctl(struct socket *sock, unsigned int cmd, if (hci_sock_gen_cookie(sk)) { struct sk_buff *skb; - if (capable(CAP_NET_ADMIN)) + /* Perform careful checks before setting the HCI_SOCK_TRUSTED + * flag. Make sure that not only the current task but also + * the socket opener has the required capability, since + * privileged programs can be tricked into making ioctl calls + * on HCI sockets, and the socket should not be marked as + * trusted simply because the ioctl caller is privileged. + */ + if (sk_capable(sk, CAP_NET_ADMIN)) hci_sock_set_flag(sk, HCI_SOCK_TRUSTED); /* Send event to monitor */ -- 2.40.0

1 year, 6 months

2
1
0 0

FAILED: patch "[PATCH] nvme-pci: add NVME_QUIRK_BOGUS_NID for T-FORCE Z330 SSD" failed to apply to 6.2-stable tree

by gregkh＠linuxfoundation.org

The patch below does not apply to the 6.2-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.2.y git checkout FETCH_HEAD git cherry-pick -x 74391b3e69855e7dd65a9cef36baf5fc1345affd # <resolve conflicts, build, test, etc.> git commit -s git send-email --to '<stable(a)vger.kernel.org>' --in-reply-to '2023041703-motive-shrill-a19e@gregkh' --subject-prefix 'PATCH 6.2.y' HEAD^.. Possible dependencies: 74391b3e6985 ("nvme-pci: add NVME_QUIRK_BOGUS_NID for T-FORCE Z330 SSD") 1231363aec86 ("nvme-pci: mark Lexar NM760 as IGNORE_DEV_SUBNQN") thanks, greg k-h ------------------ original commit in Linus's tree ------------------ From 74391b3e69855e7dd65a9cef36baf5fc1345affd Mon Sep 17 00:00:00 2001 From: Duy Truong <dory(a)dory.moe> Date: Thu, 13 Apr 2023 17:55:48 -0700 Subject: [PATCH] nvme-pci: add NVME_QUIRK_BOGUS_NID for T-FORCE Z330 SSD Added a quirk to fix the TeamGroup T-Force Cardea Zero Z330 SSDs reporting duplicate NGUIDs. Signed-off-by: Duy Truong <dory(a)dory.moe> Cc: stable(a)vger.kernel.org Signed-off-by: Christoph Hellwig <hch(a)lst.de> diff --git a/drivers/nvme/host/pci.c b/drivers/nvme/host/pci.c index 282d808400c5..cd7873de3121 100644 --- a/drivers/nvme/host/pci.c +++ b/drivers/nvme/host/pci.c @@ -3443,6 +3443,8 @@ static const struct pci_device_id nvme_id_table[] = { { PCI_DEVICE(0x1d97, 0x2269), /* Lexar NM760 */ .driver_data = NVME_QUIRK_BOGUS_NID | NVME_QUIRK_IGNORE_DEV_SUBNQN, }, + { PCI_DEVICE(0x10ec, 0x5763), /* TEAMGROUP T-FORCE CARDEA ZERO Z330 SSD */ + .driver_data = NVME_QUIRK_BOGUS_NID, }, { PCI_DEVICE(PCI_VENDOR_ID_AMAZON, 0x0061), .driver_data = NVME_QUIRK_DMA_ADDRESS_BITS_48, }, { PCI_DEVICE(PCI_VENDOR_ID_AMAZON, 0x0065),

1 year, 6 months

2
1
0 0

[PATCH 4.14] cgroup/cpuset: Wake up cpuset_attach_wq tasks in cpuset_cancel_attach()

by Waiman Long

commit ba9182a89626d5f83c2ee4594f55cb9c1e60f0e2 upstream. After a successful cpuset_can_attach() call which increments the attach_in_progress flag, either cpuset_cancel_attach() or cpuset_attach() will be called later. In cpuset_attach(), tasks in cpuset_attach_wq, if present, will be woken up at the end. That is not the case in cpuset_cancel_attach(). So missed wakeup is possible if the attach operation is somehow cancelled. Fix that by doing the wakeup in cpuset_cancel_attach() as well. Fixes: e44193d39e8d ("cpuset: let hotplug propagation work wait for task attaching") Signed-off-by: Waiman Long <longman(a)redhat.com> Reviewed-by: Michal Koutný <mkoutny(a)suse.com> Cc: stable(a)vger.kernel.org # v3.11+ Signed-off-by: Tejun Heo <tj(a)kernel.org> --- kernel/cgroup/cpuset.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/kernel/cgroup/cpuset.c b/kernel/cgroup/cpuset.c index 0b82e3857d33..20c1ccc6a0bb 100644 --- a/kernel/cgroup/cpuset.c +++ b/kernel/cgroup/cpuset.c @@ -1508,7 +1508,9 @@ static void cpuset_cancel_attach(struct cgroup_taskset *tset) cs = css_cs(css); mutex_lock(&cpuset_mutex); - css_cs(css)->attach_in_progress--; + cs->attach_in_progress--; + if (!cs->attach_in_progress) + wake_up(&cpuset_attach_wq); mutex_unlock(&cpuset_mutex); } -- 2.31.1

1 year, 6 months

1
0
0 0

[PATCH 4.19] cgroup/cpuset: Wake up cpuset_attach_wq tasks in cpuset_cancel_attach()

by Waiman Long

commit ba9182a89626d5f83c2ee4594f55cb9c1e60f0e2 upstream. After a successful cpuset_can_attach() call which increments the attach_in_progress flag, either cpuset_cancel_attach() or cpuset_attach() will be called later. In cpuset_attach(), tasks in cpuset_attach_wq, if present, will be woken up at the end. That is not the case in cpuset_cancel_attach(). So missed wakeup is possible if the attach operation is somehow cancelled. Fix that by doing the wakeup in cpuset_cancel_attach() as well. Fixes: e44193d39e8d ("cpuset: let hotplug propagation work wait for task attaching") Signed-off-by: Waiman Long <longman(a)redhat.com> Reviewed-by: Michal Koutný <mkoutny(a)suse.com> Cc: stable(a)vger.kernel.org # v3.11+ Signed-off-by: Tejun Heo <tj(a)kernel.org> --- kernel/cgroup/cpuset.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/kernel/cgroup/cpuset.c b/kernel/cgroup/cpuset.c index c6d412cebc43..3067d3e5a51d 100644 --- a/kernel/cgroup/cpuset.c +++ b/kernel/cgroup/cpuset.c @@ -1504,7 +1504,9 @@ static void cpuset_cancel_attach(struct cgroup_taskset *tset) cs = css_cs(css); mutex_lock(&cpuset_mutex); - css_cs(css)->attach_in_progress--; + cs->attach_in_progress--; + if (!cs->attach_in_progress) + wake_up(&cpuset_attach_wq); mutex_unlock(&cpuset_mutex); } -- 2.31.1

1 year, 6 months

1
0
0 0

Request to pick "ubi: Fix failure attaching when vid_hdr offset equals to (sub)page size"

by Daniel Golle

Hi, please pick 1e020e1b96afd ("ubi: Fix failure attaching when vid_hdr offset equals to (sub)page size") from linux-next to stable trees. The commit fixes a problem with another recent commit 1b42b1a36fc94 ("ubi: ensure that VID header offset ... size") which has already made it to stable trees and thereby broke attaching UBI and hence renders devices unbootable. As a temporary fix I have applied this patch downstream in OpenWrt. Thank you! Best regards Daniel ----- Forwarded message from Daniel Golle <daniel(a)makrotopia.org> ----- Date: Sat, 15 Apr 2023 00:12:46 +0100 From: Daniel Golle <daniel(a)makrotopia.org> To: Richard Weinberger <richard(a)nod.at> Cc: Miquel Raynal <miquel.raynal(a)bootlin.com>, chengzhihao1 <chengzhihao1(a)huawei.com>, Nicolas Schichan <nschichan(a)freebox.fr>, George Kennedy <george.kennedy(a)oracle.com>, linux-kernel <linux-kernel(a)vger.kernel.org>, linux-mtd <linux-mtd(a)lists.infradead.org>, Sascha Hauer <s.hauer(a)pengutronix.de>, yi zhang <yi.zhang(a)huawei.com> Subject: Re: [PATCH -next v3] ubi: Fix failure attaching when vid_hdr offset equals to (sub)page size Hi Richard, On Wed, Mar 29, 2023 at 11:33:40PM +0200, Richard Weinberger wrote: > ----- Ursprüngliche Mail ----- > > Von: "Miquel Raynal" <miquel.raynal(a)bootlin.com> > >> Thanks for testing. > >> > >> > Tested-by: Nicolas Schichan <nschichan(a)freebox.fr> > > > > Same here. > > > > Tested-by: Miquel Raynal <miquel.raynal(a)bootlin.com> # v5.10, v4.19 > > Applied to next, PR will follow soon. As stable linux trees are affected I wonder when this will hit linux-stable, ie. will it be part of 5.15.108, for example? Cheers Daniel ----- End forwarded message -----

1 year, 6 months

3
5
0 0

[PATCH] drm/amd/display: fix flickering caused by S/G mode

by Hamza Mahfooz

Currently, we allow the framebuffer for a given plane to move between memory domains, however when that happens it causes the screen to flicker, it is even possible for the framebuffer to change memory domains on every plane update (causing a continuous flicker effect). So, to fix this, don't perform an immediate flip in the aforementioned case. Cc: stable(a)vger.kernel.org Fixes: 81d0bcf99009 ("drm/amdgpu: make display pinning more flexible (v2)") Signed-off-by: Hamza Mahfooz <hamza.mahfooz(a)amd.com> --- .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 41 ++++++++++++++++++- 1 file changed, 39 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c index da3045fdcb6d..9a4e7408384a 100644 --- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c +++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c @@ -7897,6 +7897,34 @@ static void amdgpu_dm_commit_cursors(struct drm_atomic_state *state) amdgpu_dm_plane_handle_cursor_update(plane, old_plane_state); } +static inline uint32_t get_mem_type(struct amdgpu_device *adev, + struct drm_gem_object *obj, + bool check_domain) +{ + struct amdgpu_bo *abo = gem_to_amdgpu_bo(obj); + uint32_t mem_type; + + if (unlikely(amdgpu_bo_reserve(abo, true))) + return 0; + + if (unlikely(dma_resv_reserve_fences(abo->tbo.base.resv, 1))) + goto err; + + if (check_domain && + amdgpu_display_supported_domains(adev, abo->flags) != + (AMDGPU_GEM_DOMAIN_VRAM | AMDGPU_GEM_DOMAIN_GTT)) + goto err; + + mem_type = abo->tbo.resource->mem_type; + amdgpu_bo_unreserve(abo); + + return mem_type; + +err: + amdgpu_bo_unreserve(abo); + return 0; +} + static void amdgpu_dm_commit_planes(struct drm_atomic_state *state, struct dc_state *dc_state, struct drm_device *dev, @@ -7916,6 +7944,7 @@ static void amdgpu_dm_commit_planes(struct drm_atomic_state *state, to_dm_crtc_state(drm_atomic_get_old_crtc_state(state, pcrtc)); int planes_count = 0, vpos, hpos; unsigned long flags; + uint32_t mem_type; u32 target_vblank, last_flip_vblank; bool vrr_active = amdgpu_dm_crtc_vrr_active(acrtc_state); bool cursor_update = false; @@ -8035,13 +8064,21 @@ static void amdgpu_dm_commit_planes(struct drm_atomic_state *state, } } + mem_type = get_mem_type(dm->adev, old_plane_state->fb->obj[0], + true); + /* * Only allow immediate flips for fast updates that don't - * change FB pitch, DCC state, rotation or mirroing. + * change memory domain, FB pitch, DCC state, rotation or + * mirroring. */ bundle->flip_addrs[planes_count].flip_immediate = crtc->state->async_flip && - acrtc_state->update_type == UPDATE_TYPE_FAST; + acrtc_state->update_type == UPDATE_TYPE_FAST && + (!mem_type || (mem_type && get_mem_type(dm->adev, + fb->obj[0], + false) == + mem_type)); timestamp_ns = ktime_get_ns(); bundle->flip_addrs[planes_count].flip_timestamp_in_us = div_u64(timestamp_ns, 1000); -- 2.40.0

1 year, 6 months

4
8
0 0

FAILED: patch "[PATCH] cgroup/cpuset: Add cpuset_can_fork() and cpuset_cancel_fork()" 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>. 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.10.y git checkout FETCH_HEAD git cherry-pick -x eee87853794187f6adbe19533ed79c8b44b36a91 # <resolve conflicts, build, test, etc.> git commit -s git send-email --to '<stable(a)vger.kernel.org>' --in-reply-to '2023041705-gauze-elated-d7c7@gregkh' --subject-prefix 'PATCH 5.10.y' HEAD^.. Possible dependencies: eee878537941 ("cgroup/cpuset: Add cpuset_can_fork() and cpuset_cancel_fork() methods") 42a11bf5c543 ("cgroup/cpuset: Make cpuset_fork() handle CLONE_INTO_CGROUP properly") 18f9a4d47527 ("cgroup/cpuset: Skip spread flags update on v2") e2d59900d936 ("cgroup/cpuset: Allow no-task partition to have empty cpuset.cpus.effective") 18065ebe9b33 ("cgroup/cpuset: Miscellaneous cleanups & add helper functions") f9da322e864e ("cgroup: cleanup comments") 8ca1b5a49885 ("mm/page_alloc: detect allocation forbidden by cpuset and bail out early") b94f9ac79a73 ("cgroup/cpuset: Change references of cpuset_mutex to cpuset_rwsem") 69dc8010b8fc ("Merge branch 'for-5.15' of git://git.kernel.org/pub/scm/linux/kernel/git/tj/cgroup") thanks, greg k-h ------------------ original commit in Linus's tree ------------------ From eee87853794187f6adbe19533ed79c8b44b36a91 Mon Sep 17 00:00:00 2001 From: Waiman Long <longman(a)redhat.com> Date: Tue, 11 Apr 2023 09:35:59 -0400 Subject: [PATCH] cgroup/cpuset: Add cpuset_can_fork() and cpuset_cancel_fork() methods MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit In the case of CLONE_INTO_CGROUP, not all cpusets are ready to accept new tasks. It is too late to check that in cpuset_fork(). So we need to add the cpuset_can_fork() and cpuset_cancel_fork() methods to pre-check it before we can allow attachment to a different cpuset. We also need to set the attach_in_progress flag to alert other code that a new task is going to be added to the cpuset. Fixes: ef2c41cf38a7 ("clone3: allow spawning processes into cgroups") Suggested-by: Michal Koutný <mkoutny(a)suse.com> Signed-off-by: Waiman Long <longman(a)redhat.com> Cc: stable(a)vger.kernel.org # v5.7+ Signed-off-by: Tejun Heo <tj(a)kernel.org> diff --git a/kernel/cgroup/cpuset.c b/kernel/cgroup/cpuset.c index 2ccfae74acf9..166a45019f66 100644 --- a/kernel/cgroup/cpuset.c +++ b/kernel/cgroup/cpuset.c @@ -2453,6 +2453,20 @@ static int fmeter_getrate(struct fmeter *fmp) static struct cpuset *cpuset_attach_old_cs; +/* + * Check to see if a cpuset can accept a new task + * For v1, cpus_allowed and mems_allowed can't be empty. + * For v2, effective_cpus can't be empty. + * Note that in v1, effective_cpus = cpus_allowed. + */ +static int cpuset_can_attach_check(struct cpuset *cs) +{ + if (cpumask_empty(cs->effective_cpus) || + (!is_in_v2_mode() && nodes_empty(cs->mems_allowed))) + return -ENOSPC; + return 0; +} + /* Called by cgroups to determine if a cpuset is usable; cpuset_rwsem held */ static int cpuset_can_attach(struct cgroup_taskset *tset) { @@ -2467,16 +2481,9 @@ static int cpuset_can_attach(struct cgroup_taskset *tset) percpu_down_write(&cpuset_rwsem); - /* allow moving tasks into an empty cpuset if on default hierarchy */ - ret = -ENOSPC; - if (!is_in_v2_mode() && - (cpumask_empty(cs->cpus_allowed) || nodes_empty(cs->mems_allowed))) - goto out_unlock; - - /* - * Task cannot be moved to a cpuset with empty effective cpus. - */ - if (cpumask_empty(cs->effective_cpus)) + /* Check to see if task is allowed in the cpuset */ + ret = cpuset_can_attach_check(cs); + if (ret) goto out_unlock; cgroup_taskset_for_each(task, css, tset) { @@ -2493,7 +2500,6 @@ static int cpuset_can_attach(struct cgroup_taskset *tset) * changes which zero cpus/mems_allowed. */ cs->attach_in_progress++; - ret = 0; out_unlock: percpu_up_write(&cpuset_rwsem); return ret; @@ -3264,6 +3270,68 @@ static void cpuset_bind(struct cgroup_subsys_state *root_css) percpu_up_write(&cpuset_rwsem); } +/* + * In case the child is cloned into a cpuset different from its parent, + * additional checks are done to see if the move is allowed. + */ +static int cpuset_can_fork(struct task_struct *task, struct css_set *cset) +{ + struct cpuset *cs = css_cs(cset->subsys[cpuset_cgrp_id]); + bool same_cs; + int ret; + + rcu_read_lock(); + same_cs = (cs == task_cs(current)); + rcu_read_unlock(); + + if (same_cs) + return 0; + + lockdep_assert_held(&cgroup_mutex); + percpu_down_write(&cpuset_rwsem); + + /* Check to see if task is allowed in the cpuset */ + ret = cpuset_can_attach_check(cs); + if (ret) + goto out_unlock; + + ret = task_can_attach(task, cs->effective_cpus); + if (ret) + goto out_unlock; + + ret = security_task_setscheduler(task); + if (ret) + goto out_unlock; + + /* + * Mark attach is in progress. This makes validate_change() fail + * changes which zero cpus/mems_allowed. + */ + cs->attach_in_progress++; +out_unlock: + percpu_up_write(&cpuset_rwsem); + return ret; +} + +static void cpuset_cancel_fork(struct task_struct *task, struct css_set *cset) +{ + struct cpuset *cs = css_cs(cset->subsys[cpuset_cgrp_id]); + bool same_cs; + + rcu_read_lock(); + same_cs = (cs == task_cs(current)); + rcu_read_unlock(); + + if (same_cs) + return; + + percpu_down_write(&cpuset_rwsem); + cs->attach_in_progress--; + if (!cs->attach_in_progress) + wake_up(&cpuset_attach_wq); + percpu_up_write(&cpuset_rwsem); +} + /* * Make sure the new task conform to the current state of its parent, * which could have been changed by cpuset just after it inherits the @@ -3292,6 +3360,11 @@ static void cpuset_fork(struct task_struct *task) percpu_down_write(&cpuset_rwsem); guarantee_online_mems(cs, &cpuset_attach_nodemask_to); cpuset_attach_task(cs, task); + + cs->attach_in_progress--; + if (!cs->attach_in_progress) + wake_up(&cpuset_attach_wq); + percpu_up_write(&cpuset_rwsem); } @@ -3305,6 +3378,8 @@ struct cgroup_subsys cpuset_cgrp_subsys = { .attach = cpuset_attach, .post_attach = cpuset_post_attach, .bind = cpuset_bind, + .can_fork = cpuset_can_fork, + .cancel_fork = cpuset_cancel_fork, .fork = cpuset_fork, .legacy_cftypes = legacy_files, .dfl_cftypes = dfl_files,

1 year, 6 months

2
1
0 0

[Regression] Cannot overwrite VID header offset any more [Was: [PATCH] ubi: ensure that VID header offset + VID header size <= alloc, size]

by Uwe Kleine-König

Hello, On Tue, Nov 15, 2022 at 10:14:44AM -0500, George Kennedy wrote: > Ensure that the VID header offset + VID header size does not exceed > the allocated area to avoid slab OOB. > > BUG: KASAN: slab-out-of-bounds in crc32_body lib/crc32.c:111 [inline] > BUG: KASAN: slab-out-of-bounds in crc32_le_generic lib/crc32.c:179 [inline] > BUG: KASAN: slab-out-of-bounds in crc32_le_base+0x58c/0x626 lib/crc32.c:197 > Read of size 4 at addr ffff88802bb36f00 by task syz-executor136/1555 > > CPU: 2 PID: 1555 Comm: syz-executor136 Tainted: G W > 6.0.0-1868 #1 > Hardware name: Red Hat KVM, BIOS 1.13.0-2.module+el8.3.0+7860+a7792d29 > 04/01/2014 > Call Trace: > <TASK> > __dump_stack lib/dump_stack.c:88 [inline] > dump_stack_lvl+0x85/0xad lib/dump_stack.c:106 > print_address_description mm/kasan/report.c:317 [inline] > print_report.cold.13+0xb6/0x6bb mm/kasan/report.c:433 > kasan_report+0xa7/0x11b mm/kasan/report.c:495 > crc32_body lib/crc32.c:111 [inline] > crc32_le_generic lib/crc32.c:179 [inline] > crc32_le_base+0x58c/0x626 lib/crc32.c:197 > ubi_io_write_vid_hdr+0x1b7/0x472 drivers/mtd/ubi/io.c:1067 > create_vtbl+0x4d5/0x9c4 drivers/mtd/ubi/vtbl.c:317 > create_empty_lvol drivers/mtd/ubi/vtbl.c:500 [inline] > ubi_read_volume_table+0x67b/0x288a drivers/mtd/ubi/vtbl.c:812 > ubi_attach+0xf34/0x1603 drivers/mtd/ubi/attach.c:1601 > ubi_attach_mtd_dev+0x6f3/0x185e drivers/mtd/ubi/build.c:965 > ctrl_cdev_ioctl+0x2db/0x347 drivers/mtd/ubi/cdev.c:1043 > vfs_ioctl fs/ioctl.c:51 [inline] > __do_sys_ioctl fs/ioctl.c:870 [inline] > __se_sys_ioctl fs/ioctl.c:856 [inline] > __x64_sys_ioctl+0x193/0x213 fs/ioctl.c:856 > do_syscall_x64 arch/x86/entry/common.c:50 [inline] > do_syscall_64+0x3e/0x86 arch/x86/entry/common.c:80 > entry_SYSCALL_64_after_hwframe+0x63/0x0 > RIP: 0033:0x7f96d5cf753d > Code: > RSP: 002b:00007fffd72206f8 EFLAGS: 00000246 ORIG_RAX: 0000000000000010 > RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007f96d5cf753d > RDX: 0000000020000080 RSI: 0000000040186f40 RDI: 0000000000000003 > RBP: 0000000000400cd0 R08: 0000000000000000 R09: 0000000000000000 > R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000400be0 > R13: 00007fffd72207e0 R14: 0000000000000000 R15: 0000000000000000 > </TASK> > > Allocated by task 1555: > kasan_save_stack+0x20/0x3d mm/kasan/common.c:38 > kasan_set_track mm/kasan/common.c:45 [inline] > set_alloc_info mm/kasan/common.c:437 [inline] > ____kasan_kmalloc mm/kasan/common.c:516 [inline] > __kasan_kmalloc+0x88/0xa3 mm/kasan/common.c:525 > kasan_kmalloc include/linux/kasan.h:234 [inline] > __kmalloc+0x138/0x257 mm/slub.c:4429 > kmalloc include/linux/slab.h:605 [inline] > ubi_alloc_vid_buf drivers/mtd/ubi/ubi.h:1093 [inline] > create_vtbl+0xcc/0x9c4 drivers/mtd/ubi/vtbl.c:295 > create_empty_lvol drivers/mtd/ubi/vtbl.c:500 [inline] > ubi_read_volume_table+0x67b/0x288a drivers/mtd/ubi/vtbl.c:812 > ubi_attach+0xf34/0x1603 drivers/mtd/ubi/attach.c:1601 > ubi_attach_mtd_dev+0x6f3/0x185e drivers/mtd/ubi/build.c:965 > ctrl_cdev_ioctl+0x2db/0x347 drivers/mtd/ubi/cdev.c:1043 > vfs_ioctl fs/ioctl.c:51 [inline] > __do_sys_ioctl fs/ioctl.c:870 [inline] > __se_sys_ioctl fs/ioctl.c:856 [inline] > __x64_sys_ioctl+0x193/0x213 fs/ioctl.c:856 > do_syscall_x64 arch/x86/entry/common.c:50 [inline] > do_syscall_64+0x3e/0x86 arch/x86/entry/common.c:80 > entry_SYSCALL_64_after_hwframe+0x63/0x0 > > The buggy address belongs to the object at ffff88802bb36e00 > which belongs to the cache kmalloc-256 of size 256 > The buggy address is located 0 bytes to the right of > 256-byte region [ffff88802bb36e00, ffff88802bb36f00) > > The buggy address belongs to the physical page: > page:00000000ea4d1263 refcount:1 mapcount:0 mapping:0000000000000000 > index:0x0 pfn:0x2bb36 > head:00000000ea4d1263 order:1 compound_mapcount:0 compound_pincount:0 > flags: 0xfffffc0010200(slab|head|node=0|zone=1|lastcpupid=0x1fffff) > raw: 000fffffc0010200 ffffea000066c300 dead000000000003 ffff888100042b40 > raw: 0000000000000000 0000000000100010 00000001ffffffff 0000000000000000 > page dumped because: kasan: bad access detected > > Memory state around the buggy address: > ffff88802bb36e00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > ffff88802bb36e80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > > ffff88802bb36f00: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc > ^ > ffff88802bb36f80: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc > ffff88802bb37000: fa fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb > ================================================================== > > Fixes: 801c135ce73d ("UBI: Unsorted Block Images") > Reported-by: syzkaller <syzkaller(a)googlegroups.com> > Signed-off-by: George Kennedy <george.kennedy(a)oracle.com> > --- > drivers/mtd/ubi/build.c | 6 ++++++ > 1 file changed, 6 insertions(+) > > diff --git a/drivers/mtd/ubi/build.c b/drivers/mtd/ubi/build.c > index a32050fecabf..53aa4de6b963 100644 > --- a/drivers/mtd/ubi/build.c > +++ b/drivers/mtd/ubi/build.c > @@ -663,6 +663,12 @@ static int io_init(struct ubi_device *ubi, int max_beb_per1024) > ubi->ec_hdr_alsize = ALIGN(UBI_EC_HDR_SIZE, ubi->hdrs_min_io_size); > ubi->vid_hdr_alsize = ALIGN(UBI_VID_HDR_SIZE, ubi->hdrs_min_io_size); > + if (ubi->vid_hdr_offset && ((ubi->vid_hdr_offset + UBI_VID_HDR_SIZE) > > + ubi->vid_hdr_alsize)) { > + ubi_err(ubi, "VID header offset %d too large.", ubi->vid_hdr_offset); > + return -EINVAL; > + } > + This patch is in mainline as 1b42b1a36fc946f0d7088425b90d491b4257ca3e, and backported to various stable releases. For me this breaks ubiattach -m 0 -O 2048 I think the check ubi->vid_hdr_offset + UBI_VID_HDR_SIZE > ubi->vid_hdr_alsize is wrong. Without -O passed to ubiattach (and dynamic debug enabled) I get: [ 5294.936762] UBI DBG gen (pid 9619): sizeof(struct ubi_ainf_peb) 56 [ 5294.936769] UBI DBG gen (pid 9619): sizeof(struct ubi_wl_entry) 32 [ 5294.936774] UBI DBG gen (pid 9619): min_io_size 2048 [ 5294.936779] UBI DBG gen (pid 9619): max_write_size 2048 [ 5294.936783] UBI DBG gen (pid 9619): hdrs_min_io_size 512 [ 5294.936787] UBI DBG gen (pid 9619): ec_hdr_alsize 512 [ 5294.936791] UBI DBG gen (pid 9619): vid_hdr_alsize 512 [ 5294.936796] UBI DBG gen (pid 9619): vid_hdr_offset 512 [ 5294.936800] UBI DBG gen (pid 9619): vid_hdr_aloffset 512 [ 5294.936804] UBI DBG gen (pid 9619): vid_hdr_shift 0 [ 5294.936808] UBI DBG gen (pid 9619): leb_start 2048 [ 5294.936812] UBI DBG gen (pid 9619): max_erroneous 409 So the check would only pass for vid_hdr_offset <= 512 - UBI_VID_HDR_SIZE; note that even specifying the default value 512 (i.e. ubiattach -m 0 -O 512 ) fails the check. A less strong check would be: diff --git a/drivers/mtd/ubi/build.c b/drivers/mtd/ubi/build.c index 0904eb40c95f..69c28a862430 100644 --- a/drivers/mtd/ubi/build.c +++ b/drivers/mtd/ubi/build.c @@ -666,8 +666,8 @@ static int io_init(struct ubi_device *ubi, int max_beb_per1024) ubi->ec_hdr_alsize = ALIGN(UBI_EC_HDR_SIZE, ubi->hdrs_min_io_size); ubi->vid_hdr_alsize = ALIGN(UBI_VID_HDR_SIZE, ubi->hdrs_min_io_size); - if (ubi->vid_hdr_offset && ((ubi->vid_hdr_offset + UBI_VID_HDR_SIZE) > - ubi->vid_hdr_alsize)) { + if (ubi->vid_hdr_offset && + ubi->vid_hdr_offset + UBI_VID_HDR_SIZE > ubi->peb_size) { ubi_err(ubi, "VID header offset %d too large.", ubi->vid_hdr_offset); return -EINVAL; } But I'm unsure if this would be too lax?! Best regards Uwe -- Pengutronix e.K. | Uwe Kleine-König | Industrial Linux Solutions | https://www.pengutronix.de/ |

1 year, 6 months

2
2
0 0

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror April 2023