--- /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
+@@ -1804,9 +1804,9 @@ static ssize_t altr_edac_a10_device_trig
+
+ 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();
+@@ -1836,7 +1836,7 @@ static ssize_t altr_edac_a10_device_trig
+
+ 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 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
+@@ -2592,18 +2592,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
+@@ -389,7 +389,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 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
+@@ -536,6 +536,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
+@@ -1057,8 +1057,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 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
+@@ -417,8 +417,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
+@@ -562,8 +562,8 @@ int dirty_ratio_handler(struct ctl_table
+
+ 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 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
+@@ -131,22 +131,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
+@@ -21,6 +21,7 @@ KBUILD_CFLAGS += -fno-PIE -mno-space-reg
+ ifndef CONFIG_64BIT
+ KBUILD_CFLAGS += -mfast-indirect-calls
+ endif
++KBUILD_CFLAGS += -std=gnu11
+
+ OBJECTS += $(obj)/head.o $(obj)/real2.o $(obj)/firmware.o $(obj)/misc.o $(obj)/piggy.o
+
arm-9447-1-arm-memremap-fix-arch_memremap_can_ram_remap.patch
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
+ext4-inline-fix-len-overflow-in-ext4_prepare_inline_data.patch
+ext4-fix-calculation-of-credits-for-extent-tree-modification.patch
+input-ims-pcu-check-record-size-in-ims_pcu_flash_firmware.patch
+f2fs-prevent-kernel-warning-due-to-negative-i_nlink-from-corrupted-image.patch
+nfc-nci-uart-set-tty-disc_data-only-in-success-path.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
+vgacon-add-check-for-vc_origin-address-range-in-vgacon_scroll.patch
+parisc-fix-building-with-gcc-15.patch
+ipc-fix-to-protect-ipcs-lookups-using-rcu.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
+@@ -1198,7 +1198,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
