--- /dev/null
+From 9b2f20344d450137d015b380ff0c2e2a6a170135 Mon Sep 17 00:00:00 2001
+From: Zhang Xiaoxu <zhangxiaoxu5@huawei.com>
+Date: Tue, 1 Nov 2022 10:53:54 +0800
+Subject: btrfs: selftests: fix wrong error check in btrfs_free_dummy_root()
+
+From: Zhang Xiaoxu <zhangxiaoxu5@huawei.com>
+
+commit 9b2f20344d450137d015b380ff0c2e2a6a170135 upstream.
+
+The btrfs_alloc_dummy_root() uses ERR_PTR as the error return value
+rather than NULL, if error happened, there will be a NULL pointer
+dereference:
+
+ BUG: KASAN: null-ptr-deref in btrfs_free_dummy_root+0x21/0x50 [btrfs]
+ Read of size 8 at addr 000000000000002c by task insmod/258926
+
+ CPU: 2 PID: 258926 Comm: insmod Tainted: G W 6.1.0-rc2+ #5
+ Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.14.0-1.fc33 04/01/2014
+ Call Trace:
+ <TASK>
+ dump_stack_lvl+0x34/0x44
+ kasan_report+0xb7/0x140
+ kasan_check_range+0x145/0x1a0
+ btrfs_free_dummy_root+0x21/0x50 [btrfs]
+ btrfs_test_free_space_cache+0x1a8c/0x1add [btrfs]
+ btrfs_run_sanity_tests+0x65/0x80 [btrfs]
+ init_btrfs_fs+0xec/0x154 [btrfs]
+ do_one_initcall+0x87/0x2a0
+ do_init_module+0xdf/0x320
+ load_module+0x3006/0x3390
+ __do_sys_finit_module+0x113/0x1b0
+ do_syscall_64+0x35/0x80
+ entry_SYSCALL_64_after_hwframe+0x46/0xb0
+
+Fixes: aaedb55bc08f ("Btrfs: add tests for btrfs_get_extent")
+CC: stable@vger.kernel.org # 4.9+
+Reviewed-by: Anand Jain <anand.jain@oracle.com>
+Signed-off-by: Zhang Xiaoxu <zhangxiaoxu5@huawei.com>
+Reviewed-by: David Sterba <dsterba@suse.com>
+Signed-off-by: David Sterba <dsterba@suse.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ fs/btrfs/tests/btrfs-tests.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/fs/btrfs/tests/btrfs-tests.c
++++ b/fs/btrfs/tests/btrfs-tests.c
+@@ -183,7 +183,7 @@ void btrfs_free_dummy_fs_info(struct btr
+
+ void btrfs_free_dummy_root(struct btrfs_root *root)
+ {
+- if (!root)
++ if (IS_ERR_OR_NULL(root))
+ return;
+ /* Will be freed by btrfs_free_fs_roots */
+ if (WARN_ON(test_bit(BTRFS_ROOT_IN_RADIX, &root->state)))
--- /dev/null
+From 6bfb56e93bcef41859c2d5ab234ffd80b691be35 Mon Sep 17 00:00:00 2001
+From: Linus Torvalds <torvalds@linux-foundation.org>
+Date: Wed, 8 Jun 2022 13:18:39 -0700
+Subject: cert host tools: Stop complaining about deprecated OpenSSL functions
+
+From: Linus Torvalds <torvalds@linux-foundation.org>
+
+commit 6bfb56e93bcef41859c2d5ab234ffd80b691be35 upstream.
+
+OpenSSL 3.0 deprecated the OpenSSL's ENGINE API. That is as may be, but
+the kernel build host tools still use it. Disable the warning about
+deprecated declarations until somebody who cares fixes it.
+
+Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ scripts/sign-file.c | 7 +++++++
+ 1 file changed, 7 insertions(+)
+
+--- a/scripts/sign-file.c
++++ b/scripts/sign-file.c
+@@ -30,6 +30,13 @@
+ #include <openssl/engine.h>
+
+ /*
++ * OpenSSL 3.0 deprecates the OpenSSL's ENGINE API.
++ *
++ * Remove this if/when that API is no longer used
++ */
++#pragma GCC diagnostic ignored "-Wdeprecated-declarations"
++
++/*
+ * Use CMS if we have openssl-1.0.0 or newer available - otherwise we have to
+ * assume that it's not available and its header file is missing and that we
+ * should use PKCS#7 instead. Switching to the older PKCS#7 format restricts
--- /dev/null
+From 8ac932a4921a96ca52f61935dbba64ea87bbd5dc Mon Sep 17 00:00:00 2001
+From: Ryusuke Konishi <konishi.ryusuke@gmail.com>
+Date: Sat, 29 Oct 2022 13:49:12 +0900
+Subject: nilfs2: fix deadlock in nilfs_count_free_blocks()
+
+From: Ryusuke Konishi <konishi.ryusuke@gmail.com>
+
+commit 8ac932a4921a96ca52f61935dbba64ea87bbd5dc upstream.
+
+A semaphore deadlock can occur if nilfs_get_block() detects metadata
+corruption while locating data blocks and a superblock writeback occurs at
+the same time:
+
+task 1 task 2
+------ ------
+* A file operation *
+nilfs_truncate()
+ nilfs_get_block()
+ down_read(rwsem A) <--
+ nilfs_bmap_lookup_contig()
+ ... generic_shutdown_super()
+ nilfs_put_super()
+ * Prepare to write superblock *
+ down_write(rwsem B) <--
+ nilfs_cleanup_super()
+ * Detect b-tree corruption * nilfs_set_log_cursor()
+ nilfs_bmap_convert_error() nilfs_count_free_blocks()
+ __nilfs_error() down_read(rwsem A) <--
+ nilfs_set_error()
+ down_write(rwsem B) <--
+
+ *** DEADLOCK ***
+
+Here, nilfs_get_block() readlocks rwsem A (= NILFS_MDT(dat_inode)->mi_sem)
+and then calls nilfs_bmap_lookup_contig(), but if it fails due to metadata
+corruption, __nilfs_error() is called from nilfs_bmap_convert_error()
+inside the lock section.
+
+Since __nilfs_error() calls nilfs_set_error() unless the filesystem is
+read-only and nilfs_set_error() attempts to writelock rwsem B (=
+nilfs->ns_sem) to write back superblock exclusively, hierarchical lock
+acquisition occurs in the order rwsem A -> rwsem B.
+
+Now, if another task starts updating the superblock, it may writelock
+rwsem B during the lock sequence above, and can deadlock trying to
+readlock rwsem A in nilfs_count_free_blocks().
+
+However, there is actually no need to take rwsem A in
+nilfs_count_free_blocks() because it, within the lock section, only reads
+a single integer data on a shared struct with
+nilfs_sufile_get_ncleansegs(). This has been the case after commit
+aa474a220180 ("nilfs2: add local variable to cache the number of clean
+segments"), that is, even before this bug was introduced.
+
+So, this resolves the deadlock problem by just not taking the semaphore in
+nilfs_count_free_blocks().
+
+Link: https://lkml.kernel.org/r/20221029044912.9139-1-konishi.ryusuke@gmail.com
+Fixes: e828949e5b42 ("nilfs2: call nilfs_error inside bmap routines")
+Signed-off-by: Ryusuke Konishi <konishi.ryusuke@gmail.com>
+Reported-by: syzbot+45d6ce7b7ad7ef455d03@syzkaller.appspotmail.com
+Tested-by: Ryusuke Konishi <konishi.ryusuke@gmail.com>
+Cc: <stable@vger.kernel.org> [2.6.38+
+Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ fs/nilfs2/the_nilfs.c | 2 --
+ 1 file changed, 2 deletions(-)
+
+--- a/fs/nilfs2/the_nilfs.c
++++ b/fs/nilfs2/the_nilfs.c
+@@ -704,9 +704,7 @@ int nilfs_count_free_blocks(struct the_n
+ {
+ unsigned long ncleansegs;
+
+- down_read(&NILFS_MDT(nilfs->ns_dat)->mi_sem);
+ ncleansegs = nilfs_sufile_get_ncleansegs(nilfs->ns_sufile);
+- up_read(&NILFS_MDT(nilfs->ns_dat)->mi_sem);
+ *nblocks = (sector_t)ncleansegs * nilfs->ns_blocks_per_segment;
+ return 0;
+ }
--- /dev/null
+From 1598bfa8e1faa932de42e1ee7628a1c4c4263f0a Mon Sep 17 00:00:00 2001
+From: Jorge Lopez <jorge.lopez2@hp.com>
+Date: Fri, 28 Oct 2022 10:55:27 -0500
+Subject: platform/x86: hp_wmi: Fix rfkill causing soft blocked wifi
+
+From: Jorge Lopez <jorge.lopez2@hp.com>
+
+commit 1598bfa8e1faa932de42e1ee7628a1c4c4263f0a upstream.
+
+After upgrading BIOS to U82 01.02.01 Rev.A, the console is flooded
+strange char "^@" which printed out every second and makes login
+nearly impossible. Also the below messages were shown both in console
+and journal/dmesg every second:
+
+usb 1-3: Device not responding to setup address.
+usb 1-3: device not accepting address 4, error -71
+usb 1-3: device descriptor read/all, error -71
+usb usb1-port3: unable to enumerate USB device
+
+Wifi is soft blocked by checking rfkill. When unblocked manually,
+after few seconds it would be soft blocked again. So I was suspecting
+something triggered rfkill to soft block wifi. At the end it was
+fixed by removing hp_wmi module.
+
+The root cause is the way hp-wmi driver handles command 1B on
+post-2009 BIOS. In pre-2009 BIOS, command 1Bh return 0x4 to indicate
+that BIOS no longer controls the power for the wireless devices.
+
+Signed-off-by: Jorge Lopez <jorge.lopez2@hp.com>
+Link: https://bugzilla.kernel.org/show_bug.cgi?id=216468
+Reviewed-by: Mario Limonciello <mario.limonciello@amd.com>
+Link: https://lore.kernel.org/r/20221028155527.7724-1-jorge.lopez2@hp.com
+Cc: stable@vger.kernel.org
+Reviewed-by: Hans de Goede <hdegoede@redhat.com>
+Signed-off-by: Hans de Goede <hdegoede@redhat.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/platform/x86/hp-wmi.c | 12 ++++++++++--
+ 1 file changed, 10 insertions(+), 2 deletions(-)
+
+--- a/drivers/platform/x86/hp-wmi.c
++++ b/drivers/platform/x86/hp-wmi.c
+@@ -899,8 +899,16 @@ static int __init hp_wmi_bios_setup(stru
+ wwan_rfkill = NULL;
+ rfkill2_count = 0;
+
+- if (hp_wmi_rfkill_setup(device))
+- hp_wmi_rfkill2_setup(device);
++ /*
++ * In pre-2009 BIOS, command 1Bh return 0x4 to indicate that
++ * BIOS no longer controls the power for the wireless
++ * devices. All features supported by this command will no
++ * longer be supported.
++ */
++ if (!hp_wmi_bios_2009_later()) {
++ if (hp_wmi_rfkill_setup(device))
++ hp_wmi_rfkill2_setup(device);
++ }
+
+ err = device_create_file(&device->dev, &dev_attr_display);
+ if (err)
net-macvlan-fix-memory-leaks-of-macvlan_common_newli.patch
alsa-hda-fix-potential-memleak-in-add_widget_node.patch
alsa-usb-audio-add-quirk-entry-for-m-audio-micro.patch
+nilfs2-fix-deadlock-in-nilfs_count_free_blocks.patch
+platform-x86-hp_wmi-fix-rfkill-causing-soft-blocked-wifi.patch
+btrfs-selftests-fix-wrong-error-check-in-btrfs_free_dummy_root.patch
+udf-fix-a-slab-out-of-bounds-write-bug-in-udf_find_entry.patch
+cert-host-tools-stop-complaining-about-deprecated-openssl-functions.patch
--- /dev/null
+From c8af247de385ce49afabc3bf1cf4fd455c94bfe8 Mon Sep 17 00:00:00 2001
+From: ZhangPeng <zhangpeng362@huawei.com>
+Date: Wed, 9 Nov 2022 01:35:42 +0000
+Subject: udf: Fix a slab-out-of-bounds write bug in udf_find_entry()
+
+From: ZhangPeng <zhangpeng362@huawei.com>
+
+commit c8af247de385ce49afabc3bf1cf4fd455c94bfe8 upstream.
+
+Syzbot reported a slab-out-of-bounds Write bug:
+
+loop0: detected capacity change from 0 to 2048
+==================================================================
+BUG: KASAN: slab-out-of-bounds in udf_find_entry+0x8a5/0x14f0
+fs/udf/namei.c:253
+Write of size 105 at addr ffff8880123ff896 by task syz-executor323/3610
+
+CPU: 0 PID: 3610 Comm: syz-executor323 Not tainted
+6.1.0-rc2-syzkaller-00105-gb229b6ca5abb #0
+Hardware name: Google Compute Engine/Google Compute Engine, BIOS
+Google 10/11/2022
+Call Trace:
+ <TASK>
+ __dump_stack lib/dump_stack.c:88 [inline]
+ dump_stack_lvl+0x1b1/0x28e lib/dump_stack.c:106
+ print_address_description+0x74/0x340 mm/kasan/report.c:284
+ print_report+0x107/0x1f0 mm/kasan/report.c:395
+ kasan_report+0xcd/0x100 mm/kasan/report.c:495
+ kasan_check_range+0x2a7/0x2e0 mm/kasan/generic.c:189
+ memcpy+0x3c/0x60 mm/kasan/shadow.c:66
+ udf_find_entry+0x8a5/0x14f0 fs/udf/namei.c:253
+ udf_lookup+0xef/0x340 fs/udf/namei.c:309
+ lookup_open fs/namei.c:3391 [inline]
+ open_last_lookups fs/namei.c:3481 [inline]
+ path_openat+0x10e6/0x2df0 fs/namei.c:3710
+ do_filp_open+0x264/0x4f0 fs/namei.c:3740
+ do_sys_openat2+0x124/0x4e0 fs/open.c:1310
+ do_sys_open fs/open.c:1326 [inline]
+ __do_sys_creat fs/open.c:1402 [inline]
+ __se_sys_creat fs/open.c:1396 [inline]
+ __x64_sys_creat+0x11f/0x160 fs/open.c:1396
+ do_syscall_x64 arch/x86/entry/common.c:50 [inline]
+ do_syscall_64+0x3d/0xb0 arch/x86/entry/common.c:80
+ entry_SYSCALL_64_after_hwframe+0x63/0xcd
+RIP: 0033:0x7ffab0d164d9
+Code: ff ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 00 48 89 f8 48 89
+f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01
+f0 ff ff 73 01 c3 48 c7 c1 c0 ff ff ff f7 d8 64 89 01 48
+RSP: 002b:00007ffe1a7e6bb8 EFLAGS: 00000246 ORIG_RAX: 0000000000000055
+RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007ffab0d164d9
+RDX: 00007ffab0d164d9 RSI: 0000000000000000 RDI: 0000000020000180
+RBP: 00007ffab0cd5a10 R08: 0000000000000000 R09: 0000000000000000
+R10: 00005555573552c0 R11: 0000000000000246 R12: 00007ffab0cd5aa0
+R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000
+ </TASK>
+
+Allocated by task 3610:
+ kasan_save_stack mm/kasan/common.c:45 [inline]
+ kasan_set_track+0x3d/0x60 mm/kasan/common.c:52
+ ____kasan_kmalloc mm/kasan/common.c:371 [inline]
+ __kasan_kmalloc+0x97/0xb0 mm/kasan/common.c:380
+ kmalloc include/linux/slab.h:576 [inline]
+ udf_find_entry+0x7b6/0x14f0 fs/udf/namei.c:243
+ udf_lookup+0xef/0x340 fs/udf/namei.c:309
+ lookup_open fs/namei.c:3391 [inline]
+ open_last_lookups fs/namei.c:3481 [inline]
+ path_openat+0x10e6/0x2df0 fs/namei.c:3710
+ do_filp_open+0x264/0x4f0 fs/namei.c:3740
+ do_sys_openat2+0x124/0x4e0 fs/open.c:1310
+ do_sys_open fs/open.c:1326 [inline]
+ __do_sys_creat fs/open.c:1402 [inline]
+ __se_sys_creat fs/open.c:1396 [inline]
+ __x64_sys_creat+0x11f/0x160 fs/open.c:1396
+ do_syscall_x64 arch/x86/entry/common.c:50 [inline]
+ do_syscall_64+0x3d/0xb0 arch/x86/entry/common.c:80
+ entry_SYSCALL_64_after_hwframe+0x63/0xcd
+
+The buggy address belongs to the object at ffff8880123ff800
+ which belongs to the cache kmalloc-256 of size 256
+The buggy address is located 150 bytes inside of
+ 256-byte region [ffff8880123ff800, ffff8880123ff900)
+
+The buggy address belongs to the physical page:
+page:ffffea000048ff80 refcount:1 mapcount:0 mapping:0000000000000000
+index:0x0 pfn:0x123fe
+head:ffffea000048ff80 order:1 compound_mapcount:0 compound_pincount:0
+flags: 0xfff00000010200(slab|head|node=0|zone=1|lastcpupid=0x7ff)
+raw: 00fff00000010200 ffffea00004b8500 dead000000000003 ffff888012041b40
+raw: 0000000000000000 0000000080100010 00000001ffffffff 0000000000000000
+page dumped because: kasan: bad access detected
+page_owner tracks the page as allocated
+page last allocated via order 0, migratetype Unmovable, gfp_mask 0x0(),
+pid 1, tgid 1 (swapper/0), ts 1841222404, free_ts 0
+ create_dummy_stack mm/page_owner.c:67 [inline]
+ register_early_stack+0x77/0xd0 mm/page_owner.c:83
+ init_page_owner+0x3a/0x731 mm/page_owner.c:93
+ kernel_init_freeable+0x41c/0x5d5 init/main.c:1629
+ kernel_init+0x19/0x2b0 init/main.c:1519
+page_owner free stack trace missing
+
+Memory state around the buggy address:
+ ffff8880123ff780: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
+ ffff8880123ff800: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
+>ffff8880123ff880: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 06
+ ^
+ ffff8880123ff900: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
+ ffff8880123ff980: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
+==================================================================
+
+Fix this by changing the memory size allocated for copy_name from
+UDF_NAME_LEN(254) to UDF_NAME_LEN_CS0(255), because the total length
+(lfi) of subsequent memcpy can be up to 255.
+
+CC: stable@vger.kernel.org
+Reported-by: syzbot+69c9fdccc6dd08961d34@syzkaller.appspotmail.com
+Fixes: 066b9cded00b ("udf: Use separate buffer for copying split names")
+Signed-off-by: ZhangPeng <zhangpeng362@huawei.com>
+Signed-off-by: Jan Kara <jack@suse.cz>
+Link: https://lore.kernel.org/r/20221109013542.442790-1-zhangpeng362@huawei.com
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ fs/udf/namei.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/fs/udf/namei.c
++++ b/fs/udf/namei.c
+@@ -237,7 +237,7 @@ static struct fileIdentDesc *udf_find_en
+ poffset - lfi);
+ else {
+ if (!copy_name) {
+- copy_name = kmalloc(UDF_NAME_LEN,
++ copy_name = kmalloc(UDF_NAME_LEN_CS0,
+ GFP_NOFS);
+ if (!copy_name) {
+ fi = ERR_PTR(-ENOMEM);
projects / thirdparty / kernel / stable-queue.git / commitdiff
