--- /dev/null
+From daf004f87c3520c414992893e2eadd5db5f86a5a Mon Sep 17 00:00:00 2001
+From: Da Xue <da@libre.computer>
+Date: Mon, 12 May 2025 10:26:16 -0400
+Subject: clk: meson-g12a: add missing fclk_div2 to spicc
+
+From: Da Xue <da@libre.computer>
+
+commit daf004f87c3520c414992893e2eadd5db5f86a5a upstream.
+
+SPICC is missing fclk_div2, which means fclk_div5 and fclk_div7 indexes
+are wrong on this clock. This causes the spicc module to output sclk at
+2.5x the expected rate when clock index 3 is picked.
+
+Adding the missing fclk_div2 resolves this.
+
+[jbrunet: amended commit description]
+Fixes: a18c8e0b7697 ("clk: meson: g12a: add support for the SPICC SCLK Source clocks")
+Cc: stable@vger.kernel.org # 6.1
+Signed-off-by: Da Xue <da@libre.computer>
+Reviewed-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
+Link: https://lore.kernel.org/r/20250512142617.2175291-1-da@libre.computer
+Signed-off-by: Jerome Brunet <jbrunet@baylibre.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/clk/meson/g12a.c | 1 +
+ 1 file changed, 1 insertion(+)
+
+--- a/drivers/clk/meson/g12a.c
++++ b/drivers/clk/meson/g12a.c
+@@ -3969,6 +3969,7 @@ static const struct clk_parent_data spic
+ { .hw = &g12a_clk81.hw },
+ { .hw = &g12a_fclk_div4.hw },
+ { .hw = &g12a_fclk_div3.hw },
++ { .hw = &g12a_fclk_div2.hw },
+ { .hw = &g12a_fclk_div5.hw },
+ { .hw = &g12a_fclk_div7.hw },
+ };
--- /dev/null
+From e5ef4cd2a47f27c0c9d8ff6c0f63a18937c071a3 Mon Sep 17 00:00:00 2001
+From: Niravkumar L Rabara <niravkumar.l.rabara@intel.com>
+Date: Tue, 27 May 2025 07:57:07 -0700
+Subject: EDAC/altera: Use correct write width with the INTTEST register
+
+From: Niravkumar L Rabara <niravkumar.l.rabara@intel.com>
+
+commit e5ef4cd2a47f27c0c9d8ff6c0f63a18937c071a3 upstream.
+
+On the SoCFPGA platform, the INTTEST register supports only 16-bit writes.
+A 32-bit write triggers an SError to the CPU so do 16-bit accesses only.
+
+ [ bp: AI-massage the commit message. ]
+
+Fixes: c7b4be8db8bc ("EDAC, altera: Add Arria10 OCRAM ECC support")
+Signed-off-by: Niravkumar L Rabara <niravkumar.l.rabara@intel.com>
+Signed-off-by: Matthew Gerlach <matthew.gerlach@altera.com>
+Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de>
+Acked-by: Dinh Nguyen <dinguyen@kernel.org>
+Cc: stable@kernel.org
+Link: https://lore.kernel.org/20250527145707.25458-1-matthew.gerlach@altera.com
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/edac/altera_edac.c | 6 +++---
+ 1 file changed, 3 insertions(+), 3 deletions(-)
+
+--- a/drivers/edac/altera_edac.c
++++ b/drivers/edac/altera_edac.c
+@@ -1756,9 +1756,9 @@ altr_edac_a10_device_trig(struct file *f
+
+ local_irq_save(flags);
+ if (trig_type == ALTR_UE_TRIGGER_CHAR)
+- writel(priv->ue_set_mask, set_addr);
++ writew(priv->ue_set_mask, set_addr);
+ else
+- writel(priv->ce_set_mask, set_addr);
++ writew(priv->ce_set_mask, set_addr);
+
+ /* Ensure the interrupt test bits are set */
+ wmb();
+@@ -1788,7 +1788,7 @@ altr_edac_a10_device_trig2(struct file *
+
+ local_irq_save(flags);
+ if (trig_type == ALTR_UE_TRIGGER_CHAR) {
+- writel(priv->ue_set_mask, set_addr);
++ writew(priv->ue_set_mask, set_addr);
+ } else {
+ /* Setup read/write of 4 bytes */
+ writel(ECC_WORD_WRITE, drvdata->base + ECC_BLK_DBYTECTRL_OFST);
--- /dev/null
+From 1a77a028a392fab66dd637cdfac3f888450d00af Mon Sep 17 00:00:00 2001
+From: Zhang Yi <yi.zhang@huawei.com>
+Date: Tue, 6 May 2025 09:20:09 +0800
+Subject: ext4: ensure i_size is smaller than maxbytes
+
+From: Zhang Yi <yi.zhang@huawei.com>
+
+commit 1a77a028a392fab66dd637cdfac3f888450d00af upstream.
+
+The inode i_size cannot be larger than maxbytes, check it while loading
+inode from the disk.
+
+Signed-off-by: Zhang Yi <yi.zhang@huawei.com>
+Reviewed-by: Jan Kara <jack@suse.cz>
+Reviewed-by: Baokun Li <libaokun1@huawei.com>
+Link: https://patch.msgid.link/20250506012009.3896990-4-yi.zhang@huaweicloud.com
+Signed-off-by: Theodore Ts'o <tytso@mit.edu>
+Cc: stable@kernel.org
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ fs/ext4/inode.c | 3 ++-
+ 1 file changed, 2 insertions(+), 1 deletion(-)
+
+--- a/fs/ext4/inode.c
++++ b/fs/ext4/inode.c
+@@ -4968,7 +4968,8 @@ struct inode *__ext4_iget(struct super_b
+ ei->i_file_acl |=
+ ((__u64)le16_to_cpu(raw_inode->i_file_acl_high)) << 32;
+ inode->i_size = ext4_isize(sb, raw_inode);
+- if ((size = i_size_read(inode)) < 0) {
++ size = i_size_read(inode);
++ if (size < 0 || size > ext4_get_maxbytes(inode)) {
+ ext4_error_inode(inode, function, line, 0,
+ "iget: bad i_size value: %lld", size);
+ ret = -EFSCORRUPTED;
--- /dev/null
+From dbe27f06fa38b9bfc598f8864ae1c5d5831d9992 Mon Sep 17 00:00:00 2001
+From: Zhang Yi <yi.zhang@huawei.com>
+Date: Tue, 6 May 2025 09:20:08 +0800
+Subject: ext4: factor out ext4_get_maxbytes()
+
+From: Zhang Yi <yi.zhang@huawei.com>
+
+commit dbe27f06fa38b9bfc598f8864ae1c5d5831d9992 upstream.
+
+There are several locations that get the correct maxbytes value based on
+the inode's block type. It would be beneficial to extract a common
+helper function to make the code more clear.
+
+Signed-off-by: Zhang Yi <yi.zhang@huawei.com>
+Reviewed-by: Jan Kara <jack@suse.cz>
+Reviewed-by: Baokun Li <libaokun1@huawei.com>
+Link: https://patch.msgid.link/20250506012009.3896990-3-yi.zhang@huaweicloud.com
+Signed-off-by: Theodore Ts'o <tytso@mit.edu>
+Cc: stable@kernel.org
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ fs/ext4/ext4.h | 7 +++++++
+ fs/ext4/extents.c | 7 +------
+ fs/ext4/file.c | 7 +------
+ 3 files changed, 9 insertions(+), 12 deletions(-)
+
+--- a/fs/ext4/ext4.h
++++ b/fs/ext4/ext4.h
+@@ -3354,6 +3354,13 @@ static inline unsigned int ext4_flex_bg_
+ return 1 << sbi->s_log_groups_per_flex;
+ }
+
++static inline loff_t ext4_get_maxbytes(struct inode *inode)
++{
++ if (ext4_test_inode_flag(inode, EXT4_INODE_EXTENTS))
++ return inode->i_sb->s_maxbytes;
++ return EXT4_SB(inode->i_sb)->s_bitmap_maxbytes;
++}
++
+ #define ext4_std_error(sb, errno) \
+ do { \
+ if ((errno)) \
+--- a/fs/ext4/extents.c
++++ b/fs/ext4/extents.c
+@@ -4974,12 +4974,7 @@ static const struct iomap_ops ext4_iomap
+
+ static int ext4_fiemap_check_ranges(struct inode *inode, u64 start, u64 *len)
+ {
+- u64 maxbytes;
+-
+- if (ext4_test_inode_flag(inode, EXT4_INODE_EXTENTS))
+- maxbytes = inode->i_sb->s_maxbytes;
+- else
+- maxbytes = EXT4_SB(inode->i_sb)->s_bitmap_maxbytes;
++ u64 maxbytes = ext4_get_maxbytes(inode);
+
+ if (*len == 0)
+ return -EINVAL;
+--- a/fs/ext4/file.c
++++ b/fs/ext4/file.c
+@@ -880,12 +880,7 @@ static int ext4_file_open(struct inode *
+ loff_t ext4_llseek(struct file *file, loff_t offset, int whence)
+ {
+ struct inode *inode = file->f_mapping->host;
+- loff_t maxbytes;
+-
+- if (!(ext4_test_inode_flag(inode, EXT4_INODE_EXTENTS)))
+- maxbytes = EXT4_SB(inode->i_sb)->s_bitmap_maxbytes;
+- else
+- maxbytes = inode->i_sb->s_maxbytes;
++ loff_t maxbytes = ext4_get_maxbytes(inode);
+
+ switch (whence) {
+ default:
--- /dev/null
+From 32a93f5bc9b9812fc710f43a4d8a6830f91e4988 Mon Sep 17 00:00:00 2001
+From: Jan Kara <jack@suse.cz>
+Date: Tue, 29 Apr 2025 19:55:36 +0200
+Subject: ext4: fix calculation of credits for extent tree modification
+
+From: Jan Kara <jack@suse.cz>
+
+commit 32a93f5bc9b9812fc710f43a4d8a6830f91e4988 upstream.
+
+Luis and David are reporting that after running generic/750 test for 90+
+hours on 2k ext4 filesystem, they are able to trigger a warning in
+jbd2_journal_dirty_metadata() complaining that there are not enough
+credits in the running transaction started in ext4_do_writepages().
+
+Indeed the code in ext4_do_writepages() is racy and the extent tree can
+change between the time we compute credits necessary for extent tree
+computation and the time we actually modify the extent tree. Thus it may
+happen that the number of credits actually needed is higher. Modify
+ext4_ext_index_trans_blocks() to count with the worst case of maximum
+tree depth. This can reduce the possible number of writers that can
+operate in the system in parallel (because the credit estimates now won't
+fit in one transaction) but for reasonably sized journals this shouldn't
+really be an issue. So just go with a safe and simple fix.
+
+Link: https://lore.kernel.org/all/20250415013641.f2ppw6wov4kn4wq2@offworld
+Reported-by: Davidlohr Bueso <dave@stgolabs.net>
+Reported-by: Luis Chamberlain <mcgrof@kernel.org>
+Tested-by: kdevops@lists.linux.dev
+Signed-off-by: Jan Kara <jack@suse.cz>
+Reviewed-by: Zhang Yi <yi.zhang@huawei.com>
+Link: https://patch.msgid.link/20250429175535.23125-2-jack@suse.cz
+Signed-off-by: Theodore Ts'o <tytso@mit.edu>
+Cc: stable@kernel.org
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ fs/ext4/extents.c | 11 ++++++-----
+ 1 file changed, 6 insertions(+), 5 deletions(-)
+
+--- a/fs/ext4/extents.c
++++ b/fs/ext4/extents.c
+@@ -2374,18 +2374,19 @@ int ext4_ext_calc_credits_for_single_ext
+ int ext4_ext_index_trans_blocks(struct inode *inode, int extents)
+ {
+ int index;
+- int depth;
+
+ /* If we are converting the inline data, only one is needed here. */
+ if (ext4_has_inline_data(inode))
+ return 1;
+
+- depth = ext_depth(inode);
+-
++ /*
++ * Extent tree can change between the time we estimate credits and
++ * the time we actually modify the tree. Assume the worst case.
++ */
+ if (extents <= 1)
+- index = depth * 2;
++ index = EXT4_MAX_EXTENT_DEPTH * 2;
+ else
+- index = depth * 3;
++ index = EXT4_MAX_EXTENT_DEPTH * 3;
+
+ return index;
+ }
--- /dev/null
+From 227cb4ca5a6502164f850d22aec3104d7888b270 Mon Sep 17 00:00:00 2001
+From: Thadeu Lima de Souza Cascardo <cascardo@igalia.com>
+Date: Tue, 15 Apr 2025 11:53:04 -0300
+Subject: ext4: inline: fix len overflow in ext4_prepare_inline_data
+
+From: Thadeu Lima de Souza Cascardo <cascardo@igalia.com>
+
+commit 227cb4ca5a6502164f850d22aec3104d7888b270 upstream.
+
+When running the following code on an ext4 filesystem with inline_data
+feature enabled, it will lead to the bug below.
+
+ fd = open("file1", O_RDWR | O_CREAT | O_TRUNC, 0666);
+ ftruncate(fd, 30);
+ pwrite(fd, "a", 1, (1UL << 40) + 5UL);
+
+That happens because write_begin will succeed as when
+ext4_generic_write_inline_data calls ext4_prepare_inline_data, pos + len
+will be truncated, leading to ext4_prepare_inline_data parameter to be 6
+instead of 0x10000000006.
+
+Then, later when write_end is called, we hit:
+
+ BUG_ON(pos + len > EXT4_I(inode)->i_inline_size);
+
+at ext4_write_inline_data.
+
+Fix it by using a loff_t type for the len parameter in
+ext4_prepare_inline_data instead of an unsigned int.
+
+[ 44.545164] ------------[ cut here ]------------
+[ 44.545530] kernel BUG at fs/ext4/inline.c:240!
+[ 44.545834] Oops: invalid opcode: 0000 [#1] SMP NOPTI
+[ 44.546172] CPU: 3 UID: 0 PID: 343 Comm: test Not tainted 6.15.0-rc2-00003-g9080916f4863 #45 PREEMPT(full) 112853fcebfdb93254270a7959841d2c6aa2c8bb
+[ 44.546523] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014
+[ 44.546523] RIP: 0010:ext4_write_inline_data+0xfe/0x100
+[ 44.546523] Code: 3c 0e 48 83 c7 48 48 89 de 5b 41 5c 41 5d 41 5e 41 5f 5d e9 e4 fa 43 01 5b 41 5c 41 5d 41 5e 41 5f 5d c3 cc cc cc cc cc 0f 0b <0f> 0b 0f 1f 44 00 00 55 41 57 41 56 41 55 41 54 53 48 83 ec 20 49
+[ 44.546523] RSP: 0018:ffffb342008b79a8 EFLAGS: 00010216
+[ 44.546523] RAX: 0000000000000001 RBX: ffff9329c579c000 RCX: 0000010000000006
+[ 44.546523] RDX: 000000000000003c RSI: ffffb342008b79f0 RDI: ffff9329c158e738
+[ 44.546523] RBP: 0000000000000001 R08: 0000000000000001 R09: 0000000000000000
+[ 44.546523] R10: 00007ffffffff000 R11: ffffffff9bd0d910 R12: 0000006210000000
+[ 44.546523] R13: fffffc7e4015e700 R14: 0000010000000005 R15: ffff9329c158e738
+[ 44.546523] FS: 00007f4299934740(0000) GS:ffff932a60179000(0000) knlGS:0000000000000000
+[ 44.546523] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
+[ 44.546523] CR2: 00007f4299a1ec90 CR3: 0000000002886002 CR4: 0000000000770eb0
+[ 44.546523] PKRU: 55555554
+[ 44.546523] Call Trace:
+[ 44.546523] <TASK>
+[ 44.546523] ext4_write_inline_data_end+0x126/0x2d0
+[ 44.546523] generic_perform_write+0x17e/0x270
+[ 44.546523] ext4_buffered_write_iter+0xc8/0x170
+[ 44.546523] vfs_write+0x2be/0x3e0
+[ 44.546523] __x64_sys_pwrite64+0x6d/0xc0
+[ 44.546523] do_syscall_64+0x6a/0xf0
+[ 44.546523] ? __wake_up+0x89/0xb0
+[ 44.546523] ? xas_find+0x72/0x1c0
+[ 44.546523] ? next_uptodate_folio+0x317/0x330
+[ 44.546523] ? set_pte_range+0x1a6/0x270
+[ 44.546523] ? filemap_map_pages+0x6ee/0x840
+[ 44.546523] ? ext4_setattr+0x2fa/0x750
+[ 44.546523] ? do_pte_missing+0x128/0xf70
+[ 44.546523] ? security_inode_post_setattr+0x3e/0xd0
+[ 44.546523] ? ___pte_offset_map+0x19/0x100
+[ 44.546523] ? handle_mm_fault+0x721/0xa10
+[ 44.546523] ? do_user_addr_fault+0x197/0x730
+[ 44.546523] ? do_syscall_64+0x76/0xf0
+[ 44.546523] ? arch_exit_to_user_mode_prepare+0x1e/0x60
+[ 44.546523] ? irqentry_exit_to_user_mode+0x79/0x90
+[ 44.546523] entry_SYSCALL_64_after_hwframe+0x55/0x5d
+[ 44.546523] RIP: 0033:0x7f42999c6687
+[ 44.546523] Code: 48 89 fa 4c 89 df e8 58 b3 00 00 8b 93 08 03 00 00 59 5e 48 83 f8 fc 74 1a 5b c3 0f 1f 84 00 00 00 00 00 48 8b 44 24 10 0f 05 <5b> c3 0f 1f 80 00 00 00 00 83 e2 39 83 fa 08 75 de e8 23 ff ff ff
+[ 44.546523] RSP: 002b:00007ffeae4a7930 EFLAGS: 00000202 ORIG_RAX: 0000000000000012
+[ 44.546523] RAX: ffffffffffffffda RBX: 00007f4299934740 RCX: 00007f42999c6687
+[ 44.546523] RDX: 0000000000000001 RSI: 000055ea6149200f RDI: 0000000000000003
+[ 44.546523] RBP: 00007ffeae4a79a0 R08: 0000000000000000 R09: 0000000000000000
+[ 44.546523] R10: 0000010000000005 R11: 0000000000000202 R12: 0000000000000000
+[ 44.546523] R13: 00007ffeae4a7ac8 R14: 00007f4299b86000 R15: 000055ea61493dd8
+[ 44.546523] </TASK>
+[ 44.546523] Modules linked in:
+[ 44.568501] ---[ end trace 0000000000000000 ]---
+[ 44.568889] RIP: 0010:ext4_write_inline_data+0xfe/0x100
+[ 44.569328] Code: 3c 0e 48 83 c7 48 48 89 de 5b 41 5c 41 5d 41 5e 41 5f 5d e9 e4 fa 43 01 5b 41 5c 41 5d 41 5e 41 5f 5d c3 cc cc cc cc cc 0f 0b <0f> 0b 0f 1f 44 00 00 55 41 57 41 56 41 55 41 54 53 48 83 ec 20 49
+[ 44.570931] RSP: 0018:ffffb342008b79a8 EFLAGS: 00010216
+[ 44.571356] RAX: 0000000000000001 RBX: ffff9329c579c000 RCX: 0000010000000006
+[ 44.571959] RDX: 000000000000003c RSI: ffffb342008b79f0 RDI: ffff9329c158e738
+[ 44.572571] RBP: 0000000000000001 R08: 0000000000000001 R09: 0000000000000000
+[ 44.573148] R10: 00007ffffffff000 R11: ffffffff9bd0d910 R12: 0000006210000000
+[ 44.573748] R13: fffffc7e4015e700 R14: 0000010000000005 R15: ffff9329c158e738
+[ 44.574335] FS: 00007f4299934740(0000) GS:ffff932a60179000(0000) knlGS:0000000000000000
+[ 44.575027] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
+[ 44.575520] CR2: 00007f4299a1ec90 CR3: 0000000002886002 CR4: 0000000000770eb0
+[ 44.576112] PKRU: 55555554
+[ 44.576338] Kernel panic - not syncing: Fatal exception
+[ 44.576517] Kernel Offset: 0x1a600000 from 0xffffffff81000000 (relocation range: 0xffffffff80000000-0xffffffffbfffffff)
+
+Reported-by: syzbot+fe2a25dae02a207717a0@syzkaller.appspotmail.com
+Closes: https://syzkaller.appspot.com/bug?extid=fe2a25dae02a207717a0
+Fixes: f19d5870cbf7 ("ext4: add normal write support for inline data")
+Signed-off-by: Thadeu Lima de Souza Cascardo <cascardo@igalia.com>
+Cc: stable@vger.kernel.org
+Reviewed-by: Jan Kara <jack@suse.cz>
+Reviewed-by: Andreas Dilger <adilger@dilger.ca>
+Link: https://patch.msgid.link/20250415-ext4-prepare-inline-overflow-v1-1-f4c13d900967@igalia.com
+Signed-off-by: Theodore Ts'o <tytso@mit.edu>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ fs/ext4/inline.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/fs/ext4/inline.c
++++ b/fs/ext4/inline.c
+@@ -393,7 +393,7 @@ out:
+ }
+
+ static int ext4_prepare_inline_data(handle_t *handle, struct inode *inode,
+- unsigned int len)
++ loff_t len)
+ {
+ int ret, size, no_expand;
+ struct ext4_inode_info *ei = EXT4_I(inode);
--- /dev/null
+From 5db0d252c64e91ba1929c70112352e85dc5751e7 Mon Sep 17 00:00:00 2001
+From: Chao Yu <chao@kernel.org>
+Date: Mon, 14 Apr 2025 18:55:20 +0800
+Subject: f2fs: fix to do sanity check on sit_bitmap_size
+
+From: Chao Yu <chao@kernel.org>
+
+commit 5db0d252c64e91ba1929c70112352e85dc5751e7 upstream.
+
+w/ below testcase, resize will generate a corrupted image which
+contains inconsistent metadata, so when mounting such image, it
+will trigger kernel panic:
+
+touch img
+truncate -s $((512*1024*1024*1024)) img
+mkfs.f2fs -f img $((256*1024*1024))
+resize.f2fs -s -i img -t $((1024*1024*1024))
+mount img /mnt/f2fs
+
+------------[ cut here ]------------
+kernel BUG at fs/f2fs/segment.h:863!
+Oops: invalid opcode: 0000 [#1] SMP PTI
+CPU: 11 UID: 0 PID: 3922 Comm: mount Not tainted 6.15.0-rc1+ #191 PREEMPT(voluntary)
+Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014
+RIP: 0010:f2fs_ra_meta_pages+0x47c/0x490
+
+Call Trace:
+ f2fs_build_segment_manager+0x11c3/0x2600
+ f2fs_fill_super+0xe97/0x2840
+ mount_bdev+0xf4/0x140
+ legacy_get_tree+0x2b/0x50
+ vfs_get_tree+0x29/0xd0
+ path_mount+0x487/0xaf0
+ __x64_sys_mount+0x116/0x150
+ do_syscall_64+0x82/0x190
+ entry_SYSCALL_64_after_hwframe+0x76/0x7e
+RIP: 0033:0x7fdbfde1bcfe
+
+The reaseon is:
+
+sit_i->bitmap_size is 192, so size of sit bitmap is 192*8=1536, at maximum
+there are 1536 sit blocks, however MAIN_SEGS is 261893, so that sit_blk_cnt
+is 4762, build_sit_entries() -> current_sit_addr() tries to access
+out-of-boundary in sit_bitmap at offset from [1536, 4762), once sit_bitmap
+and sit_bitmap_mirror is not the same, it will trigger f2fs_bug_on().
+
+Let's add sanity check in f2fs_sanity_check_ckpt() to avoid panic.
+
+Cc: stable@vger.kernel.org
+Signed-off-by: Chao Yu <chao@kernel.org>
+Signed-off-by: Jaegeuk Kim <jaegeuk@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ fs/f2fs/super.c | 8 ++++++++
+ 1 file changed, 8 insertions(+)
+
+--- a/fs/f2fs/super.c
++++ b/fs/f2fs/super.c
+@@ -3499,6 +3499,7 @@ int f2fs_sanity_check_ckpt(struct f2fs_s
+ block_t user_block_count, valid_user_blocks;
+ block_t avail_node_count, valid_node_count;
+ unsigned int nat_blocks, nat_bits_bytes, nat_bits_blocks;
++ unsigned int sit_blk_cnt;
+ int i, j;
+
+ total = le32_to_cpu(raw_super->segment_count);
+@@ -3610,6 +3611,13 @@ skip_cross:
+ return 1;
+ }
+
++ sit_blk_cnt = DIV_ROUND_UP(main_segs, SIT_ENTRY_PER_BLOCK);
++ if (sit_bitmap_size * 8 < sit_blk_cnt) {
++ f2fs_err(sbi, "Wrong bitmap size: sit: %u, sit_blk_cnt:%u",
++ sit_bitmap_size, sit_blk_cnt);
++ return 1;
++ }
++
+ cp_pack_start_sum = __start_sum_addr(sbi);
+ cp_payload = __cp_payload(sbi);
+ if (cp_pack_start_sum < cp_payload + 1 ||
--- /dev/null
+From 42cb74a92adaf88061039601ddf7c874f58b554e Mon Sep 17 00:00:00 2001
+From: Jaegeuk Kim <jaegeuk@kernel.org>
+Date: Sat, 12 Apr 2025 21:09:46 +0000
+Subject: f2fs: prevent kernel warning due to negative i_nlink from corrupted image
+
+From: Jaegeuk Kim <jaegeuk@kernel.org>
+
+commit 42cb74a92adaf88061039601ddf7c874f58b554e upstream.
+
+WARNING: CPU: 1 PID: 9426 at fs/inode.c:417 drop_nlink+0xac/0xd0
+home/cc/linux/fs/inode.c:417
+Modules linked in:
+CPU: 1 UID: 0 PID: 9426 Comm: syz-executor568 Not tainted
+6.14.0-12627-g94d471a4f428 #2 PREEMPT(full)
+Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS
+1.13.0-1ubuntu1.1 04/01/2014
+RIP: 0010:drop_nlink+0xac/0xd0 home/cc/linux/fs/inode.c:417
+Code: 48 8b 5d 28 be 08 00 00 00 48 8d bb 70 07 00 00 e8 f9 67 e6 ff
+f0 48 ff 83 70 07 00 00 5b 5d e9 9a 12 82 ff e8 95 12 82 ff 90
+<0f> 0b 90 c7 45 48 ff ff ff ff 5b 5d e9 83 12 82 ff e8 fe 5f e6
+ff
+RSP: 0018:ffffc900026b7c28 EFLAGS: 00010293
+RAX: 0000000000000000 RBX: 0000000000000000 RCX: ffffffff8239710f
+RDX: ffff888041345a00 RSI: ffffffff8239717b RDI: 0000000000000005
+RBP: ffff888054509ad0 R08: 0000000000000005 R09: 0000000000000000
+R10: 0000000000000000 R11: ffffffff9ab36f08 R12: ffff88804bb40000
+R13: ffff8880545091e0 R14: 0000000000008000 R15: ffff8880545091e0
+FS: 000055555d0c5880(0000) GS:ffff8880eb3e3000(0000) knlGS:0000000000000000
+CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
+CR2: 00007f915c55b178 CR3: 0000000050d20000 CR4: 0000000000352ef0
+Call Trace:
+ <task>
+ f2fs_i_links_write home/cc/linux/fs/f2fs/f2fs.h:3194 [inline]
+ f2fs_drop_nlink+0xd1/0x3c0 home/cc/linux/fs/f2fs/dir.c:845
+ f2fs_delete_entry+0x542/0x1450 home/cc/linux/fs/f2fs/dir.c:909
+ f2fs_unlink+0x45c/0x890 home/cc/linux/fs/f2fs/namei.c:581
+ vfs_unlink+0x2fb/0x9b0 home/cc/linux/fs/namei.c:4544
+ do_unlinkat+0x4c5/0x6a0 home/cc/linux/fs/namei.c:4608
+ __do_sys_unlink home/cc/linux/fs/namei.c:4654 [inline]
+ __se_sys_unlink home/cc/linux/fs/namei.c:4652 [inline]
+ __x64_sys_unlink+0xc5/0x110 home/cc/linux/fs/namei.c:4652
+ do_syscall_x64 home/cc/linux/arch/x86/entry/syscall_64.c:63 [inline]
+ do_syscall_64+0xc7/0x250 home/cc/linux/arch/x86/entry/syscall_64.c:94
+ entry_SYSCALL_64_after_hwframe+0x77/0x7f
+RIP: 0033:0x7fb3d092324b
+Code: 73 01 c3 48 c7 c1 c0 ff ff ff f7 d8 64 89 01 48 83 c8 ff c3 66
+2e 0f 1f 84 00 00 00 00 00 90 f3 0f 1e fa b8 57 00 00 00 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:00007ffdc232d938 EFLAGS: 00000206 ORIG_RAX: 0000000000000057
+RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007fb3d092324b
+RDX: 00007ffdc232d960 RSI: 00007ffdc232d960 RDI: 00007ffdc232d9f0
+RBP: 00007ffdc232d9f0 R08: 0000000000000001 R09: 00007ffdc232d7c0
+R10: 00000000fffffffd R11: 0000000000000206 R12: 00007ffdc232eaf0
+R13: 000055555d0cebb0 R14: 00007ffdc232d958 R15: 0000000000000001
+ </task>
+
+Cc: stable@vger.kernel.org
+Reviewed-by: Chao Yu <chao@kernel.org>
+Signed-off-by: Jaegeuk Kim <jaegeuk@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ fs/f2fs/namei.c | 9 +++++++++
+ 1 file changed, 9 insertions(+)
+
+--- a/fs/f2fs/namei.c
++++ b/fs/f2fs/namei.c
+@@ -550,6 +550,15 @@ static int f2fs_unlink(struct inode *dir
+ goto fail;
+ }
+
++ if (unlikely(inode->i_nlink == 0)) {
++ f2fs_warn(F2FS_I_SB(inode), "%s: inode (ino=%lx) has zero i_nlink",
++ __func__, inode->i_ino);
++ err = -EFSCORRUPTED;
++ set_sbi_flag(F2FS_I_SB(inode), SBI_NEED_FSCK);
++ f2fs_put_page(page, 0);
++ goto fail;
++ }
++
+ f2fs_balance_fs(sbi, true);
+
+ f2fs_lock_op(sbi);
--- /dev/null
+From 05f6e183879d9785a3cdf2f08a498bc31b7a20aa Mon Sep 17 00:00:00 2001
+From: Murad Masimov <m.masimov@mt-integration.ru>
+Date: Mon, 28 Apr 2025 18:34:07 +0300
+Subject: fbdev: Fix fb_set_var to prevent null-ptr-deref in fb_videomode_to_var
+
+From: Murad Masimov <m.masimov@mt-integration.ru>
+
+commit 05f6e183879d9785a3cdf2f08a498bc31b7a20aa upstream.
+
+If fb_add_videomode() in fb_set_var() fails to allocate memory for
+fb_videomode, later it may lead to a null-ptr dereference in
+fb_videomode_to_var(), as the fb_info is registered while not having the
+mode in modelist that is expected to be there, i.e. the one that is
+described in fb_info->var.
+
+================================================================
+general protection fault, probably for non-canonical address 0xdffffc0000000001: 0000 [#1] PREEMPT SMP KASAN NOPTI
+KASAN: null-ptr-deref in range [0x0000000000000008-0x000000000000000f]
+CPU: 1 PID: 30371 Comm: syz-executor.1 Not tainted 5.10.226-syzkaller #0
+Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.12.0-1 04/01/2014
+RIP: 0010:fb_videomode_to_var+0x24/0x610 drivers/video/fbdev/core/modedb.c:901
+Call Trace:
+ display_to_var+0x3a/0x7c0 drivers/video/fbdev/core/fbcon.c:929
+ fbcon_resize+0x3e2/0x8f0 drivers/video/fbdev/core/fbcon.c:2071
+ resize_screen drivers/tty/vt/vt.c:1176 [inline]
+ vc_do_resize+0x53a/0x1170 drivers/tty/vt/vt.c:1263
+ fbcon_modechanged+0x3ac/0x6e0 drivers/video/fbdev/core/fbcon.c:2720
+ fbcon_update_vcs+0x43/0x60 drivers/video/fbdev/core/fbcon.c:2776
+ do_fb_ioctl+0x6d2/0x740 drivers/video/fbdev/core/fbmem.c:1128
+ fb_ioctl+0xe7/0x150 drivers/video/fbdev/core/fbmem.c:1203
+ vfs_ioctl fs/ioctl.c:48 [inline]
+ __do_sys_ioctl fs/ioctl.c:753 [inline]
+ __se_sys_ioctl fs/ioctl.c:739 [inline]
+ __x64_sys_ioctl+0x19a/0x210 fs/ioctl.c:739
+ do_syscall_64+0x33/0x40 arch/x86/entry/common.c:46
+ entry_SYSCALL_64_after_hwframe+0x67/0xd1
+================================================================
+
+The reason is that fb_info->var is being modified in fb_set_var(), and
+then fb_videomode_to_var() is called. If it fails to add the mode to
+fb_info->modelist, fb_set_var() returns error, but does not restore the
+old value of fb_info->var. Restore fb_info->var on failure the same way
+it is done earlier in the function.
+
+Found by Linux Verification Center (linuxtesting.org) with Syzkaller.
+
+Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
+Cc: stable@vger.kernel.org
+Signed-off-by: Murad Masimov <m.masimov@mt-integration.ru>
+Signed-off-by: Helge Deller <deller@gmx.de>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/video/fbdev/core/fbmem.c | 4 +++-
+ 1 file changed, 3 insertions(+), 1 deletion(-)
+
+--- a/drivers/video/fbdev/core/fbmem.c
++++ b/drivers/video/fbdev/core/fbmem.c
+@@ -1061,8 +1061,10 @@ fb_set_var(struct fb_info *info, struct
+ !list_empty(&info->modelist))
+ ret = fb_add_videomode(&mode, &info->modelist);
+
+- if (ret)
++ if (ret) {
++ info->var = old_var;
+ return ret;
++ }
+
+ event.info = info;
+ event.data = &mode;
--- /dev/null
+From 8f38219fa139623c29db2cb0f17d0a197a86e344 Mon Sep 17 00:00:00 2001
+From: Gatien Chevallier <gatien.chevallier@foss.st.com>
+Date: Fri, 30 May 2025 16:09:23 -0700
+Subject: Input: gpio-keys - fix possible concurrent access in gpio_keys_irq_timer()
+
+From: Gatien Chevallier <gatien.chevallier@foss.st.com>
+
+commit 8f38219fa139623c29db2cb0f17d0a197a86e344 upstream.
+
+gpio_keys_irq_isr() and gpio_keys_irq_timer() access the same resources.
+There could be a concurrent access if a GPIO interrupt occurs in parallel
+of a HR timer interrupt.
+
+Guard back those resources with a spinlock.
+
+Fixes: 019002f20cb5 ("Input: gpio-keys - use hrtimer for release timer")
+Signed-off-by: Gatien Chevallier <gatien.chevallier@foss.st.com>
+Link: https://lore.kernel.org/r/20250528-gpio_keys_preempt_rt-v2-2-3fc55a9c3619@foss.st.com
+Cc: stable@vger.kernel.org
+Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/input/keyboard/gpio_keys.c | 2 ++
+ 1 file changed, 2 insertions(+)
+
+--- a/drivers/input/keyboard/gpio_keys.c
++++ b/drivers/input/keyboard/gpio_keys.c
+@@ -455,6 +455,8 @@ static enum hrtimer_restart gpio_keys_ir
+ release_timer);
+ struct input_dev *input = bdata->input;
+
++ guard(spinlock_irqsave)(&bdata->lock);
++
+ if (bdata->key_pressed) {
+ input_event(input, EV_KEY, *bdata->code, 0);
+ input_sync(input);
--- /dev/null
+From a95ef0199e80f3384eb992889322957d26c00102 Mon Sep 17 00:00:00 2001
+From: Dan Carpenter <dan.carpenter@linaro.org>
+Date: Fri, 30 May 2025 16:13:32 -0700
+Subject: Input: ims-pcu - check record size in ims_pcu_flash_firmware()
+
+From: Dan Carpenter <dan.carpenter@linaro.org>
+
+commit a95ef0199e80f3384eb992889322957d26c00102 upstream.
+
+The "len" variable comes from the firmware and we generally do
+trust firmware, but it's always better to double check. If the "len"
+is too large it could result in memory corruption when we do
+"memcpy(fragment->data, rec->data, len);"
+
+Fixes: 628329d52474 ("Input: add IMS Passenger Control Unit driver")
+Signed-off-by: Dan Carpenter <dan.carpenter@linaro.org>
+Link: https://lore.kernel.org/r/131fd1ae92c828ee9f4fa2de03d8c210ae1f3524.1748463049.git.dan.carpenter@linaro.org
+Cc: stable@vger.kernel.org
+Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/input/misc/ims-pcu.c | 6 ++++++
+ 1 file changed, 6 insertions(+)
+
+--- a/drivers/input/misc/ims-pcu.c
++++ b/drivers/input/misc/ims-pcu.c
+@@ -845,6 +845,12 @@ static int ims_pcu_flash_firmware(struct
+ addr = be32_to_cpu(rec->addr) / 2;
+ len = be16_to_cpu(rec->len);
+
++ if (len > sizeof(pcu->cmd_buf) - 1 - sizeof(*fragment)) {
++ dev_err(pcu->dev,
++ "Invalid record length in firmware: %d\n", len);
++ return -EINVAL;
++ }
++
+ fragment = (void *)&pcu->cmd_buf[1];
+ put_unaligned_le32(addr, &fragment->addr);
+ fragment->len = len;
--- /dev/null
+From d66adabe91803ef34a8b90613c81267b5ded1472 Mon Sep 17 00:00:00 2001
+From: Jeongjun Park <aha310510@gmail.com>
+Date: Thu, 24 Apr 2025 23:33:22 +0900
+Subject: ipc: fix to protect IPCS lookups using RCU
+
+From: Jeongjun Park <aha310510@gmail.com>
+
+commit d66adabe91803ef34a8b90613c81267b5ded1472 upstream.
+
+syzbot reported that it discovered a use-after-free vulnerability, [0]
+
+[0]: https://lore.kernel.org/all/67af13f8.050a0220.21dd3.0038.GAE@google.com/
+
+idr_for_each() is protected by rwsem, but this is not enough. If it is
+not protected by RCU read-critical region, when idr_for_each() calls
+radix_tree_node_free() through call_rcu() to free the radix_tree_node
+structure, the node will be freed immediately, and when reading the next
+node in radix_tree_for_each_slot(), the already freed memory may be read.
+
+Therefore, we need to add code to make sure that idr_for_each() is
+protected within the RCU read-critical region when we call it in
+shm_destroy_orphaned().
+
+Link: https://lkml.kernel.org/r/20250424143322.18830-1-aha310510@gmail.com
+Fixes: b34a6b1da371 ("ipc: introduce shm_rmid_forced sysctl")
+Signed-off-by: Jeongjun Park <aha310510@gmail.com>
+Reported-by: syzbot+a2b84e569d06ca3a949c@syzkaller.appspotmail.com
+Cc: Jeongjun Park <aha310510@gmail.com>
+Cc: Liam Howlett <liam.howlett@oracle.com>
+Cc: Lorenzo Stoakes <lorenzo.stoakes@oracle.com>
+Cc: Matthew Wilcox (Oracle) <willy@infradead.org>
+Cc: Vasiliy Kulikov <segoon@openwall.com>
+Cc: <stable@vger.kernel.org>
+Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ ipc/shm.c | 5 ++++-
+ 1 file changed, 4 insertions(+), 1 deletion(-)
+
+--- a/ipc/shm.c
++++ b/ipc/shm.c
+@@ -430,8 +430,11 @@ static int shm_try_destroy_orphaned(int
+ void shm_destroy_orphaned(struct ipc_namespace *ns)
+ {
+ down_write(&shm_ids(ns).rwsem);
+- if (shm_ids(ns).in_use)
++ if (shm_ids(ns).in_use) {
++ rcu_read_lock();
+ idr_for_each(&shm_ids(ns).ipcs_idr, &shm_try_destroy_orphaned, ns);
++ rcu_read_unlock();
++ }
+ up_write(&shm_ids(ns).rwsem);
+ }
+
--- /dev/null
+From f83f362d40ccceb647f7d80eb92206733d76a36b Mon Sep 17 00:00:00 2001
+From: Jinliang Zheng <alexjlzheng@tencent.com>
+Date: Tue, 15 Apr 2025 17:02:32 +0800
+Subject: mm: fix ratelimit_pages update error in dirty_ratio_handler()
+
+From: Jinliang Zheng <alexjlzheng@tencent.com>
+
+commit f83f362d40ccceb647f7d80eb92206733d76a36b upstream.
+
+In dirty_ratio_handler(), vm_dirty_bytes must be set to zero before
+calling writeback_set_ratelimit(), as global_dirty_limits() always
+prioritizes the value of vm_dirty_bytes.
+
+It's domain_dirty_limits() that's relevant here, not node_dirty_ok:
+
+ dirty_ratio_handler
+ writeback_set_ratelimit
+ global_dirty_limits(&dirty_thresh) <- ratelimit_pages based on dirty_thresh
+ domain_dirty_limits
+ if (bytes) <- bytes = vm_dirty_bytes <--------+
+ thresh = f1(bytes) <- prioritizes vm_dirty_bytes |
+ else |
+ thresh = f2(ratio) |
+ ratelimit_pages = f3(dirty_thresh) |
+ vm_dirty_bytes = 0 <- it's late! ---------------------+
+
+This causes ratelimit_pages to still use the value calculated based on
+vm_dirty_bytes, which is wrong now.
+
+
+The impact visible to userspace is difficult to capture directly because
+there is no procfs/sysfs interface exported to user space. However, it
+will have a real impact on the balance of dirty pages.
+
+For example:
+
+1. On default, we have vm_dirty_ratio=40, vm_dirty_bytes=0
+
+2. echo 8192 > dirty_bytes, then vm_dirty_bytes=8192,
+ vm_dirty_ratio=0, and ratelimit_pages is calculated based on
+ vm_dirty_bytes now.
+
+3. echo 20 > dirty_ratio, then since vm_dirty_bytes is not reset to
+ zero when writeback_set_ratelimit() -> global_dirty_limits() ->
+ domain_dirty_limits() is called, reallimit_pages is still calculated
+ based on vm_dirty_bytes instead of vm_dirty_ratio. This does not
+ conform to the actual intent of the user.
+
+Link: https://lkml.kernel.org/r/20250415090232.7544-1-alexjlzheng@tencent.com
+Fixes: 9d823e8f6b1b ("writeback: per task dirty rate limit")
+Signed-off-by: Jinliang Zheng <alexjlzheng@tencent.com>
+Reviewed-by: MengEn Sun <mengensun@tencent.com>
+Cc: Andrea Righi <andrea@betterlinux.com>
+Cc: Fenggaung Wu <fengguang.wu@intel.com>
+Cc: Jinliang Zheng <alexjlzheng@tencent.com>
+Cc: Matthew Wilcox (Oracle) <willy@infradead.org>
+Cc: <stable@vger.kernel.org>
+Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ mm/page-writeback.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/mm/page-writeback.c
++++ b/mm/page-writeback.c
+@@ -540,8 +540,8 @@ static int dirty_ratio_handler(struct ct
+
+ ret = proc_dointvec_minmax(table, write, buffer, lenp, ppos);
+ if (ret == 0 && write && vm_dirty_ratio != old_ratio) {
+- writeback_set_ratelimit();
+ vm_dirty_bytes = 0;
++ writeback_set_ratelimit();
+ }
+ return ret;
+ }
--- /dev/null
+From ae409629e022fbebbc6d31a1bfeccdbbeee20fd6 Mon Sep 17 00:00:00 2001
+From: Heiner Kallweit <hkallweit1@gmail.com>
+Date: Tue, 17 Jun 2025 20:20:17 +0200
+Subject: net: ftgmac100: select FIXED_PHY
+
+From: Heiner Kallweit <hkallweit1@gmail.com>
+
+commit ae409629e022fbebbc6d31a1bfeccdbbeee20fd6 upstream.
+
+Depending on e.g. DT configuration this driver uses a fixed link.
+So we shouldn't rely on the user to enable FIXED_PHY, select it in
+Kconfig instead. We may end up with a non-functional driver otherwise.
+
+Fixes: 38561ded50d0 ("net: ftgmac100: support fixed link")
+Cc: stable@vger.kernel.org
+Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com>
+Link: https://patch.msgid.link/476bb33b-5584-40f0-826a-7294980f2895@gmail.com
+Signed-off-by: Jakub Kicinski <kuba@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/net/ethernet/faraday/Kconfig | 1 +
+ 1 file changed, 1 insertion(+)
+
+diff --git a/drivers/net/ethernet/faraday/Kconfig b/drivers/net/ethernet/faraday/Kconfig
+index c699bd6bcbb9..474073c7f94d 100644
+--- a/drivers/net/ethernet/faraday/Kconfig
++++ b/drivers/net/ethernet/faraday/Kconfig
+@@ -31,6 +31,7 @@ config FTGMAC100
+ depends on ARM || COMPILE_TEST
+ depends on !64BIT || BROKEN
+ select PHYLIB
++ select FIXED_PHY
+ select MDIO_ASPEED if MACH_ASPEED_G6
+ select CRC32
+ help
+--
+2.50.0
+
--- /dev/null
+From fc27ab48904ceb7e4792f0c400f1ef175edf16fe Mon Sep 17 00:00:00 2001
+From: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
+Date: Wed, 18 Jun 2025 09:36:50 +0200
+Subject: NFC: nci: uart: Set tty->disc_data only in success path
+
+From: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
+
+commit fc27ab48904ceb7e4792f0c400f1ef175edf16fe upstream.
+
+Setting tty->disc_data before opening the NCI device means we need to
+clean it up on error paths. This also opens some short window if device
+starts sending data, even before NCIUARTSETDRIVER IOCTL succeeded
+(broken hardware?). Close the window by exposing tty->disc_data only on
+the success path, when opening of the NCI device and try_module_get()
+succeeds.
+
+The code differs in error path in one aspect: tty->disc_data won't be
+ever assigned thus NULL-ified. This however should not be relevant
+difference, because of "tty->disc_data=NULL" in nci_uart_tty_open().
+
+Cc: Linus Torvalds <torvalds@linuxfoundation.org>
+Fixes: 9961127d4bce ("NFC: nci: add generic uart support")
+Cc: <stable@vger.kernel.org>
+Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
+Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+Link: https://patch.msgid.link/20250618073649.25049-2-krzysztof.kozlowski@linaro.org
+Signed-off-by: Jakub Kicinski <kuba@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ net/nfc/nci/uart.c | 8 ++++----
+ 1 file changed, 4 insertions(+), 4 deletions(-)
+
+--- a/net/nfc/nci/uart.c
++++ b/net/nfc/nci/uart.c
+@@ -119,22 +119,22 @@ static int nci_uart_set_driver(struct tt
+
+ memcpy(nu, nci_uart_drivers[driver], sizeof(struct nci_uart));
+ nu->tty = tty;
+- tty->disc_data = nu;
+ skb_queue_head_init(&nu->tx_q);
+ INIT_WORK(&nu->write_work, nci_uart_write_work);
+ spin_lock_init(&nu->rx_lock);
+
+ ret = nu->ops.open(nu);
+ if (ret) {
+- tty->disc_data = NULL;
+ kfree(nu);
++ return ret;
+ } else if (!try_module_get(nu->owner)) {
+ nu->ops.close(nu);
+- tty->disc_data = NULL;
+ kfree(nu);
+ return -ENOENT;
+ }
+- return ret;
++ tty->disc_data = nu;
++
++ return 0;
+ }
+
+ /* ------ LDISC part ------ */
--- /dev/null
+From 7cbb015e2d3d6f180256cde0c908eab21268e7b9 Mon Sep 17 00:00:00 2001
+From: Arnd Bergmann <arnd@arndb.de>
+Date: Tue, 20 May 2025 11:00:46 +0200
+Subject: parisc: fix building with gcc-15
+
+From: Arnd Bergmann <arnd@arndb.de>
+
+commit 7cbb015e2d3d6f180256cde0c908eab21268e7b9 upstream.
+
+The decompressor is built with the default C dialect, which is now gnu23
+on gcc-15, and this clashes with the kernel's bool type definition:
+
+In file included from include/uapi/linux/posix_types.h:5,
+ from arch/parisc/boot/compressed/misc.c:7:
+include/linux/stddef.h:11:9: error: cannot use keyword 'false' as enumeration constant
+ 11 | false = 0,
+
+Add the -std=gnu11 argument here, as we do for all other architectures.
+
+Cc: stable@vger.kernel.org
+Signed-off-by: Arnd Bergmann <arnd@arndb.de>
+Signed-off-by: Helge Deller <deller@gmx.de>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ arch/parisc/boot/compressed/Makefile | 1 +
+ 1 file changed, 1 insertion(+)
+
+--- a/arch/parisc/boot/compressed/Makefile
++++ b/arch/parisc/boot/compressed/Makefile
+@@ -22,6 +22,7 @@ KBUILD_CFLAGS += -fno-PIE -mno-space-reg
+ ifndef CONFIG_64BIT
+ KBUILD_CFLAGS += -mfast-indirect-calls
+ endif
++KBUILD_CFLAGS += -std=gnu11
+
+ LDFLAGS_vmlinux := -X -e startup --as-needed -T
+ $(obj)/vmlinux: $(obj)/vmlinux.lds $(addprefix $(obj)/, $(OBJECTS)) $(LIBGCC) FORCE
--- /dev/null
+From 213205889d5ffc19cb8df06aa6778b2d4724c887 Mon Sep 17 00:00:00 2001
+From: Helge Deller <deller@gmx.de>
+Date: Sat, 31 May 2025 15:26:27 +0200
+Subject: parisc/unaligned: Fix hex output to show 8 hex chars
+
+From: Helge Deller <deller@gmx.de>
+
+commit 213205889d5ffc19cb8df06aa6778b2d4724c887 upstream.
+
+Change back printk format to 0x%08lx instead of %#08lx, since the latter
+does not seem to reliably format the value to 8 hex chars.
+
+Signed-off-by: Helge Deller <deller@gmx.de>
+Cc: stable@vger.kernel.org # v5.18+
+Fixes: e5e9e7f222e5b ("parisc/unaligned: Enhance user-space visible output")
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ arch/parisc/kernel/unaligned.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/arch/parisc/kernel/unaligned.c
++++ b/arch/parisc/kernel/unaligned.c
+@@ -22,7 +22,7 @@
+ #define DPRINTF(fmt, args...)
+ #endif
+
+-#define RFMT "%#08lx"
++#define RFMT "0x%08lx"
+
+ /* 1111 1100 0000 0000 0001 0011 1100 0000 */
+ #define OPCODE1(a,b,c) ((a)<<26|(b)<<12|(c)<<6)
--- /dev/null
+From 6883b680e703c6b2efddb4e7a8d891ce1803d06b Mon Sep 17 00:00:00 2001
+From: Shin'ichiro Kawasaki <shinichiro.kawasaki@wdc.com>
+Date: Sat, 10 May 2025 19:10:36 +0900
+Subject: RDMA/iwcm: Fix use-after-free of work objects after cm_id destruction
+
+From: Shin'ichiro Kawasaki <shinichiro.kawasaki@wdc.com>
+
+commit 6883b680e703c6b2efddb4e7a8d891ce1803d06b upstream.
+
+The commit 59c68ac31e15 ("iw_cm: free cm_id resources on the last
+deref") simplified cm_id resource management by freeing cm_id once all
+references to the cm_id were removed. The references are removed either
+upon completion of iw_cm event handlers or when the application destroys
+the cm_id. This commit introduced the use-after-free condition where
+cm_id_private object could still be in use by event handler works during
+the destruction of cm_id. The commit aee2424246f9 ("RDMA/iwcm: Fix a
+use-after-free related to destroying CM IDs") addressed this use-after-
+free by flushing all pending works at the cm_id destruction.
+
+However, still another use-after-free possibility remained. It happens
+with the work objects allocated for each cm_id_priv within
+alloc_work_entries() during cm_id creation, and subsequently freed in
+dealloc_work_entries() once all references to the cm_id are removed.
+If the cm_id's last reference is decremented in the event handler work,
+the work object for the work itself gets removed, and causes the use-
+after-free BUG below:
+
+ BUG: KASAN: slab-use-after-free in __pwq_activate_work+0x1ff/0x250
+ Read of size 8 at addr ffff88811f9cf800 by task kworker/u16:1/147091
+
+ CPU: 2 UID: 0 PID: 147091 Comm: kworker/u16:1 Not tainted 6.15.0-rc2+ #27 PREEMPT(voluntary)
+ Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-3.fc41 04/01/2014
+ Workqueue: 0x0 (iw_cm_wq)
+ Call Trace:
+ <TASK>
+ dump_stack_lvl+0x6a/0x90
+ print_report+0x174/0x554
+ ? __virt_addr_valid+0x208/0x430
+ ? __pwq_activate_work+0x1ff/0x250
+ kasan_report+0xae/0x170
+ ? __pwq_activate_work+0x1ff/0x250
+ __pwq_activate_work+0x1ff/0x250
+ pwq_dec_nr_in_flight+0x8c5/0xfb0
+ process_one_work+0xc11/0x1460
+ ? __pfx_process_one_work+0x10/0x10
+ ? assign_work+0x16c/0x240
+ worker_thread+0x5ef/0xfd0
+ ? __pfx_worker_thread+0x10/0x10
+ kthread+0x3b0/0x770
+ ? __pfx_kthread+0x10/0x10
+ ? rcu_is_watching+0x11/0xb0
+ ? _raw_spin_unlock_irq+0x24/0x50
+ ? rcu_is_watching+0x11/0xb0
+ ? __pfx_kthread+0x10/0x10
+ ret_from_fork+0x30/0x70
+ ? __pfx_kthread+0x10/0x10
+ ret_from_fork_asm+0x1a/0x30
+ </TASK>
+
+ Allocated by task 147416:
+ kasan_save_stack+0x2c/0x50
+ kasan_save_track+0x10/0x30
+ __kasan_kmalloc+0xa6/0xb0
+ alloc_work_entries+0xa9/0x260 [iw_cm]
+ iw_cm_connect+0x23/0x4a0 [iw_cm]
+ rdma_connect_locked+0xbfd/0x1920 [rdma_cm]
+ nvme_rdma_cm_handler+0x8e5/0x1b60 [nvme_rdma]
+ cma_cm_event_handler+0xae/0x320 [rdma_cm]
+ cma_work_handler+0x106/0x1b0 [rdma_cm]
+ process_one_work+0x84f/0x1460
+ worker_thread+0x5ef/0xfd0
+ kthread+0x3b0/0x770
+ ret_from_fork+0x30/0x70
+ ret_from_fork_asm+0x1a/0x30
+
+ Freed by task 147091:
+ kasan_save_stack+0x2c/0x50
+ kasan_save_track+0x10/0x30
+ kasan_save_free_info+0x37/0x60
+ __kasan_slab_free+0x4b/0x70
+ kfree+0x13a/0x4b0
+ dealloc_work_entries+0x125/0x1f0 [iw_cm]
+ iwcm_deref_id+0x6f/0xa0 [iw_cm]
+ cm_work_handler+0x136/0x1ba0 [iw_cm]
+ process_one_work+0x84f/0x1460
+ worker_thread+0x5ef/0xfd0
+ kthread+0x3b0/0x770
+ ret_from_fork+0x30/0x70
+ ret_from_fork_asm+0x1a/0x30
+
+ Last potentially related work creation:
+ kasan_save_stack+0x2c/0x50
+ kasan_record_aux_stack+0xa3/0xb0
+ __queue_work+0x2ff/0x1390
+ queue_work_on+0x67/0xc0
+ cm_event_handler+0x46a/0x820 [iw_cm]
+ siw_cm_upcall+0x330/0x650 [siw]
+ siw_cm_work_handler+0x6b9/0x2b20 [siw]
+ process_one_work+0x84f/0x1460
+ worker_thread+0x5ef/0xfd0
+ kthread+0x3b0/0x770
+ ret_from_fork+0x30/0x70
+ ret_from_fork_asm+0x1a/0x30
+
+This BUG is reproducible by repeating the blktests test case nvme/061
+for the rdma transport and the siw driver.
+
+To avoid the use-after-free of cm_id_private work objects, ensure that
+the last reference to the cm_id is decremented not in the event handler
+works, but in the cm_id destruction context. For that purpose, move
+iwcm_deref_id() call from destroy_cm_id() to the callers of
+destroy_cm_id(). In iw_destroy_cm_id(), call iwcm_deref_id() after
+flushing the pending works.
+
+During the fix work, I noticed that iw_destroy_cm_id() is called from
+cm_work_handler() and process_event() context. However, the comment of
+iw_destroy_cm_id() notes that the function "cannot be called by the
+event thread". Drop the false comment.
+
+Closes: https://lore.kernel.org/linux-rdma/r5676e754sv35aq7cdsqrlnvyhiq5zktteaurl7vmfih35efko@z6lay7uypy3c/
+Fixes: 59c68ac31e15 ("iw_cm: free cm_id resources on the last deref")
+Cc: stable@vger.kernel.org
+Signed-off-by: Shin'ichiro Kawasaki <shinichiro.kawasaki@wdc.com>
+Link: https://patch.msgid.link/20250510101036.1756439-1-shinichiro.kawasaki@wdc.com
+Reviewed-by: Zhu Yanjun <yanjun.zhu@linux.dev>
+Signed-off-by: Leon Romanovsky <leon@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/infiniband/core/iwcm.c | 29 +++++++++++++++--------------
+ 1 file changed, 15 insertions(+), 14 deletions(-)
+
+--- a/drivers/infiniband/core/iwcm.c
++++ b/drivers/infiniband/core/iwcm.c
+@@ -367,12 +367,9 @@ EXPORT_SYMBOL(iw_cm_disconnect);
+ /*
+ * CM_ID <-- DESTROYING
+ *
+- * Clean up all resources associated with the connection and release
+- * the initial reference taken by iw_create_cm_id.
+- *
+- * Returns true if and only if the last cm_id_priv reference has been dropped.
++ * Clean up all resources associated with the connection.
+ */
+-static bool destroy_cm_id(struct iw_cm_id *cm_id)
++static void destroy_cm_id(struct iw_cm_id *cm_id)
+ {
+ struct iwcm_id_private *cm_id_priv;
+ struct ib_qp *qp;
+@@ -441,20 +438,22 @@ static bool destroy_cm_id(struct iw_cm_i
+ iwpm_remove_mapinfo(&cm_id->local_addr, &cm_id->m_local_addr);
+ iwpm_remove_mapping(&cm_id->local_addr, RDMA_NL_IWCM);
+ }
+-
+- return iwcm_deref_id(cm_id_priv);
+ }
+
+ /*
+- * This function is only called by the application thread and cannot
+- * be called by the event thread. The function will wait for all
+- * references to be released on the cm_id and then kfree the cm_id
+- * object.
++ * Destroy cm_id. If the cm_id still has other references, wait for all
++ * references to be released on the cm_id and then release the initial
++ * reference taken by iw_create_cm_id.
+ */
+ void iw_destroy_cm_id(struct iw_cm_id *cm_id)
+ {
+- if (!destroy_cm_id(cm_id))
++ struct iwcm_id_private *cm_id_priv;
++
++ cm_id_priv = container_of(cm_id, struct iwcm_id_private, id);
++ destroy_cm_id(cm_id);
++ if (refcount_read(&cm_id_priv->refcount) > 1)
+ flush_workqueue(iwcm_wq);
++ iwcm_deref_id(cm_id_priv);
+ }
+ EXPORT_SYMBOL(iw_destroy_cm_id);
+
+@@ -1037,8 +1036,10 @@ static void cm_work_handler(struct work_
+
+ if (!test_bit(IWCM_F_DROP_EVENTS, &cm_id_priv->flags)) {
+ ret = process_event(cm_id_priv, &levent);
+- if (ret)
+- WARN_ON_ONCE(destroy_cm_id(&cm_id_priv->id));
++ if (ret) {
++ destroy_cm_id(&cm_id_priv->id);
++ WARN_ON_ONCE(iwcm_deref_id(cm_id_priv));
++ }
+ } else
+ pr_debug("dropping event %d\n", levent.event);
+ if (iwcm_deref_id(cm_id_priv))
ata-pata_via-force-pio-for-atapi-devices-on-vt6415-vt6330.patch
bus-fsl-mc-do-not-add-a-device-link-for-the-uapi-used-dpmcp-device.patch
bus-fsl-mc-fix-get-set_taildrop-command-ids.patch
+ext4-inline-fix-len-overflow-in-ext4_prepare_inline_data.patch
+ext4-fix-calculation-of-credits-for-extent-tree-modification.patch
+ext4-factor-out-ext4_get_maxbytes.patch
+ext4-ensure-i_size-is-smaller-than-maxbytes.patch
+input-ims-pcu-check-record-size-in-ims_pcu_flash_firmware.patch
+input-gpio-keys-fix-possible-concurrent-access-in-gpio_keys_irq_timer.patch
+f2fs-prevent-kernel-warning-due-to-negative-i_nlink-from-corrupted-image.patch
+f2fs-fix-to-do-sanity-check-on-sit_bitmap_size.patch
+nfc-nci-uart-set-tty-disc_data-only-in-success-path.patch
+net-ftgmac100-select-fixed_phy.patch
+edac-altera-use-correct-write-width-with-the-inttest-register.patch
+fbdev-fix-fb_set_var-to-prevent-null-ptr-deref-in-fb_videomode_to_var.patch
+parisc-unaligned-fix-hex-output-to-show-8-hex-chars.patch
+vgacon-add-check-for-vc_origin-address-range-in-vgacon_scroll.patch
+parisc-fix-building-with-gcc-15.patch
+clk-meson-g12a-add-missing-fclk_div2-to-spicc.patch
+ipc-fix-to-protect-ipcs-lookups-using-rcu.patch
+rdma-iwcm-fix-use-after-free-of-work-objects-after-cm_id-destruction.patch
+mm-fix-ratelimit_pages-update-error-in-dirty_ratio_handler.patch
--- /dev/null
+From 864f9963ec6b4b76d104d595ba28110b87158003 Mon Sep 17 00:00:00 2001
+From: GONG Ruiqi <gongruiqi1@huawei.com>
+Date: Sun, 27 Apr 2025 10:53:03 +0800
+Subject: vgacon: Add check for vc_origin address range in vgacon_scroll()
+
+From: GONG Ruiqi <gongruiqi1@huawei.com>
+
+commit 864f9963ec6b4b76d104d595ba28110b87158003 upstream.
+
+Our in-house Syzkaller reported the following BUG (twice), which we
+believed was the same issue with [1]:
+
+==================================================================
+BUG: KASAN: slab-out-of-bounds in vcs_scr_readw+0xc2/0xd0 drivers/tty/vt/vt.c:4740
+Read of size 2 at addr ffff88800f5bef60 by task syz.7.2620/12393
+...
+Call Trace:
+ <TASK>
+ __dump_stack lib/dump_stack.c:88 [inline]
+ dump_stack_lvl+0x72/0xa0 lib/dump_stack.c:106
+ print_address_description.constprop.0+0x6b/0x3d0 mm/kasan/report.c:364
+ print_report+0xba/0x280 mm/kasan/report.c:475
+ kasan_report+0xa9/0xe0 mm/kasan/report.c:588
+ vcs_scr_readw+0xc2/0xd0 drivers/tty/vt/vt.c:4740
+ vcs_write_buf_noattr drivers/tty/vt/vc_screen.c:493 [inline]
+ vcs_write+0x586/0x840 drivers/tty/vt/vc_screen.c:690
+ vfs_write+0x219/0x960 fs/read_write.c:584
+ ksys_write+0x12e/0x260 fs/read_write.c:639
+ do_syscall_x64 arch/x86/entry/common.c:51 [inline]
+ do_syscall_64+0x59/0x110 arch/x86/entry/common.c:81
+ entry_SYSCALL_64_after_hwframe+0x78/0xe2
+ ...
+ </TASK>
+
+Allocated by task 5614:
+ kasan_save_stack+0x20/0x40 mm/kasan/common.c:45
+ kasan_set_track+0x25/0x30 mm/kasan/common.c:52
+ ____kasan_kmalloc mm/kasan/common.c:374 [inline]
+ __kasan_kmalloc+0x8f/0xa0 mm/kasan/common.c:383
+ kasan_kmalloc include/linux/kasan.h:201 [inline]
+ __do_kmalloc_node mm/slab_common.c:1007 [inline]
+ __kmalloc+0x62/0x140 mm/slab_common.c:1020
+ kmalloc include/linux/slab.h:604 [inline]
+ kzalloc include/linux/slab.h:721 [inline]
+ vc_do_resize+0x235/0xf40 drivers/tty/vt/vt.c:1193
+ vgacon_adjust_height+0x2d4/0x350 drivers/video/console/vgacon.c:1007
+ vgacon_font_set+0x1f7/0x240 drivers/video/console/vgacon.c:1031
+ con_font_set drivers/tty/vt/vt.c:4628 [inline]
+ con_font_op+0x4da/0xa20 drivers/tty/vt/vt.c:4675
+ vt_k_ioctl+0xa10/0xb30 drivers/tty/vt/vt_ioctl.c:474
+ vt_ioctl+0x14c/0x1870 drivers/tty/vt/vt_ioctl.c:752
+ tty_ioctl+0x655/0x1510 drivers/tty/tty_io.c:2779
+ vfs_ioctl fs/ioctl.c:51 [inline]
+ __do_sys_ioctl fs/ioctl.c:871 [inline]
+ __se_sys_ioctl+0x12d/0x190 fs/ioctl.c:857
+ do_syscall_x64 arch/x86/entry/common.c:51 [inline]
+ do_syscall_64+0x59/0x110 arch/x86/entry/common.c:81
+ entry_SYSCALL_64_after_hwframe+0x78/0xe2
+
+Last potentially related work creation:
+ kasan_save_stack+0x20/0x40 mm/kasan/common.c:45
+ __kasan_record_aux_stack+0x94/0xa0 mm/kasan/generic.c:492
+ __call_rcu_common.constprop.0+0xc3/0xa10 kernel/rcu/tree.c:2713
+ netlink_release+0x620/0xc20 net/netlink/af_netlink.c:802
+ __sock_release+0xb5/0x270 net/socket.c:663
+ sock_close+0x1e/0x30 net/socket.c:1425
+ __fput+0x408/0xab0 fs/file_table.c:384
+ __fput_sync+0x4c/0x60 fs/file_table.c:465
+ __do_sys_close fs/open.c:1580 [inline]
+ __se_sys_close+0x68/0xd0 fs/open.c:1565
+ do_syscall_x64 arch/x86/entry/common.c:51 [inline]
+ do_syscall_64+0x59/0x110 arch/x86/entry/common.c:81
+ entry_SYSCALL_64_after_hwframe+0x78/0xe2
+
+Second to last potentially related work creation:
+ kasan_save_stack+0x20/0x40 mm/kasan/common.c:45
+ __kasan_record_aux_stack+0x94/0xa0 mm/kasan/generic.c:492
+ __call_rcu_common.constprop.0+0xc3/0xa10 kernel/rcu/tree.c:2713
+ netlink_release+0x620/0xc20 net/netlink/af_netlink.c:802
+ __sock_release+0xb5/0x270 net/socket.c:663
+ sock_close+0x1e/0x30 net/socket.c:1425
+ __fput+0x408/0xab0 fs/file_table.c:384
+ task_work_run+0x154/0x240 kernel/task_work.c:239
+ exit_task_work include/linux/task_work.h:45 [inline]
+ do_exit+0x8e5/0x1320 kernel/exit.c:874
+ do_group_exit+0xcd/0x280 kernel/exit.c:1023
+ get_signal+0x1675/0x1850 kernel/signal.c:2905
+ arch_do_signal_or_restart+0x80/0x3b0 arch/x86/kernel/signal.c:310
+ exit_to_user_mode_loop kernel/entry/common.c:111 [inline]
+ exit_to_user_mode_prepare include/linux/entry-common.h:328 [inline]
+ __syscall_exit_to_user_mode_work kernel/entry/common.c:207 [inline]
+ syscall_exit_to_user_mode+0x1b3/0x1e0 kernel/entry/common.c:218
+ do_syscall_64+0x66/0x110 arch/x86/entry/common.c:87
+ entry_SYSCALL_64_after_hwframe+0x78/0xe2
+
+The buggy address belongs to the object at ffff88800f5be000
+ which belongs to the cache kmalloc-2k of size 2048
+The buggy address is located 2656 bytes to the right of
+ allocated 1280-byte region [ffff88800f5be000, ffff88800f5be500)
+
+...
+
+Memory state around the buggy address:
+ ffff88800f5bee00: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
+ ffff88800f5bee80: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
+>ffff88800f5bef00: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
+ ^
+ ffff88800f5bef80: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
+ ffff88800f5bf000: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
+==================================================================
+
+By analyzing the vmcore, we found that vc->vc_origin was somehow placed
+one line prior to vc->vc_screenbuf when vc was in KD_TEXT mode, and
+further writings to /dev/vcs caused out-of-bounds reads (and writes
+right after) in vcs_write_buf_noattr().
+
+Our further experiments show that in most cases, vc->vc_origin equals to
+vga_vram_base when the console is in KD_TEXT mode, and it's around
+vc->vc_screenbuf for the KD_GRAPHICS mode. But via triggerring a
+TIOCL_SETVESABLANK ioctl beforehand, we can make vc->vc_origin be around
+vc->vc_screenbuf while the console is in KD_TEXT mode, and then by
+writing the special 'ESC M' control sequence to the tty certain times
+(depends on the value of `vc->state.y - vc->vc_top`), we can eventually
+move vc->vc_origin prior to vc->vc_screenbuf. Here's the PoC, tested on
+QEMU:
+
+```
+int main() {
+ const int RI_NUM = 10; // should be greater than `vc->state.y - vc->vc_top`
+ int tty_fd, vcs_fd;
+ const char *tty_path = "/dev/tty0";
+ const char *vcs_path = "/dev/vcs";
+ const char escape_seq[] = "\x1bM"; // ESC + M
+ const char trigger_seq[] = "Let's trigger an OOB write.";
+ struct vt_sizes vt_size = { 70, 2 };
+ int blank = TIOCL_BLANKSCREEN;
+
+ tty_fd = open(tty_path, O_RDWR);
+
+ char vesa_mode[] = { TIOCL_SETVESABLANK, 1 };
+ ioctl(tty_fd, TIOCLINUX, vesa_mode);
+
+ ioctl(tty_fd, TIOCLINUX, &blank);
+ ioctl(tty_fd, VT_RESIZE, &vt_size);
+
+ for (int i = 0; i < RI_NUM; ++i)
+ write(tty_fd, escape_seq, sizeof(escape_seq) - 1);
+
+ vcs_fd = open(vcs_path, O_RDWR);
+ write(vcs_fd, trigger_seq, sizeof(trigger_seq));
+
+ close(vcs_fd);
+ close(tty_fd);
+ return 0;
+}
+```
+
+To solve this problem, add an address range validation check in
+vgacon_scroll(), ensuring vc->vc_origin never precedes vc_screenbuf.
+
+Reported-by: syzbot+9c09fda97a1a65ea859b@syzkaller.appspotmail.com
+Closes: https://syzkaller.appspot.com/bug?extid=9c09fda97a1a65ea859b [1]
+Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
+Cc: stable@vger.kernel.org
+Co-developed-by: Yi Yang <yiyang13@huawei.com>
+Signed-off-by: Yi Yang <yiyang13@huawei.com>
+Signed-off-by: GONG Ruiqi <gongruiqi1@huawei.com>
+Signed-off-by: Helge Deller <deller@gmx.de>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/video/console/vgacon.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/drivers/video/console/vgacon.c
++++ b/drivers/video/console/vgacon.c
+@@ -1157,7 +1157,7 @@ static bool vgacon_scroll(struct vc_data
+ c->vc_screenbuf_size - delta);
+ c->vc_origin = vga_vram_end - c->vc_screenbuf_size;
+ vga_rolled_over = 0;
+- } else
++ } else if (oldo - delta >= (unsigned long)c->vc_screenbuf)
+ c->vc_origin -= delta;
+ c->vc_scr_end = c->vc_origin + c->vc_screenbuf_size;
+ scr_memsetw((u16 *) (c->vc_origin), c->vc_video_erase_char,
projects / thirdparty / kernel / stable-queue.git / commitdiff
