February 2022 - Linux-stable-mirror

CPU excessively long times between frequency scaling driver calls - bisected

by Doug Smythies

Hi All, Note before: I do not know If I have the e-mail address list correct, nor am I actually a member of the x86 distribution list. I am on the linux-pm email list. When using the intel_pstate CPU frequency scaling driver with HWP disabled, active mode, powersave scaling governor, the times between calls to the driver have never exceeded 10 seconds. Since kernel 5.16-rc4 and commit: b50db7095fe002fa3e16605546cba66bf1b68a3e " x86/tsc: Disable clocksource watchdog for TSC on qualified platorms" There are now occasions where times between calls to the driver can be over 100's of seconds and can result in the CPU frequency being left unnecessarily high for extended periods. From the number of clock cycles executed between these long durations one can tell that the CPU has been running code, but the driver never got called. Attached are some graphs from some trace data acquired using intel_pstate_tracer.py where one can observe an idle system between about 42 and well over 200 seconds elapsed time, yet CPU10 never gets called, which would have resulted in reducing it's pstate request, until an elapsed time of 167.616 seconds, 126 seconds since the last call. The CPU frequency never does go to minimum. For reference, a similar CPU frequency graph is also attached, with the commit reverted. The CPU frequency drops to minimum, over about 10 or 15 seconds. Processor: Intel(R) Core(TM) i5-10600K CPU @ 4.10GHz Why this particular configuration, i.e. no-hwp, active, powersave? Because it is, by far, the easiest to observe what is going on. ... Doug

2 years, 9 months

8
46
0 0

FAILED: patch "[PATCH] staging: fbtft: fb_st7789v: reset display before" 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 b6821b0d9b56386d2bf14806f90ec401468c799f Mon Sep 17 00:00:00 2001 From: Oliver Graute <oliver.graute(a)kococonnector.com> Date: Thu, 10 Feb 2022 09:53:22 +0100 Subject: [PATCH] staging: fbtft: fb_st7789v: reset display before initialization In rare cases the display is flipped or mirrored. This was observed more often in a low temperature environment. A clean reset on init_display() should help to get registers in a sane state. Fixes: ef8f317795da (staging: fbtft: use init function instead of init sequence) Cc: stable(a)vger.kernel.org Signed-off-by: Oliver Graute <oliver.graute(a)kococonnector.com> Link: https://lore.kernel.org/r/20220210085322.15676-1-oliver.graute@kococonnecto… Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> diff --git a/drivers/staging/fbtft/fb_st7789v.c b/drivers/staging/fbtft/fb_st7789v.c index abe9395a0aef..861a154144e6 100644 --- a/drivers/staging/fbtft/fb_st7789v.c +++ b/drivers/staging/fbtft/fb_st7789v.c @@ -144,6 +144,8 @@ static int init_display(struct fbtft_par *par) { int rc; + par->fbtftops.reset(par); + rc = init_tearing_effect_line(par); if (rc) return rc;

2 years, 9 months

3
2
0 0

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

2 years, 9 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);

2 years, 9 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,

2 years, 9 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,

2 years, 9 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

2 years, 9 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

2 years, 9 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(-)

2 years, 9 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

2 years, 9 months

3
4
0 0

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror February 2022