July 2022 - Linux-stable-mirror

[PATCH v5] ufs: core: correct ufshcd_shutdown flow

by peter.wang＠mediatek.com

From: Peter Wang <peter.wang(a)mediatek.com> After ufshcd_wl_shutdown set device power off and link off, ufshcd_shutdown could turn off clock/power. Also remove pm_runtime_get_sync. The reason why here can remove pm_runtime_get_sync is because, (1) ufshcd_wl_shutdown -> pm_runtime_get_sync, will resume hba->dev too. (2) device resume(turn on clk/power) is not required, even if device is in RPM_SUSPENDED. Fixes: b294ff3e3449 ("scsi: ufs: core: Enable power management for wlun") Cc: <stable(a)vger.kernel.org> # 5.15.x Signed-off-by: Peter Wang <peter.wang(a)mediatek.com> --- drivers/ufs/core/ufshcd.c | 6 +----- 1 file changed, 1 insertion(+), 5 deletions(-) diff --git a/drivers/ufs/core/ufshcd.c b/drivers/ufs/core/ufshcd.c index c7b337480e3e..d13c76983555 100644 --- a/drivers/ufs/core/ufshcd.c +++ b/drivers/ufs/core/ufshcd.c @@ -9462,12 +9462,8 @@ EXPORT_SYMBOL(ufshcd_runtime_resume); int ufshcd_shutdown(struct ufs_hba *hba) { if (ufshcd_is_ufs_dev_poweroff(hba) && ufshcd_is_link_off(hba)) - goto out; - - pm_runtime_get_sync(hba->dev); + ufshcd_suspend(hba); - ufshcd_suspend(hba); -out: hba->is_powered = false; /* allow force shutdown even in case of errors */ return 0; -- 2.18.0

1 year, 8 months

3
2
0 0

[PATCH v2] Bluetooth: Always set event mask on suspend

by Abhishek Pandit-Subedi

From: Abhishek Pandit-Subedi <abhishekpandit(a)chromium.org> When suspending, always set the event mask once disconnects are successful. Otherwise, if wakeup is disallowed, the event mask is not set before suspend continues and can result in an early wakeup. Fixes: 182ee45da083 ("Bluetooth: hci_sync: Rework hci_suspend_notifier") Cc: stable(a)vger.kernel.org Signed-off-by: Abhishek Pandit-Subedi <abhishekpandit(a)chromium.org> --- Observed on ChromeOS as follows: < HCI Command: Disconnect (0x01|0x0006) plen 3 Handle: 256 Reason: Remote Device Terminated due to Power Off (0x15) > HCI Event: Command Status (0x0f) plen 4 Disconnect (0x01|0x0006) ncmd 1 Status: Success (0x00) @ MGMT Event: Device Disconnected (0x000c) plen 8 BR/EDR Address: 04:52:C7:C3:65:B5 (Bose Corporation) Reason: Connection terminated by local host for suspend (0x05) @ MGMT Event: Controller Suspended (0x002d) plen 1 Suspend state: Disconnected and not scanning (1) > HCI Event: Disconnect Complete (0x05) plen 4 Status: Success (0x00) Handle: 256 Reason: Connection Terminated By Local Host (0x16) The expectation is that we should see Set Event Mask before completing the suspend so that the `Disconnect Complete` doesn't wake us up. Changes in v2: - Added fixes tag and cc stable net/bluetooth/hci_sync.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/net/bluetooth/hci_sync.c b/net/bluetooth/hci_sync.c index 148ce629a59f..e6d804b82b67 100644 --- a/net/bluetooth/hci_sync.c +++ b/net/bluetooth/hci_sync.c @@ -5297,6 +5297,9 @@ int hci_suspend_sync(struct hci_dev *hdev) return err; } + /* Update event mask so only the allowed event can wakeup the host */ + hci_set_event_mask_sync(hdev); + /* Only configure accept list if disconnect succeeded and wake * isn't being prevented. */ @@ -5308,9 +5311,6 @@ int hci_suspend_sync(struct hci_dev *hdev) /* Unpause to take care of updating scanning params */ hdev->scanning_paused = false; - /* Update event mask so only the allowed event can wakeup the host */ - hci_set_event_mask_sync(hdev); - /* Enable event filter for paired devices */ hci_update_event_filter_sync(hdev); -- 2.37.1.359.gd136c6c3e2-goog

1 year, 9 months

2
1
0 0

[for-next][PATCH 21/21] tracing: Use a struct alignof to determine trace event field alignment

by Steven Rostedt

From: "Steven Rostedt (Google)" <rostedt(a)goodmis.org> alignof() gives an alignment of types as they would be as standalone variables. But alignment in structures might be different, and when building the fields of events, the alignment must be the actual alignment otherwise the field offsets may not match what they actually are. This caused trace-cmd to crash, as libtraceevent did not check if the field offset was bigger than the event. The write_msr and read_msr events on 32 bit had their fields incorrect, because it had a u64 field between two ints. alignof(u64) would give 8, but the u64 field was at a 4 byte alignment. Define a macro as: ALIGN_STRUCTFIELD(type) ((int)(offsetof(struct {char a; type b;}, b))) which gives the actual alignment of types in a structure. Link: https://lkml.kernel.org/r/20220731015928.7ab3a154@rorschach.local.home Cc: Ingo Molnar <mingo(a)kernel.org> Cc: Andrew Morton <akpm(a)linux-foundation.org> Cc: Peter Zijlstra <peterz(a)infradead.org> Cc: Thomas Gleixner <tglx(a)linutronix.de> Cc: Masami Hiramatsu <mhiramat(a)kernel.org> Cc: stable(a)vger.kernel.org Fixes: 04ae87a52074e ("ftrace: Rework event_create_dir()") Signed-off-by: Steven Rostedt (Google) <rostedt(a)goodmis.org> --- include/trace/stages/stage4_event_fields.h | 8 +++++--- 1 file changed, 5 insertions(+), 3 deletions(-) diff --git a/include/trace/stages/stage4_event_fields.h b/include/trace/stages/stage4_event_fields.h index c3790ec7a453..80d34f396555 100644 --- a/include/trace/stages/stage4_event_fields.h +++ b/include/trace/stages/stage4_event_fields.h @@ -2,16 +2,18 @@ /* Stage 4 definitions for creating trace events */ +#define ALIGN_STRUCTFIELD(type) ((int)(offsetof(struct {char a; type b;}, b))) + #undef __field_ext #define __field_ext(_type, _item, _filter_type) { \ .type = #_type, .name = #_item, \ - .size = sizeof(_type), .align = __alignof__(_type), \ + .size = sizeof(_type), .align = ALIGN_STRUCTFIELD(_type), \ .is_signed = is_signed_type(_type), .filter_type = _filter_type }, #undef __field_struct_ext #define __field_struct_ext(_type, _item, _filter_type) { \ .type = #_type, .name = #_item, \ - .size = sizeof(_type), .align = __alignof__(_type), \ + .size = sizeof(_type), .align = ALIGN_STRUCTFIELD(_type), \ 0, .filter_type = _filter_type }, #undef __field @@ -23,7 +25,7 @@ #undef __array #define __array(_type, _item, _len) { \ .type = #_type"["__stringify(_len)"]", .name = #_item, \ - .size = sizeof(_type[_len]), .align = __alignof__(_type), \ + .size = sizeof(_type[_len]), .align = ALIGN_STRUCTFIELD(_type), \ .is_signed = is_signed_type(_type), .filter_type = FILTER_OTHER }, #undef __dynamic_array -- 2.35.1

1 year, 9 months

2
2
0 0

[PATCH v3] tpm: Add check for Failure mode for TPM2 modules

by Mårten Lindahl

In commit 0aa698787aa2 ("tpm: Add Upgrade/Reduced mode support for TPM2 modules") it was said that: "If the TPM is in Failure mode, it will successfully respond to both tpm2_do_selftest() and tpm2_startup() calls. Although, will fail to answer to tpm2_get_cc_attrs_tbl(). Use this fact to conclude that TPM is in Failure mode." But a check was never added in the commit when calling tpm2_get_cc_attrs_tbl() to conclude that the TPM is in Failure mode. This commit corrects this by adding a check. Fixes: 0aa698787aa2 ("tpm: Add Upgrade/Reduced mode support for TPM2 modules") Cc: stable(a)vger.kernel.org # v5.17+ Signed-off-by: Mårten Lindahl <marten.lindahl(a)axis.com> Reviewed-by: Jarkko Sakkinen <jarkko(a)kernel.org> --- v3: - Add Jarkkos Reviewed-by tag. - Add Fixes tag and Cc. v2: - Add missed check for TPM error code. drivers/char/tpm/tpm2-cmd.c | 6 ++++++ 1 file changed, 6 insertions(+) diff --git a/drivers/char/tpm/tpm2-cmd.c b/drivers/char/tpm/tpm2-cmd.c index c1eb5d223839..65d03867e114 100644 --- a/drivers/char/tpm/tpm2-cmd.c +++ b/drivers/char/tpm/tpm2-cmd.c @@ -752,6 +752,12 @@ int tpm2_auto_startup(struct tpm_chip *chip) } rc = tpm2_get_cc_attrs_tbl(chip); + if (rc == TPM2_RC_FAILURE || (rc < 0 && rc != -ENOMEM)) { + dev_info(&chip->dev, + "TPM in field failure mode, requires firmware upgrade\n"); + chip->flags |= TPM_CHIP_FLAG_FIRMWARE_UPGRADE; + rc = 0; + } out: /* -- 2.30.2

1 year, 9 months

3
2
0 0

[PATCH 4.9 0/6] Convert isec->lock into a spinlock fixing deadlock on GFS2

by Alexander Grund

This patchset backports basically upstream commit 9287aed2 (selinux: Convert isec->lock into a spinlock). This "fixes a deadlock between selinux and GFS2 when GFS2 invalidates a security label", see the original discussion at https://lore.kernel.org/all/1478812710-17190-2-git-send-email-agruenba@redh… It also contains the follow-up fixes to make this correct. The first 3 commits (by Andreas) are valuable on their own too as they fix a documentation bug, avoid partially initialized structs and (slightly) improve performance while making the code cleaner. Andreas Gruenbacher (4): selinux: Minor cleanups proc: Pass file mode to proc_pid_make_inode selinux: Clean up initialization of isec->sclass selinux: Convert isec->lock into a spinlock Paul Moore (1): selinux: fix inode_doinit_with_dentry() LABEL_INVALID error handling Tianyue Ren (1): selinux: fix error initialization in inode_doinit_with_dentry() fs/proc/base.c | 23 +++--- fs/proc/fd.c | 6 +- fs/proc/internal.h | 2 +- fs/proc/namespaces.c | 3 +- security/selinux/hooks.c | 123 +++++++++++++++++++----------- security/selinux/include/objsec.h | 5 +- security/selinux/selinuxfs.c | 4 +- 7 files changed, 96 insertions(+), 70 deletions(-) -- 2.25.1

1 year, 9 months

2
7
0 0

[PATCH 4.9] ion: Make user_ion_handle_put_nolock() a void function

by Nathan Chancellor

Clang warns: drivers/staging/android/ion/ion-ioctl.c:71:6: warning: variable 'ret' is used uninitialized whenever 'if' condition is false [-Wsometimes-uninitialized] if (--handle->user_ref_count == 0) ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~ drivers/staging/android/ion/ion-ioctl.c:74:9: note: uninitialized use occurs here return ret; ^~~ drivers/staging/android/ion/ion-ioctl.c:71:2: note: remove the 'if' if its condition is always true if (--handle->user_ref_count == 0) ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ drivers/staging/android/ion/ion-ioctl.c:69:9: note: initialize the variable 'ret' to silence this warning int ret; ^ = 0 1 warning generated. The return value of user_ion_handle_put_nolock() is not checked in its one call site in user_ion_free_nolock() so just make user_ion_handle_put_nolock() return void to remove the warning. Fixes: a8200613c8c9 ("ion: Protect kref from userspace manipulation") Reported-by: kernel test robot <lkp(a)intel.com> Signed-off-by: Nathan Chancellor <nathan(a)kernel.org> --- drivers/staging/android/ion/ion-ioctl.c | 8 ++------ 1 file changed, 2 insertions(+), 6 deletions(-) diff --git a/drivers/staging/android/ion/ion-ioctl.c b/drivers/staging/android/ion/ion-ioctl.c index a27865b94416..e020a23d05f2 100644 --- a/drivers/staging/android/ion/ion-ioctl.c +++ b/drivers/staging/android/ion/ion-ioctl.c @@ -64,14 +64,10 @@ static struct ion_handle *pass_to_user(struct ion_handle *handle) } /* Must hold the client lock */ -static int user_ion_handle_put_nolock(struct ion_handle *handle) +static void user_ion_handle_put_nolock(struct ion_handle *handle) { - int ret; - if (--handle->user_ref_count == 0) - ret = ion_handle_put_nolock(handle); - - return ret; + ion_handle_put_nolock(handle); } static void user_ion_free_nolock(struct ion_client *client, base-commit: 65be5f5665a580424a7b1102f1a04c4259c559b5 -- 2.37.1

1 year, 9 months

2
1
0 0

[PATCH 5.10 v2 0/9] xfs stable patches for 5.10.y (from v5.13+)

by Amir Goldstein

Hi Greg, This backport series contains mostly fixes from v5.14 release along with one fix deferred from the first joint 5.10/5.15 series [1]. The upstream commit f8d92a66e810 ("xfs: prevent UAF in xfs_log_item_in_current_chkpt") was already applied to 5.15.y, but its 5.10.y backport was more involved (required two non trivial dependency patches), so it needed more time for review and testing. Per Darrick's recommendation, on top of the usual regression tests, I also ran the "recoveryloop" tests group for an extended period of time to test for rare regressions. Some recoveryloop tests were failing at rates less frequent than 1/100, but no change in failure rate was observed between baseline (v5.10.131) and the backport branch. There was one exceptional test, xfs/455, that was reporting data corruptions after crash at very low rate - less frequent than 1/1000 on both baseline and backport branch. It is hard to draw solid conclusions with such rare failures, but the test was run >10,000 times on baseline and >20,000 times on backport branch, so as far as our test coverage can attest, these backports are not introducing any obvious xfs regressions to 5.10.y. Thanks, Amir. Changes from [v1]: - Survived a week of crash recovery loop - Added Acked-by Darrick - CC stable [1] https://lore.kernel.org/linux-xfs/20220623203641.1710377-1-leah.rumancik@gm… [v1] https://lore.kernel.org/linux-xfs/20220726092125.3899077-1-amir73il@gmail.c… Brian Foster (2): xfs: hold buffer across unpin and potential shutdown processing xfs: remove dead stale buf unpin handling code Christoph Hellwig (1): xfs: refactor xfs_file_fsync Darrick J. Wong (3): xfs: prevent UAF in xfs_log_item_in_current_chkpt xfs: fix log intent recovery ENOSPC shutdowns when inactivating inodes xfs: force the log offline when log intent item recovery fails Dave Chinner (3): xfs: xfs_log_force_lsn isn't passed a LSN xfs: logging the on disk inode LSN can make it go backwards xfs: Enforce attr3 buffer recovery order fs/xfs/libxfs/xfs_log_format.h | 11 ++++- fs/xfs/libxfs/xfs_types.h | 1 + fs/xfs/xfs_buf_item.c | 60 ++++++++++-------------- fs/xfs/xfs_buf_item_recover.c | 1 + fs/xfs/xfs_dquot_item.c | 2 +- fs/xfs/xfs_file.c | 81 ++++++++++++++++++++------------- fs/xfs/xfs_inode.c | 10 ++-- fs/xfs/xfs_inode_item.c | 4 +- fs/xfs/xfs_inode_item.h | 2 +- fs/xfs/xfs_inode_item_recover.c | 39 ++++++++++++---- fs/xfs/xfs_log.c | 30 ++++++------ fs/xfs/xfs_log.h | 4 +- fs/xfs/xfs_log_cil.c | 32 +++++-------- fs/xfs/xfs_log_priv.h | 15 +++--- fs/xfs/xfs_log_recover.c | 5 +- fs/xfs/xfs_mount.c | 10 +++- fs/xfs/xfs_trans.c | 6 +-- fs/xfs/xfs_trans.h | 4 +- 18 files changed, 179 insertions(+), 138 deletions(-) -- 2.25.1

1 year, 9 months

2
10
0 0

[PATCH] ARM: crypto: comment out gcc warning that breaks clang builds

by Greg Kroah-Hartman

From: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> The gcc build warning prevents all clang-built kernels from working properly, so comment it out to fix the build. This is a -stable kernel only patch for now, it will be resolved differently in mainline releases in the future. Cc: "Jason A. Donenfeld" <Jason(a)zx2c4.com> Cc: "Justin M. Forbes" <jforbes(a)fedoraproject.org> Cc: Ard Biesheuvel <ardb(a)kernel.org> Cc: Arnd Bergmann <arnd(a)kernel.org> Cc: Nicolas Pitre <nico(a)linaro.org> Cc: Nathan Chancellor <nathan(a)kernel.org> Cc: Nick Desaulniers <ndesaulniers(a)google.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- arch/arm/lib/xor-neon.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/arch/arm/lib/xor-neon.c b/arch/arm/lib/xor-neon.c index b99dd8e1c93f..7ba6cf826162 100644 --- a/arch/arm/lib/xor-neon.c +++ b/arch/arm/lib/xor-neon.c @@ -26,8 +26,9 @@ MODULE_LICENSE("GPL"); * While older versions of GCC do not generate incorrect code, they fail to * recognize the parallel nature of these functions, and emit plain ARM code, * which is known to be slower than the optimized ARM code in asm-arm/xor.h. + * + * #warning This code requires at least version 4.6 of GCC */ -#warning This code requires at least version 4.6 of GCC #endif #pragma GCC diagnostic ignored "-Wunused-variable" -- 2.37.1

1 year, 9 months

3
5
0 0

FAILED: patch "[PATCH] mm/hugetlb: separate path for hwpoison entry in" failed to apply to 5.18-stable tree

by gregkh＠linuxfoundation.org

The patch below does not apply to the 5.18-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 c2cb0dcce9dd8b748b6ca8bb8d4a389f2e232307 Mon Sep 17 00:00:00 2001 From: Naoya Horiguchi <naoya.horiguchi(a)nec.com> Date: Mon, 4 Jul 2022 10:33:05 +0900 Subject: [PATCH] mm/hugetlb: separate path for hwpoison entry in copy_hugetlb_page_range() Originally copy_hugetlb_page_range() handles migration entries and hwpoisoned entries in similar manner. But recently the related code path has more code for migration entries, and when is_writable_migration_entry() was converted to !is_readable_migration_entry(), hwpoison entries on source processes got to be unexpectedly updated (which is legitimate for migration entries, but not for hwpoison entries). This results in unexpected serious issues like kernel panic when forking processes with hwpoison entries in pmd. Separate the if branch into one for hwpoison entries and one for migration entries. Link: https://lkml.kernel.org/r/20220704013312.2415700-3-naoya.horiguchi@linux.dev Fixes: 6c287605fd56 ("mm: remember exclusively mapped anonymous pages with PG_anon_exclusive") Signed-off-by: Naoya Horiguchi <naoya.horiguchi(a)nec.com> Reviewed-by: Miaohe Lin <linmiaohe(a)huawei.com> Reviewed-by: Mike Kravetz <mike.kravetz(a)oracle.com> Reviewed-by: Muchun Song <songmuchun(a)bytedance.com> Cc: <stable(a)vger.kernel.org> [5.18] Cc: David Hildenbrand <david(a)redhat.com> Cc: Liu Shixin <liushixin2(a)huawei.com> Cc: Oscar Salvador <osalvador(a)suse.de> Cc: Yang Shi <shy828301(a)gmail.com> Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> diff --git a/mm/hugetlb.c b/mm/hugetlb.c index a57e1be41401..baf7f6b19ce6 100644 --- a/mm/hugetlb.c +++ b/mm/hugetlb.c @@ -4788,8 +4788,13 @@ int copy_hugetlb_page_range(struct mm_struct *dst, struct mm_struct *src, * sharing with another vma. */ ; - } else if (unlikely(is_hugetlb_entry_migration(entry) || - is_hugetlb_entry_hwpoisoned(entry))) { + } else if (unlikely(is_hugetlb_entry_hwpoisoned(entry))) { + bool uffd_wp = huge_pte_uffd_wp(entry); + + if (!userfaultfd_wp(dst_vma) && uffd_wp) + entry = huge_pte_clear_uffd_wp(entry); + set_huge_pte_at(dst, addr, dst_pte, entry); + } else if (unlikely(is_hugetlb_entry_migration(entry))) { swp_entry_t swp_entry = pte_to_swp_entry(entry); bool uffd_wp = huge_pte_uffd_wp(entry);

1 year, 9 months

4
3
0 0

[PATCH stable 4.19 4.14 0/2] add fix patch for CVE-2021-3365

by Chen Jun

refer to https://lore.kernel.org/all/20220706150253.2186-1-deller@gmx.de/ 3 patches are provided to fix CVE-2021-3365 (When sending malicous data to kernel by ioctl cmd FBIOPUT_VSCREENINFO,kernel will write memory out of bounds. https://nvd.nist.gov/vuln/detail/CVE-2021-33655) in mainline. But only commit 65a01e601dbb ("fbcon: Disallow setting font bigger than screen size") was backported to stable (4.19,4.14). without other two commit commit e64242caef18 ("fbcon: Prevent that screen size is smaller than font size") commit 6c11df58fd1a ("fbmem: Check virtual screen sizes in fb_set_var()") The problem still exists. static long do_fb_ioctl(struct fb_info *info, unsigned int cmd, unsigned long arg) fb_set_var(info, &var); fb_notifier_call_chain(evnt, &event); // evnt = FB_EVENT_MODE_CHANGE static int fbcon_event_notify(struct notifier_block *self, unsigned long action, void *data) fbcon_modechanged(info); updatescrollmode(p, info, vc); ... p->vrows = vyres/fh; if (yres > (fh * (vc->vc_rows + 1))) p->vrows -= (yres - (fh * vc->vc_rows)) / fh; if ((yres % fh) && (vyres % fh < yres % fh)) p->vrows--; [1] [1]: p->vrows could be -1, like what CVE-2021-3365 described. I think, the two commits should be backported to 4.19 and 4.14. Helge Deller (2): fbcon: Prevent that screen size is smaller than font size fbmem: Check virtual screen sizes in fb_set_var() drivers/video/fbdev/core/fbcon.c | 28 ++++++++++++++++++++++++++++ drivers/video/fbdev/core/fbmem.c | 20 +++++++++++++++++--- include/linux/fbcon.h | 4 ++++ 3 files changed, 49 insertions(+), 3 deletions(-) -- 2.17.1

1 year, 9 months

3
4
0 0

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror July 2022