February 2022 - Linux-stable-mirror

Backport Request: scsi: lpfc: Fix mailbox command failure during driver initialization

by James Smart

Please backport the following patch to the 5.10 and 5.15 kernels. It is currently in the 5.16 kernel. scsi: lpfc: Fix mailbox command failure during driver initialization commit efe1dc571a5b The error being corrected causes failure of adapter initialization and attachment. -- James

1 year, 6 months

2
4
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);

1 year, 6 months

3
7
0 0

FAILED: patch "[PATCH] thermal: int340x: fix memory leak in int3400_notify()" failed to apply to 4.19-stable tree

by gregkh＠linuxfoundation.org

The patch below does not apply to the 4.19-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 3abea10e6a8f0e7804ed4c124bea2d15aca977c8 Mon Sep 17 00:00:00 2001 From: Chuansheng Liu <chuansheng.liu(a)intel.com> Date: Wed, 23 Feb 2022 08:20:24 +0800 Subject: [PATCH] thermal: int340x: fix memory leak in int3400_notify() It is easy to hit the below memory leaks in my TigerLake platform: unreferenced object 0xffff927c8b91dbc0 (size 32): comm "kworker/0:2", pid 112, jiffies 4294893323 (age 83.604s) hex dump (first 32 bytes): 4e 41 4d 45 3d 49 4e 54 33 34 30 30 20 54 68 65 NAME=INT3400 The 72 6d 61 6c 00 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b a5 rmal.kkkkkkkkkk. backtrace: [<ffffffff9c502c3e>] __kmalloc_track_caller+0x2fe/0x4a0 [<ffffffff9c7b7c15>] kvasprintf+0x65/0xd0 [<ffffffff9c7b7d6e>] kasprintf+0x4e/0x70 [<ffffffffc04cb662>] int3400_notify+0x82/0x120 [int3400_thermal] [<ffffffff9c8b7358>] acpi_ev_notify_dispatch+0x54/0x71 [<ffffffff9c88f1a7>] acpi_os_execute_deferred+0x17/0x30 [<ffffffff9c2c2c0a>] process_one_work+0x21a/0x3f0 [<ffffffff9c2c2e2a>] worker_thread+0x4a/0x3b0 [<ffffffff9c2cb4dd>] kthread+0xfd/0x130 [<ffffffff9c201c1f>] ret_from_fork+0x1f/0x30 Fix it by calling kfree() accordingly. Fixes: 38e44da59130 ("thermal: int3400_thermal: process "thermal table changed" event") Signed-off-by: Chuansheng Liu <chuansheng.liu(a)intel.com> Cc: 4.14+ <stable(a)vger.kernel.org> # 4.14+ Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki(a)intel.com> diff --git a/drivers/thermal/intel/int340x_thermal/int3400_thermal.c b/drivers/thermal/intel/int340x_thermal/int3400_thermal.c index 72acb1f61849..4f478812cb51 100644 --- a/drivers/thermal/intel/int340x_thermal/int3400_thermal.c +++ b/drivers/thermal/intel/int340x_thermal/int3400_thermal.c @@ -404,6 +404,10 @@ static void int3400_notify(acpi_handle handle, thermal_prop[3] = kasprintf(GFP_KERNEL, "EVENT=%d", therm_event); thermal_prop[4] = NULL; kobject_uevent_env(&priv->thermal->device.kobj, KOBJ_CHANGE, thermal_prop); + kfree(thermal_prop[0]); + kfree(thermal_prop[1]); + kfree(thermal_prop[2]); + kfree(thermal_prop[3]); } static int int3400_thermal_get_temp(struct thermal_zone_device *thermal,

1 year, 6 months

2
1
0 0

FAILED: patch "[PATCH] thermal: int340x: fix memory leak in int3400_notify()" failed to apply to 5.4-stable tree

by gregkh＠linuxfoundation.org

The patch below does not apply to the 5.4-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 3abea10e6a8f0e7804ed4c124bea2d15aca977c8 Mon Sep 17 00:00:00 2001 From: Chuansheng Liu <chuansheng.liu(a)intel.com> Date: Wed, 23 Feb 2022 08:20:24 +0800 Subject: [PATCH] thermal: int340x: fix memory leak in int3400_notify() It is easy to hit the below memory leaks in my TigerLake platform: unreferenced object 0xffff927c8b91dbc0 (size 32): comm "kworker/0:2", pid 112, jiffies 4294893323 (age 83.604s) hex dump (first 32 bytes): 4e 41 4d 45 3d 49 4e 54 33 34 30 30 20 54 68 65 NAME=INT3400 The 72 6d 61 6c 00 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b a5 rmal.kkkkkkkkkk. backtrace: [<ffffffff9c502c3e>] __kmalloc_track_caller+0x2fe/0x4a0 [<ffffffff9c7b7c15>] kvasprintf+0x65/0xd0 [<ffffffff9c7b7d6e>] kasprintf+0x4e/0x70 [<ffffffffc04cb662>] int3400_notify+0x82/0x120 [int3400_thermal] [<ffffffff9c8b7358>] acpi_ev_notify_dispatch+0x54/0x71 [<ffffffff9c88f1a7>] acpi_os_execute_deferred+0x17/0x30 [<ffffffff9c2c2c0a>] process_one_work+0x21a/0x3f0 [<ffffffff9c2c2e2a>] worker_thread+0x4a/0x3b0 [<ffffffff9c2cb4dd>] kthread+0xfd/0x130 [<ffffffff9c201c1f>] ret_from_fork+0x1f/0x30 Fix it by calling kfree() accordingly. Fixes: 38e44da59130 ("thermal: int3400_thermal: process "thermal table changed" event") Signed-off-by: Chuansheng Liu <chuansheng.liu(a)intel.com> Cc: 4.14+ <stable(a)vger.kernel.org> # 4.14+ Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki(a)intel.com> diff --git a/drivers/thermal/intel/int340x_thermal/int3400_thermal.c b/drivers/thermal/intel/int340x_thermal/int3400_thermal.c index 72acb1f61849..4f478812cb51 100644 --- a/drivers/thermal/intel/int340x_thermal/int3400_thermal.c +++ b/drivers/thermal/intel/int340x_thermal/int3400_thermal.c @@ -404,6 +404,10 @@ static void int3400_notify(acpi_handle handle, thermal_prop[3] = kasprintf(GFP_KERNEL, "EVENT=%d", therm_event); thermal_prop[4] = NULL; kobject_uevent_env(&priv->thermal->device.kobj, KOBJ_CHANGE, thermal_prop); + kfree(thermal_prop[0]); + kfree(thermal_prop[1]); + kfree(thermal_prop[2]); + kfree(thermal_prop[3]); } static int int3400_thermal_get_temp(struct thermal_zone_device *thermal,

1 year, 6 months

2
1
0 0

[PATCH] mmc: sdhci-xenon: fix 1.8v regulator stabilization

by Marcin Wojtas

From: Alex Leibovich <alexl(a)marvell.com> Automatic Clock Gating is a feature used for the power consumption optimisation. It turned out that during early init phase it may prevent the stable voltage switch to 1.8V - due to that on some platfroms an endless printout in dmesg can be observed: "mmc1: 1.8V regulator output did not became stable" Fix the problem by disabling the ACG at very beginning of the sdhci_init and let that be enabled later. Fixes: 3a3748dba881 ("mmc: sdhci-xenon: Add Marvell Xenon SDHC core functionality") Signed-off-by: Alex Leibovich <alexl(a)marvell.com> Signed-off-by: Marcin Wojtas <mw(a)semihalf.com> Cc: stable(a)vger.kernel.org --- drivers/mmc/host/sdhci-xenon.c | 7 ++++++- 1 file changed, 6 insertions(+), 1 deletion(-) diff --git a/drivers/mmc/host/sdhci-xenon.c b/drivers/mmc/host/sdhci-xenon.c index c67611fdaa8a..4b05f6fdefb4 100644 --- a/drivers/mmc/host/sdhci-xenon.c +++ b/drivers/mmc/host/sdhci-xenon.c @@ -168,7 +168,12 @@ static void xenon_reset_exit(struct sdhci_host *host, /* Disable tuning request and auto-retuning again */ xenon_retune_setup(host); - xenon_set_acg(host, true); + /* + * The ACG should be turned off at the early init time, in order + * to solve a possile issues with the 1.8V regulator stabilization. + * The feature is enabled in later stage. + */ + xenon_set_acg(host, false); xenon_set_sdclk_off_idle(host, sdhc_id, false); -- 2.29.0

1 year, 6 months

4
10
0 0

[PATCH] mm: fix dereference a null pointer in migrate[_huge]_page_move_mapping()

by liqiong

Upstream has no this bug. The two functions look up a slot and dereference the pointer, If the pointer is null, the kernel would crash and dump. The 'numad' service calls 'migrate_pages' periodically. If some slots being replaced (Cache Eviction), the radix_tree_lookup_slot() returns a null pointer, then, kernel crash. "numad": crash> bt [exception RIP: migrate_page_move_mapping+337] Introduct a pointer checking to avoid dereference a null pointer. Cc: <stable(a)vger.kernel.org> # v4.19-rc8 Signed-off-by: liqiong <liqiong(a)nfschina.com> --- mm/migrate.c | 8 ++++++++ 1 file changed, 8 insertions(+) diff --git a/mm/migrate.c b/mm/migrate.c index 84381b55b2bd..1ff95c259511 100644 --- a/mm/migrate.c +++ b/mm/migrate.c @@ -474,6 +474,10 @@ int migrate_page_move_mapping(struct address_space *mapping, pslot = radix_tree_lookup_slot(&mapping->i_pages, page_index(page)); + if (pslot == NULL) { + xa_unlock_irq(&mapping->i_pages); + return -EAGAIN; + } expected_count += hpage_nr_pages(page) + page_has_private(page); if (page_count(page) != expected_count || @@ -592,6 +596,10 @@ int migrate_huge_page_move_mapping(struct address_space *mapping, xa_lock_irq(&mapping->i_pages); pslot = radix_tree_lookup_slot(&mapping->i_pages, page_index(page)); + if (pslot == NULL) { + xa_unlock_irq(&mapping->i_pages); + return -EAGAIN; + } expected_count = 2 + page_has_private(page); if (page_count(page) != expected_count || -- 2.25.1

1 year, 6 months

4
8
0 0

[PATCH 4.19 00/34] 4.19.232-rc1 review

by Greg Kroah-Hartman

This is the start of the stable review cycle for the 4.19.232 release. There are 34 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know. Responses should be made by Wed, 02 Mar 2022 17:20:16 +0000. Anything received after that time might be too late. The whole patch series can be found in one patch at: https://www.kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.19.232-r… or in the git tree and branch at: git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-4.19.y and the diffstat can be found below. thanks, greg k-h ------------- Pseudo-Shortlog of commits: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Linux 4.19.232-rc1 daniel.starke(a)siemens.com <daniel.starke(a)siemens.com> tty: n_gsm: fix encoding of control signal octet bit DV Hongyu Xie <xiehongyu1(a)kylinos.cn> xhci: Prevent futile URB re-submissions due to incorrect return value. Puma Hsu <pumahsu(a)google.com> xhci: re-initialize the HC during resume if HCE was set Sebastian Andrzej Siewior <bigeasy(a)linutronix.de> usb: dwc3: gadget: Let the interrupt handler disable bottom halves. Hans de Goede <hdegoede(a)redhat.com> usb: dwc3: pci: Fix Bay Trail phy GPIO mappings Daniele Palmas <dnlplm(a)gmail.com> USB: serial: option: add Telit LE910R1 compositions Slark Xiao <slark_xiao(a)163.com> USB: serial: option: add support for DW5829e Steven Rostedt (Google) <rostedt(a)goodmis.org> tracefs: Set the group ownership in apply_options() not parse_options() Szymon Heidrich <szymon.heidrich(a)gmail.com> USB: gadget: validate endpoint index for xilinx udc Daehwan Jung <dh10.jung(a)samsung.com> usb: gadget: rndis: add spinlock for rndis response list Dmytro Bagrii <dimich.dmb(a)gmail.com> Revert "USB: serial: ch341: add new Product ID for CH341A" Sergey Shtylyov <s.shtylyov(a)omp.ru> ata: pata_hpt37x: disable primary channel on HPT371 Christophe JAILLET <christophe.jaillet(a)wanadoo.fr> iio: adc: men_z188_adc: Fix a resource leak in an error handling path Steven Rostedt (Google) <rostedt(a)goodmis.org> tracing: Have traceon and traceoff trigger honor the instance Linus Torvalds <torvalds(a)linux-foundation.org> fget: clarify and improve __fget_files() implementation Miaohe Lin <linmiaohe(a)huawei.com> memblock: use kfree() to release kmalloced memblock regions Karol Herbst <kherbst(a)redhat.com> Revert "drm/nouveau/pmu/gm200-: avoid touching PMU outside of DEVINIT/PREOS/ACR" Marc Zyngier <maz(a)kernel.org> gpio: tegra186: Fix chip_data type confusion daniel.starke(a)siemens.com <daniel.starke(a)siemens.com> tty: n_gsm: fix proper link termination after failed open Bart Van Assche <bvanassche(a)acm.org> RDMA/ib_srp: Fix a deadlock ChenXiaoSong <chenxiaosong2(a)huawei.com> configfs: fix a race in configfs_{,un}register_subsystem() Gal Pressman <gal(a)nvidia.com> net/mlx5e: Fix wrong return value on ioctl EEPROM query failure Maxime Ripard <maxime(a)cerno.tech> drm/edid: Always set RGB444 Paul Blakey <paulb(a)nvidia.com> openvswitch: Fix setting ipv6 fields causing hw csum failure Tao Liu <thomas.liu(a)ucloud.cn> gso: do not skip outer ip header in case of ipip and net_failover Dan Carpenter <dan.carpenter(a)oracle.com> tipc: Fix end of loop tests for list_for_each_entry() Eric Dumazet <edumazet(a)google.com> net: __pskb_pull_tail() & pskb_carve_frag_list() drop_monitor friends Xin Long <lucien.xin(a)gmail.com> ping: remove pr_err from ping_lookup Oliver Neukum <oneukum(a)suse.com> USB: zaurus: support another broken Zaurus Oliver Neukum <oneukum(a)suse.com> sr9700: sanity check for packet length Helge Deller <deller(a)gmx.de> parisc/unaligned: Fix ldw() and stw() unalignment handlers Helge Deller <deller(a)gmx.de> parisc/unaligned: Fix fldd and fstd unaligned handlers on 32-bit kernel Stefano Garzarella <sgarzare(a)redhat.com> vhost/vsock: don't check owner in vhost_vsock_stop() while releasing Zhang Qiao <zhangqiao22(a)huawei.com> cgroup/cpuset: Fix a race between cpuset_attach() and cpu hotplug ------------- Diffstat: Makefile | 4 +- arch/parisc/kernel/unaligned.c | 14 ++--- drivers/ata/pata_hpt37x.c | 14 +++++ drivers/gpio/gpio-tegra186.c | 14 +++-- drivers/gpu/drm/drm_edid.c | 2 +- drivers/gpu/drm/nouveau/nvkm/subdev/pmu/base.c | 37 +++++------ drivers/iio/adc/men_z188_adc.c | 9 ++- drivers/infiniband/ulp/srp/ib_srp.c | 6 +- .../net/ethernet/mellanox/mlx5/core/en_ethtool.c | 2 +- drivers/net/usb/cdc_ether.c | 12 ++++ drivers/net/usb/sr9700.c | 2 +- drivers/net/usb/zaurus.c | 12 ++++ drivers/tty/n_gsm.c | 4 +- drivers/usb/dwc3/dwc3-pci.c | 4 +- drivers/usb/dwc3/gadget.c | 2 + drivers/usb/gadget/function/rndis.c | 8 +++ drivers/usb/gadget/function/rndis.h | 1 + drivers/usb/gadget/udc/udc-xilinx.c | 6 ++ drivers/usb/host/xhci.c | 28 ++++++--- drivers/usb/serial/ch341.c | 1 - drivers/usb/serial/option.c | 12 ++++ drivers/vhost/vsock.c | 21 ++++--- fs/configfs/dir.c | 14 +++++ fs/file.c | 73 +++++++++++++++++----- fs/tracefs/inode.c | 5 +- include/net/checksum.h | 5 ++ kernel/cgroup/cpuset.c | 2 + kernel/trace/trace_events_trigger.c | 52 +++++++++++++-- mm/memblock.c | 10 ++- net/core/skbuff.c | 4 +- net/ipv4/af_inet.c | 5 +- net/ipv4/ping.c | 1 - net/ipv6/ip6_offload.c | 2 + net/openvswitch/actions.c | 46 +++++++++++--- net/tipc/name_table.c | 2 +- net/tipc/socket.c | 2 +- 36 files changed, 337 insertions(+), 101 deletions(-)

1 year, 6 months

11
49
0 0

[PATCH -next] jffs2: fix use-after-free in jffs2_clear_xattr_subsystem

by Baokun Li

When we mount a jffs2 image, assume that the first few blocks of the image are normal and contain at least one xattr-related inode, but the next block is abnormal. As a result, an error is returned in jffs2_scan_eraseblock(). jffs2_clear_xattr_subsystem() is then called in jffs2_build_filesystem() and then again in jffs2_do_fill_super(). Finally we can observe the following report: ================================================================== BUG: KASAN: use-after-free in jffs2_clear_xattr_subsystem+0x95/0x6ac Read of size 8 at addr ffff8881243384e0 by task mount/719 Call Trace: dump_stack+0x115/0x16b jffs2_clear_xattr_subsystem+0x95/0x6ac jffs2_do_fill_super+0x84f/0xc30 jffs2_fill_super+0x2ea/0x4c0 mtd_get_sb+0x254/0x400 mtd_get_sb_by_nr+0x4f/0xd0 get_tree_mtd+0x498/0x840 jffs2_get_tree+0x25/0x30 vfs_get_tree+0x8d/0x2e0 path_mount+0x50f/0x1e50 do_mount+0x107/0x130 __se_sys_mount+0x1c5/0x2f0 __x64_sys_mount+0xc7/0x160 do_syscall_64+0x45/0x70 entry_SYSCALL_64_after_hwframe+0x44/0xa9 Allocated by task 719: kasan_save_stack+0x23/0x60 __kasan_kmalloc.constprop.0+0x10b/0x120 kasan_slab_alloc+0x12/0x20 kmem_cache_alloc+0x1c0/0x870 jffs2_alloc_xattr_ref+0x2f/0xa0 jffs2_scan_medium.cold+0x3713/0x4794 jffs2_do_mount_fs.cold+0xa7/0x2253 jffs2_do_fill_super+0x383/0xc30 jffs2_fill_super+0x2ea/0x4c0 [...] Freed by task 719: kmem_cache_free+0xcc/0x7b0 jffs2_free_xattr_ref+0x78/0x98 jffs2_clear_xattr_subsystem+0xa1/0x6ac jffs2_do_mount_fs.cold+0x5e6/0x2253 jffs2_do_fill_super+0x383/0xc30 jffs2_fill_super+0x2ea/0x4c0 [...] The buggy address belongs to the object at ffff8881243384b8 which belongs to the cache jffs2_xattr_ref of size 48 The buggy address is located 40 bytes inside of 48-byte region [ffff8881243384b8, ffff8881243384e8) [...] ================================================================== The triggering of the BUG is shown in the following stack: ----------------------------------------------------------- jffs2_fill_super jffs2_do_fill_super jffs2_do_mount_fs jffs2_build_filesystem jffs2_scan_medium jffs2_scan_eraseblock <--- ERROR jffs2_clear_xattr_subsystem <--- free jffs2_clear_xattr_subsystem <--- free again ----------------------------------------------------------- An error is returned in jffs2_do_mount_fs(). If the error is returned by jffs2_sum_init(), the jffs2_clear_xattr_subsystem() does not need to be executed. If the error is returned by jffs2_build_filesystem(), the jffs2_clear_xattr_subsystem() also does not need to be executed again. So move jffs2_clear_xattr_subsystem() from 'out_inohash' to 'out_root' to fix this UAF problem. Fixes: aa98d7cf59b5 ("[JFFS2][XATTR] XATTR support on JFFS2 (version. 5)") Cc: stable(a)vger.kernel.org Reported-by: Hulk Robot <hulkci(a)huawei.com> Signed-off-by: Baokun Li <libaokun1(a)huawei.com> --- fs/jffs2/fs.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/fs/jffs2/fs.c b/fs/jffs2/fs.c index 2ac410477c4f..71f03a5d36ed 100644 --- a/fs/jffs2/fs.c +++ b/fs/jffs2/fs.c @@ -603,8 +603,8 @@ int jffs2_do_fill_super(struct super_block *sb, struct fs_context *fc) jffs2_free_ino_caches(c); jffs2_free_raw_node_refs(c); kvfree(c->blocks); - out_inohash: jffs2_clear_xattr_subsystem(c); + out_inohash: kfree(c->inocache_list); out_wbuf: jffs2_flash_cleanup(c); -- 2.31.1

1 year, 6 months

3
4
0 0

[PATCH] userfaultfd: mark uffd_wp regardless of VM_WRITE flag

by Nadav Amit

From: Nadav Amit <namit(a)vmware.com> When a PTE is set by UFFD operations such as UFFDIO_COPY, the PTE is currently only marked as write-protected if the VMA has VM_WRITE flag set. This seems incorrect or at least would be unexpected by the users. Consider the following sequence of operations that are being performed on a certain page: mprotect(PROT_READ) UFFDIO_COPY(UFFDIO_COPY_MODE_WP) mprotect(PROT_READ|PROT_WRITE) At this point the user would expect to still get UFFD notification when the page is accessed for write, but the user would not get one, since the PTE was not marked as UFFD_WP during UFFDIO_COPY. Fix it by always marking PTEs as UFFD_WP regardless on the write-permission in the VMA flags. Fixes: 292924b26024 ("userfaultfd: wp: apply _PAGE_UFFD_WP bit") Cc: Mike Rapoport <rppt(a)linux.vnet.ibm.com> Cc: Andrea Arcangeli <aarcange(a)redhat.com> Cc: Peter Xu <peterx(a)redhat.com> Cc: <stable(a)vger.kernel.org> Signed-off-by: Nadav Amit <namit(a)vmware.com> --- mm/userfaultfd.c | 15 +++++++++------ 1 file changed, 9 insertions(+), 6 deletions(-) diff --git a/mm/userfaultfd.c b/mm/userfaultfd.c index 0780c2a57ff1..885e5adb0168 100644 --- a/mm/userfaultfd.c +++ b/mm/userfaultfd.c @@ -72,12 +72,15 @@ int mfill_atomic_install_pte(struct mm_struct *dst_mm, pmd_t *dst_pmd, _dst_pte = pte_mkdirty(_dst_pte); if (page_in_cache && !vm_shared) writable = false; - if (writable) { - if (wp_copy) - _dst_pte = pte_mkuffd_wp(_dst_pte); - else - _dst_pte = pte_mkwrite(_dst_pte); - } + + /* + * Always mark a PTE as write-protected when needed, regardless of + * VM_WRITE, which the user might change. + */ + if (wp_copy) + _dst_pte = pte_mkuffd_wp(_dst_pte); + else if (writable) + _dst_pte = pte_mkwrite(_dst_pte); dst_pte = pte_offset_map_lock(dst_mm, dst_pmd, dst_addr, &ptl); -- 2.25.1

1 year, 6 months

4
11
0 0

[tip: irq/urgent] PCI/MSI: Mask MSI-X vectors only on success

by tip-bot2 for Stefan Roese

The following commit has been merged into the irq/urgent branch of tip: Commit-ID: 83dbf898a2d45289be875deb580e93050ba67529 Gitweb: https://git.kernel.org/tip/83dbf898a2d45289be875deb580e93050ba67529 Author: Stefan Roese <sr(a)denx.de> AuthorDate: Tue, 14 Dec 2021 12:49:32 +01:00 Committer: Thomas Gleixner <tglx(a)linutronix.de> CommitterDate: Tue, 14 Dec 2021 13:23:32 +01:00 PCI/MSI: Mask MSI-X vectors only on success Masking all unused MSI-X entries is done to ensure that a crash kernel starts from a clean slate, which correponds to the reset state of the device as defined in the PCI-E specificion 3.0 and later: Vector Control for MSI-X Table Entries -------------------------------------- "00: Mask bit: When this bit is set, the function is prohibited from sending a message using this MSI-X Table entry. ... This bit’s state after reset is 1 (entry is masked)." A Marvell NVME device fails to deliver MSI interrupts after trying to enable MSI-X interrupts due to that masking. It seems to take the MSI-X mask bits into account even when MSI-X is disabled. While not specification compliant, this can be cured by moving the masking into the success path, so that the MSI-X table entries stay in device reset state when the MSI-X setup fails. [ tglx: Move it into the success path, add comment and amend changelog ] Fixes: aa8092c1d1f1 ("PCI/MSI: Mask all unused MSI-X entries") Signed-off-by: Stefan Roese <sr(a)denx.de> Signed-off-by: Thomas Gleixner <tglx(a)linutronix.de> Cc: linux-pci(a)vger.kernel.org Cc: Bjorn Helgaas <bhelgaas(a)google.com> Cc: Michal Simek <michal.simek(a)xilinx.com> Cc: Marek Vasut <marex(a)denx.de> Cc: stable(a)vger.kernel.org Link: https://lore.kernel.org/r/20211210161025.3287927-1-sr@denx.de --- drivers/pci/msi.c | 13 ++++++++++--- 1 file changed, 10 insertions(+), 3 deletions(-) diff --git a/drivers/pci/msi.c b/drivers/pci/msi.c index 48e3f4e..6748cf9 100644 --- a/drivers/pci/msi.c +++ b/drivers/pci/msi.c @@ -722,9 +722,6 @@ static int msix_capability_init(struct pci_dev *dev, struct msix_entry *entries, goto out_disable; } - /* Ensure that all table entries are masked. */ - msix_mask_all(base, tsize); - ret = msix_setup_entries(dev, base, entries, nvec, affd); if (ret) goto out_disable; @@ -751,6 +748,16 @@ static int msix_capability_init(struct pci_dev *dev, struct msix_entry *entries, /* Set MSI-X enabled bits and unmask the function */ pci_intx_for_msi(dev, 0); dev->msix_enabled = 1; + + /* + * Ensure that all table entries are masked to prevent + * stale entries from firing in a crash kernel. + * + * Done late to deal with a broken Marvell NVME device + * which takes the MSI-X mask bits into account even + * when MSI-X is disabled, which prevents MSI delivery. + */ + msix_mask_all(base, tsize); pci_msix_clear_and_set_ctrl(dev, PCI_MSIX_FLAGS_MASKALL, 0); pcibios_free_irq(dev);

1 year, 6 months

4
3
0 0

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror February 2022