--- /dev/null
+From 9056d6489f5a41cfbb67f719d2c0ce61ead72d9f Mon Sep 17 00:00:00 2001
+From: Chao Yu <chao@kernel.org>
+Date: Mon, 6 Dec 2021 22:44:19 +0800
+Subject: f2fs: fix to do sanity check on inode type during garbage collection
+
+From: Chao Yu <chao@kernel.org>
+
+commit 9056d6489f5a41cfbb67f719d2c0ce61ead72d9f upstream.
+
+As report by Wenqing Liu in bugzilla:
+
+https://bugzilla.kernel.org/show_bug.cgi?id=215231
+
+- Overview
+kernel NULL pointer dereference triggered in folio_mark_dirty() when mount and operate on a crafted f2fs image
+
+- Reproduce
+tested on kernel 5.16-rc3, 5.15.X under root
+
+1. mkdir mnt
+2. mount -t f2fs tmp1.img mnt
+3. touch tmp
+4. cp tmp mnt
+
+F2FS-fs (loop0): sanity_check_inode: inode (ino=49) extent info [5942, 4294180864, 4] is incorrect, run fsck to fix
+F2FS-fs (loop0): f2fs_check_nid_range: out-of-range nid=31340049, run fsck to fix.
+BUG: kernel NULL pointer dereference, address: 0000000000000000
+ folio_mark_dirty+0x33/0x50
+ move_data_page+0x2dd/0x460 [f2fs]
+ do_garbage_collect+0xc18/0x16a0 [f2fs]
+ f2fs_gc+0x1d3/0xd90 [f2fs]
+ f2fs_balance_fs+0x13a/0x570 [f2fs]
+ f2fs_create+0x285/0x840 [f2fs]
+ path_openat+0xe6d/0x1040
+ do_filp_open+0xc5/0x140
+ do_sys_openat2+0x23a/0x310
+ do_sys_open+0x57/0x80
+
+The root cause is for special file: e.g. character, block, fifo or socket file,
+f2fs doesn't assign address space operations pointer array for mapping->a_ops field,
+so, in a fuzzed image, SSA table indicates a data block belong to special file, when
+f2fs tries to migrate that block, it causes NULL pointer access once move_data_page()
+calls a_ops->set_dirty_page().
+
+Cc: stable@vger.kernel.org
+Reported-by: Wenqing Liu <wenqingliu0120@gmail.com>
+Signed-off-by: Chao Yu <chao@kernel.org>
+Signed-off-by: Jaegeuk Kim <jaegeuk@kernel.org>
+Signed-off-by: Kazunori Kobayashi <kazunori.kobayashi@miraclelinux.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ fs/f2fs/gc.c | 3 ++-
+ 1 file changed, 2 insertions(+), 1 deletion(-)
+
+--- a/fs/f2fs/gc.c
++++ b/fs/f2fs/gc.c
+@@ -841,7 +841,8 @@ next_step:
+
+ if (phase == 3) {
+ inode = f2fs_iget(sb, dni.ino);
+- if (IS_ERR(inode) || is_bad_inode(inode))
++ if (IS_ERR(inode) || is_bad_inode(inode) ||
++ special_file(inode->i_mode))
+ continue;
+
+ /* if encrypted inode, let's go phase 3 */
--- /dev/null
+From 3bb2a01caa813d3a1845d378bbe4169ef280d394 Mon Sep 17 00:00:00 2001
+From: Wang Hai <wanghai38@huawei.com>
+Date: Tue, 20 Dec 2022 09:21:43 +0800
+Subject: kobject: Fix slab-out-of-bounds in fill_kobj_path()
+
+From: Wang Hai <wanghai38@huawei.com>
+
+commit 3bb2a01caa813d3a1845d378bbe4169ef280d394 upstream.
+
+In kobject_get_path(), if kobj->name is changed between calls
+get_kobj_path_length() and fill_kobj_path() and the length becomes
+longer, then fill_kobj_path() will have an out-of-bounds bug.
+
+The actual current problem occurs when the ixgbe probe.
+
+In ixgbe_mii_bus_init(), if the length of netdev->dev.kobj.name
+length becomes longer, out-of-bounds will occur.
+
+cpu0 cpu1
+ixgbe_probe
+ register_netdev(netdev)
+ netdev_register_kobject
+ device_add
+ kobject_uevent // Sending ADD events
+ systemd-udevd // rename netdev
+ dev_change_name
+ device_rename
+ kobject_rename
+ ixgbe_mii_bus_init |
+ mdiobus_register |
+ __mdiobus_register |
+ device_register |
+ device_add |
+ kobject_uevent |
+ kobject_get_path |
+ len = get_kobj_path_length // old name |
+ path = kzalloc(len, gfp_mask); |
+ kobj->name = name;
+ /* name length becomes
+ * longer
+ */
+ fill_kobj_path /* kobj path length is
+ * longer than path,
+ * resulting in out of
+ * bounds when filling path
+ */
+
+This is the kasan report:
+
+==================================================================
+BUG: KASAN: slab-out-of-bounds in fill_kobj_path+0x50/0xc0
+Write of size 7 at addr ff1100090573d1fd by task kworker/28:1/673
+
+ Workqueue: events work_for_cpu_fn
+ Call Trace:
+ <TASK>
+ dump_stack_lvl+0x34/0x48
+ print_address_description.constprop.0+0x86/0x1e7
+ print_report+0x36/0x4f
+ kasan_report+0xad/0x130
+ kasan_check_range+0x35/0x1c0
+ memcpy+0x39/0x60
+ fill_kobj_path+0x50/0xc0
+ kobject_get_path+0x5a/0xc0
+ kobject_uevent_env+0x140/0x460
+ device_add+0x5c7/0x910
+ __mdiobus_register+0x14e/0x490
+ ixgbe_probe.cold+0x441/0x574 [ixgbe]
+ local_pci_probe+0x78/0xc0
+ work_for_cpu_fn+0x26/0x40
+ process_one_work+0x3b6/0x6a0
+ worker_thread+0x368/0x520
+ kthread+0x165/0x1a0
+ ret_from_fork+0x1f/0x30
+
+This reproducer triggers that bug:
+
+while:
+do
+ rmmod ixgbe
+ sleep 0.5
+ modprobe ixgbe
+ sleep 0.5
+
+When calling fill_kobj_path() to fill path, if the name length of
+kobj becomes longer, return failure and retry. This fixes the problem.
+
+Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
+Signed-off-by: Wang Hai <wanghai38@huawei.com>
+Link: https://lore.kernel.org/r/20221220012143.52141-1-wanghai38@huawei.com
+Signed-off-by: Oleksandr Tymoshenko <ovt@google.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ lib/kobject.c | 12 ++++++++++--
+ 1 file changed, 10 insertions(+), 2 deletions(-)
+
+--- a/lib/kobject.c
++++ b/lib/kobject.c
+@@ -118,7 +118,7 @@ static int get_kobj_path_length(struct k
+ return length;
+ }
+
+-static void fill_kobj_path(struct kobject *kobj, char *path, int length)
++static int fill_kobj_path(struct kobject *kobj, char *path, int length)
+ {
+ struct kobject *parent;
+
+@@ -127,12 +127,16 @@ static void fill_kobj_path(struct kobjec
+ int cur = strlen(kobject_name(parent));
+ /* back up enough to print this name with '/' */
+ length -= cur;
++ if (length <= 0)
++ return -EINVAL;
+ memcpy(path + length, kobject_name(parent), cur);
+ *(path + --length) = '/';
+ }
+
+ pr_debug("kobject: '%s' (%p): %s: path = '%s'\n", kobject_name(kobj),
+ kobj, __func__, path);
++
++ return 0;
+ }
+
+ /**
+@@ -148,13 +152,17 @@ char *kobject_get_path(struct kobject *k
+ char *path;
+ int len;
+
++retry:
+ len = get_kobj_path_length(kobj);
+ if (len == 0)
+ return NULL;
+ path = kzalloc(len, gfp_mask);
+ if (!path)
+ return NULL;
+- fill_kobj_path(kobj, path, len);
++ if (fill_kobj_path(kobj, path, len)) {
++ kfree(path);
++ goto retry;
++ }
+
+ return path;
+ }
--- /dev/null
+From 1aee9158bc978f91701c5992e395efbc6da2de3c Mon Sep 17 00:00:00 2001
+From: Al Viro <viro@zeniv.linux.org.uk>
+Date: Sat, 14 Oct 2023 21:34:40 -0400
+Subject: nfsd: lock_rename() needs both directories to live on the same fs
+
+From: Al Viro <viro@zeniv.linux.org.uk>
+
+commit 1aee9158bc978f91701c5992e395efbc6da2de3c upstream.
+
+... checking that after lock_rename() is too late. Incidentally,
+NFSv2 had no nfserr_xdev...
+
+Fixes: aa387d6ce153 "nfsd: fix EXDEV checking in rename"
+Cc: stable@vger.kernel.org # v3.9+
+Reviewed-by: Jeff Layton <jlayton@kernel.org>
+Acked-by: Chuck Lever <chuck.lever@oracle.com>
+Tested-by: Jeff Layton <jlayton@kernel.org>
+Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ fs/nfsd/vfs.c | 12 ++++++------
+ 1 file changed, 6 insertions(+), 6 deletions(-)
+
+--- a/fs/nfsd/vfs.c
++++ b/fs/nfsd/vfs.c
+@@ -1665,6 +1665,12 @@ nfsd_rename(struct svc_rqst *rqstp, stru
+ if (!flen || isdotent(fname, flen) || !tlen || isdotent(tname, tlen))
+ goto out;
+
++ err = (rqstp->rq_vers == 2) ? nfserr_acces : nfserr_xdev;
++ if (ffhp->fh_export->ex_path.mnt != tfhp->fh_export->ex_path.mnt)
++ goto out;
++ if (ffhp->fh_export->ex_path.dentry != tfhp->fh_export->ex_path.dentry)
++ goto out;
++
+ host_err = fh_want_write(ffhp);
+ if (host_err) {
+ err = nfserrno(host_err);
+@@ -1698,12 +1704,6 @@ nfsd_rename(struct svc_rqst *rqstp, stru
+ if (ndentry == trap)
+ goto out_dput_new;
+
+- host_err = -EXDEV;
+- if (ffhp->fh_export->ex_path.mnt != tfhp->fh_export->ex_path.mnt)
+- goto out_dput_new;
+- if (ffhp->fh_export->ex_path.dentry != tfhp->fh_export->ex_path.dentry)
+- goto out_dput_new;
+-
+ host_err = vfs_rename(fdir, odentry, tdir, ndentry, NULL, 0);
+ if (!host_err) {
+ host_err = commit_metadata(tfhp);
nfs-don-t-call-generic_error_remove_page-while-holdi.patch
arm-8933-1-replace-sun-solaris-style-flag-on-section.patch
drm-dp_mst-fix-null-deref-in-get_mst_branch_device_by_guid_helper.patch
+kobject-fix-slab-out-of-bounds-in-fill_kobj_path.patch
+f2fs-fix-to-do-sanity-check-on-inode-type-during-garbage-collection.patch
+nfsd-lock_rename-needs-both-directories-to-live-on-the-same-fs.patch
+x86-i8259-skip-probing-when-acpi-madt-advertises-pcat-compatibility.patch
--- /dev/null
+From 128b0c9781c9f2651bea163cb85e52a6c7be0f9e Mon Sep 17 00:00:00 2001
+From: Thomas Gleixner <tglx@linutronix.de>
+Date: Wed, 25 Oct 2023 23:04:15 +0200
+Subject: x86/i8259: Skip probing when ACPI/MADT advertises PCAT compatibility
+
+From: Thomas Gleixner <tglx@linutronix.de>
+
+commit 128b0c9781c9f2651bea163cb85e52a6c7be0f9e upstream.
+
+David and a few others reported that on certain newer systems some legacy
+interrupts fail to work correctly.
+
+Debugging revealed that the BIOS of these systems leaves the legacy PIC in
+uninitialized state which makes the PIC detection fail and the kernel
+switches to a dummy implementation.
+
+Unfortunately this fallback causes quite some code to fail as it depends on
+checks for the number of legacy PIC interrupts or the availability of the
+real PIC.
+
+In theory there is no reason to use the PIC on any modern system when
+IO/APIC is available, but the dependencies on the related checks cannot be
+resolved trivially and on short notice. This needs lots of analysis and
+rework.
+
+The PIC detection has been added to avoid quirky checks and force selection
+of the dummy implementation all over the place, especially in VM guest
+scenarios. So it's not an option to revert the relevant commit as that
+would break a lot of other scenarios.
+
+One solution would be to try to initialize the PIC on detection fail and
+retry the detection, but that puts the burden on everything which does not
+have a PIC.
+
+Fortunately the ACPI/MADT table header has a flag field, which advertises
+in bit 0 that the system is PCAT compatible, which means it has a legacy
+8259 PIC.
+
+Evaluate that bit and if set avoid the detection routine and keep the real
+PIC installed, which then gets initialized (for nothing) and makes the rest
+of the code with all the dependencies work again.
+
+Fixes: e179f6914152 ("x86, irq, pic: Probe for legacy PIC and set legacy_pic appropriately")
+Reported-by: David Lazar <dlazar@gmail.com>
+Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
+Tested-by: David Lazar <dlazar@gmail.com>
+Reviewed-by: Hans de Goede <hdegoede@redhat.com>
+Reviewed-by: Mario Limonciello <mario.limonciello@amd.com>
+Cc: stable@vger.kernel.org
+Closes: https://bugzilla.kernel.org/show_bug.cgi?id=218003
+Link: https://lore.kernel.org/r/875y2u5s8g.ffs@tglx
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ arch/x86/include/asm/i8259.h | 2 ++
+ arch/x86/kernel/acpi/boot.c | 3 +++
+ arch/x86/kernel/i8259.c | 38 ++++++++++++++++++++++++++++++--------
+ 3 files changed, 35 insertions(+), 8 deletions(-)
+
+--- a/arch/x86/include/asm/i8259.h
++++ b/arch/x86/include/asm/i8259.h
+@@ -67,6 +67,8 @@ struct legacy_pic {
+ void (*make_irq)(unsigned int irq);
+ };
+
++void legacy_pic_pcat_compat(void);
++
+ extern struct legacy_pic *legacy_pic;
+ extern struct legacy_pic null_legacy_pic;
+
+--- a/arch/x86/kernel/acpi/boot.c
++++ b/arch/x86/kernel/acpi/boot.c
+@@ -156,6 +156,9 @@ static int __init acpi_parse_madt(struct
+ madt->address);
+ }
+
++ if (madt->flags & ACPI_MADT_PCAT_COMPAT)
++ legacy_pic_pcat_compat();
++
+ default_acpi_madt_oem_check(madt->header.oem_id,
+ madt->header.oem_table_id);
+
+--- a/arch/x86/kernel/i8259.c
++++ b/arch/x86/kernel/i8259.c
+@@ -32,6 +32,7 @@
+ */
+ static void init_8259A(int auto_eoi);
+
++static bool pcat_compat __ro_after_init;
+ static int i8259A_auto_eoi;
+ DEFINE_RAW_SPINLOCK(i8259A_lock);
+
+@@ -300,15 +301,32 @@ static void unmask_8259A(void)
+
+ static int probe_8259A(void)
+ {
++ unsigned char new_val, probe_val = ~(1 << PIC_CASCADE_IR);
+ unsigned long flags;
+- unsigned char probe_val = ~(1 << PIC_CASCADE_IR);
+- unsigned char new_val;
++
++ /*
++ * If MADT has the PCAT_COMPAT flag set, then do not bother probing
++ * for the PIC. Some BIOSes leave the PIC uninitialized and probing
++ * fails.
++ *
++ * Right now this causes problems as quite some code depends on
++ * nr_legacy_irqs() > 0 or has_legacy_pic() == true. This is silly
++ * when the system has an IO/APIC because then PIC is not required
++ * at all, except for really old machines where the timer interrupt
++ * must be routed through the PIC. So just pretend that the PIC is
++ * there and let legacy_pic->init() initialize it for nothing.
++ *
++ * Alternatively this could just try to initialize the PIC and
++ * repeat the probe, but for cases where there is no PIC that's
++ * just pointless.
++ */
++ if (pcat_compat)
++ return nr_legacy_irqs();
++
+ /*
+- * Check to see if we have a PIC.
+- * Mask all except the cascade and read
+- * back the value we just wrote. If we don't
+- * have a PIC, we will read 0xff as opposed to the
+- * value we wrote.
++ * Check to see if we have a PIC. Mask all except the cascade and
++ * read back the value we just wrote. If we don't have a PIC, we
++ * will read 0xff as opposed to the value we wrote.
+ */
+ raw_spin_lock_irqsave(&i8259A_lock, flags);
+
+@@ -430,5 +448,9 @@ static int __init i8259A_init_ops(void)
+
+ return 0;
+ }
+-
+ device_initcall(i8259A_init_ops);
++
++void __init legacy_pic_pcat_compat(void)
++{
++ pcat_compat = true;
++}
projects / thirdparty / kernel / stable-queue.git / commitdiff
