diff options
Diffstat (limited to 'meta-openbmc-mods/meta-common/recipes-kernel')
58 files changed, 4562 insertions, 0 deletions
diff --git a/meta-openbmc-mods/meta-common/recipes-kernel/linux/linux-aspeed/CVE-2021-33631.patch b/meta-openbmc-mods/meta-common/recipes-kernel/linux/linux-aspeed/CVE-2021-33631.patch new file mode 100644 index 000000000..4c12c53a1 --- /dev/null +++ b/meta-openbmc-mods/meta-common/recipes-kernel/linux/linux-aspeed/CVE-2021-33631.patch @@ -0,0 +1,107 @@ +From 5c099c4fdc438014d5893629e70a8ba934433ee8 Mon Sep 17 00:00:00 2001 +From: Ye Bin <yebin10@huawei.com> +Date: Tue, 6 Dec 2022 22:41:34 +0800 +Subject: ext4: fix kernel BUG in 'ext4_write_inline_data_end()' + +Syzbot report follow issue: +------------[ cut here ]------------ +kernel BUG at fs/ext4/inline.c:227! +invalid opcode: 0000 [#1] PREEMPT SMP KASAN +CPU: 1 PID: 3629 Comm: syz-executor212 Not tainted 6.1.0-rc5-syzkaller-00018-g59d0d52c30d4 #0 +Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 10/26/2022 +RIP: 0010:ext4_write_inline_data+0x344/0x3e0 fs/ext4/inline.c:227 +RSP: 0018:ffffc90003b3f368 EFLAGS: 00010293 +RAX: 0000000000000000 RBX: ffff8880704e16c0 RCX: 0000000000000000 +RDX: ffff888021763a80 RSI: ffffffff821e31a4 RDI: 0000000000000006 +RBP: 000000000006818e R08: 0000000000000006 R09: 0000000000068199 +R10: 0000000000000079 R11: 0000000000000000 R12: 000000000000000b +R13: 0000000000068199 R14: ffffc90003b3f408 R15: ffff8880704e1c82 +FS: 000055555723e3c0(0000) GS:ffff8880b9b00000(0000) knlGS:0000000000000000 +CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 +CR2: 00007fffe8ac9080 CR3: 0000000079f81000 CR4: 0000000000350ee0 +Call Trace: + <TASK> + ext4_write_inline_data_end+0x2a3/0x12f0 fs/ext4/inline.c:768 + ext4_write_end+0x242/0xdd0 fs/ext4/inode.c:1313 + ext4_da_write_end+0x3ed/0xa30 fs/ext4/inode.c:3063 + generic_perform_write+0x316/0x570 mm/filemap.c:3764 + ext4_buffered_write_iter+0x15b/0x460 fs/ext4/file.c:285 + ext4_file_write_iter+0x8bc/0x16e0 fs/ext4/file.c:700 + call_write_iter include/linux/fs.h:2191 [inline] + do_iter_readv_writev+0x20b/0x3b0 fs/read_write.c:735 + do_iter_write+0x182/0x700 fs/read_write.c:861 + vfs_iter_write+0x74/0xa0 fs/read_write.c:902 + iter_file_splice_write+0x745/0xc90 fs/splice.c:686 + do_splice_from fs/splice.c:764 [inline] + direct_splice_actor+0x114/0x180 fs/splice.c:931 + splice_direct_to_actor+0x335/0x8a0 fs/splice.c:886 + do_splice_direct+0x1ab/0x280 fs/splice.c:974 + do_sendfile+0xb19/0x1270 fs/read_write.c:1255 + __do_sys_sendfile64 fs/read_write.c:1323 [inline] + __se_sys_sendfile64 fs/read_write.c:1309 [inline] + __x64_sys_sendfile64+0x1d0/0x210 fs/read_write.c:1309 + do_syscall_x64 arch/x86/entry/common.c:50 [inline] + do_syscall_64+0x39/0xb0 arch/x86/entry/common.c:80 + entry_SYSCALL_64_after_hwframe+0x63/0xcd +---[ end trace 0000000000000000 ]--- + +Above issue may happens as follows: +ext4_da_write_begin + ext4_da_write_inline_data_begin + ext4_da_convert_inline_data_to_extent + ext4_clear_inode_state(inode, EXT4_STATE_MAY_INLINE_DATA); +ext4_da_write_end + +ext4_run_li_request + ext4_mb_prefetch + ext4_read_block_bitmap_nowait + ext4_validate_block_bitmap + ext4_mark_group_bitmap_corrupted(sb, block_group, EXT4_GROUP_INFO_BBITMAP_CORRUPT) + percpu_counter_sub(&sbi->s_freeclusters_counter,grp->bb_free); + -> sbi->s_freeclusters_counter become zero +ext4_da_write_begin + if (ext4_nonda_switch(inode->i_sb)) -> As freeclusters_counter is zero will return true + *fsdata = (void *)FALL_BACK_TO_NONDELALLOC; + ext4_write_begin +ext4_da_write_end + if (write_mode == FALL_BACK_TO_NONDELALLOC) + ext4_write_end + if (inline_data) + ext4_write_inline_data_end + ext4_write_inline_data + BUG_ON(pos + len > EXT4_I(inode)->i_inline_size); + -> As inode is already convert to extent, so 'pos + len' > inline_size + -> then trigger BUG. + +To solve this issue, instead of checking ext4_has_inline_data() which +is only cleared after data has been written back, check the +EXT4_STATE_MAY_INLINE_DATA flag in ext4_write_end(). + +Fixes: f19d5870cbf7 ("ext4: add normal write support for inline data") +Reported-by: syzbot+4faa160fa96bfba639f8@syzkaller.appspotmail.com +Reported-by: Jun Nie <jun.nie@linaro.org> +Signed-off-by: Ye Bin <yebin10@huawei.com> +Link: https://lore.kernel.org/r/20221206144134.1919987-1-yebin@huaweicloud.com +Signed-off-by: Theodore Ts'o <tytso@mit.edu> +Cc: stable@kernel.org +--- + fs/ext4/inode.c | 3 ++- + 1 file changed, 2 insertions(+), 1 deletion(-) + +diff --git a/fs/ext4/inode.c b/fs/ext4/inode.c +index 181bc161b1ac3d..a0f4d4197a0b71 100644 +--- a/fs/ext4/inode.c ++++ b/fs/ext4/inode.c +@@ -1315,7 +1315,8 @@ static int ext4_write_end(struct file *file, + + trace_ext4_write_end(inode, pos, len, copied); + +- if (ext4_has_inline_data(inode)) ++ if (ext4_has_inline_data(inode) && ++ ext4_test_inode_state(inode, EXT4_STATE_MAY_INLINE_DATA)) + return ext4_write_inline_data_end(inode, pos, len, copied, page); + + copied = block_write_end(file, mapping, pos, len, copied, page, fsdata); +-- +cgit 1.2.3-korg + diff --git a/meta-openbmc-mods/meta-common/recipes-kernel/linux/linux-aspeed/CVE-2021-46923.patch b/meta-openbmc-mods/meta-common/recipes-kernel/linux/linux-aspeed/CVE-2021-46923.patch new file mode 100644 index 000000000..eb2b5cc93 --- /dev/null +++ b/meta-openbmc-mods/meta-common/recipes-kernel/linux/linux-aspeed/CVE-2021-46923.patch @@ -0,0 +1,44 @@ +From 012e332286e2bb9f6ac77d195f17e74b2963d663 Mon Sep 17 00:00:00 2001 +From: Christian Brauner <christian.brauner@ubuntu.com> +Date: Thu, 30 Dec 2021 20:23:09 +0100 +Subject: fs/mount_setattr: always cleanup mount_kattr + +Make sure that finish_mount_kattr() is called after mount_kattr was +succesfully built in both the success and failure case to prevent +leaking any references we took when we built it. We returned early if +path lookup failed thereby risking to leak an additional reference we +took when building mount_kattr when an idmapped mount was requested. + +Cc: linux-fsdevel@vger.kernel.org +Cc: stable@vger.kernel.org +Fixes: 9caccd41541a ("fs: introduce MOUNT_ATTR_IDMAP") +Signed-off-by: Christian Brauner <christian.brauner@ubuntu.com> +Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> +--- + fs/namespace.c | 9 ++++----- + 1 file changed, 4 insertions(+), 5 deletions(-) + +diff --git a/fs/namespace.c b/fs/namespace.c +index 659a8f39c61afb..b696543adab848 100644 +--- a/fs/namespace.c ++++ b/fs/namespace.c +@@ -4263,12 +4263,11 @@ SYSCALL_DEFINE5(mount_setattr, int, dfd, const char __user *, path, + return err; + + err = user_path_at(dfd, path, kattr.lookup_flags, &target); +- if (err) +- return err; +- +- err = do_mount_setattr(&target, &kattr); ++ if (!err) { ++ err = do_mount_setattr(&target, &kattr); ++ path_put(&target); ++ } + finish_mount_kattr(&kattr); +- path_put(&target); + return err; + } + +-- +cgit 1.2.3-korg + diff --git a/meta-openbmc-mods/meta-common/recipes-kernel/linux/linux-aspeed/CVE-2021-46933.patch b/meta-openbmc-mods/meta-common/recipes-kernel/linux/linux-aspeed/CVE-2021-46933.patch new file mode 100644 index 000000000..74c9cac10 --- /dev/null +++ b/meta-openbmc-mods/meta-common/recipes-kernel/linux/linux-aspeed/CVE-2021-46933.patch @@ -0,0 +1,118 @@ +From 1c4ace3e6b8575745c50dca9e76e0021e697d645 Mon Sep 17 00:00:00 2001 +From: Vincent Pelletier <plr.vincent@gmail.com> +Date: Sat, 18 Dec 2021 02:18:40 +0000 +Subject: usb: gadget: f_fs: Clear ffs_eventfd in ffs_data_clear. + +commit b1e0887379422975f237d43d8839b751a6bcf154 upstream. + +ffs_data_clear is indirectly called from both ffs_fs_kill_sb and +ffs_ep0_release, so it ends up being called twice when userland closes ep0 +and then unmounts f_fs. +If userland provided an eventfd along with function's USB descriptors, it +ends up calling eventfd_ctx_put as many times, causing a refcount +underflow. +NULL-ify ffs_eventfd to prevent these extraneous eventfd_ctx_put calls. + +Also, set epfiles to NULL right after de-allocating it, for readability. + +For completeness, ffs_data_clear actually ends up being called thrice, the +last call being before the whole ffs structure gets freed, so when this +specific sequence happens there is a second underflow happening (but not +being reported): + +/sys/kernel/debug/tracing# modprobe usb_f_fs +/sys/kernel/debug/tracing# echo ffs_data_clear > set_ftrace_filter +/sys/kernel/debug/tracing# echo function > current_tracer +/sys/kernel/debug/tracing# echo 1 > tracing_on +(setup gadget, run and kill function userland process, teardown gadget) +/sys/kernel/debug/tracing# echo 0 > tracing_on +/sys/kernel/debug/tracing# cat trace + smartcard-openp-436 [000] ..... 1946.208786: ffs_data_clear <-ffs_data_closed + smartcard-openp-431 [000] ..... 1946.279147: ffs_data_clear <-ffs_data_closed + smartcard-openp-431 [000] .n... 1946.905512: ffs_data_clear <-ffs_data_put + +Warning output corresponding to above trace: +[ 1946.284139] WARNING: CPU: 0 PID: 431 at lib/refcount.c:28 refcount_warn_saturate+0x110/0x15c +[ 1946.293094] refcount_t: underflow; use-after-free. +[ 1946.298164] Modules linked in: usb_f_ncm(E) u_ether(E) usb_f_fs(E) hci_uart(E) btqca(E) btrtl(E) btbcm(E) btintel(E) bluetooth(E) nls_ascii(E) nls_cp437(E) vfat(E) fat(E) bcm2835_v4l2(CE) bcm2835_mmal_vchiq(CE) videobuf2_vmalloc(E) videobuf2_memops(E) sha512_generic(E) videobuf2_v4l2(E) sha512_arm(E) videobuf2_common(E) videodev(E) cpufreq_dt(E) snd_bcm2835(CE) brcmfmac(E) mc(E) vc4(E) ctr(E) brcmutil(E) snd_soc_core(E) snd_pcm_dmaengine(E) drbg(E) snd_pcm(E) snd_timer(E) snd(E) soundcore(E) drm_kms_helper(E) cec(E) ansi_cprng(E) rc_core(E) syscopyarea(E) raspberrypi_cpufreq(E) sysfillrect(E) sysimgblt(E) cfg80211(E) max17040_battery(OE) raspberrypi_hwmon(E) fb_sys_fops(E) regmap_i2c(E) ecdh_generic(E) rfkill(E) ecc(E) bcm2835_rng(E) rng_core(E) vchiq(CE) leds_gpio(E) libcomposite(E) fuse(E) configfs(E) ip_tables(E) x_tables(E) autofs4(E) ext4(E) crc16(E) mbcache(E) jbd2(E) crc32c_generic(E) sdhci_iproc(E) sdhci_pltfm(E) sdhci(E) +[ 1946.399633] CPU: 0 PID: 431 Comm: smartcard-openp Tainted: G C OE 5.15.0-1-rpi #1 Debian 5.15.3-1 +[ 1946.417950] Hardware name: BCM2835 +[ 1946.425442] Backtrace: +[ 1946.432048] [<c08d60a0>] (dump_backtrace) from [<c08d62ec>] (show_stack+0x20/0x24) +[ 1946.448226] r7:00000009 r6:0000001c r5:c04a948c r4:c0a64e2c +[ 1946.458412] [<c08d62cc>] (show_stack) from [<c08d9ae0>] (dump_stack+0x28/0x30) +[ 1946.470380] [<c08d9ab8>] (dump_stack) from [<c0123500>] (__warn+0xe8/0x154) +[ 1946.482067] r5:c04a948c r4:c0a71dc8 +[ 1946.490184] [<c0123418>] (__warn) from [<c08d6948>] (warn_slowpath_fmt+0xa0/0xe4) +[ 1946.506758] r7:00000009 r6:0000001c r5:c0a71dc8 r4:c0a71e04 +[ 1946.517070] [<c08d68ac>] (warn_slowpath_fmt) from [<c04a948c>] (refcount_warn_saturate+0x110/0x15c) +[ 1946.535309] r8:c0100224 r7:c0dfcb84 r6:ffffffff r5:c3b84c00 r4:c24a17c0 +[ 1946.546708] [<c04a937c>] (refcount_warn_saturate) from [<c0380134>] (eventfd_ctx_put+0x48/0x74) +[ 1946.564476] [<c03800ec>] (eventfd_ctx_put) from [<bf5464e8>] (ffs_data_clear+0xd0/0x118 [usb_f_fs]) +[ 1946.582664] r5:c3b84c00 r4:c2695b00 +[ 1946.590668] [<bf546418>] (ffs_data_clear [usb_f_fs]) from [<bf547cc0>] (ffs_data_closed+0x9c/0x150 [usb_f_fs]) +[ 1946.609608] r5:bf54d014 r4:c2695b00 +[ 1946.617522] [<bf547c24>] (ffs_data_closed [usb_f_fs]) from [<bf547da0>] (ffs_fs_kill_sb+0x2c/0x30 [usb_f_fs]) +[ 1946.636217] r7:c0dfcb84 r6:c3a12260 r5:bf54d014 r4:c229f000 +[ 1946.646273] [<bf547d74>] (ffs_fs_kill_sb [usb_f_fs]) from [<c0326d50>] (deactivate_locked_super+0x54/0x9c) +[ 1946.664893] r5:bf54d014 r4:c229f000 +[ 1946.672921] [<c0326cfc>] (deactivate_locked_super) from [<c0326df8>] (deactivate_super+0x60/0x64) +[ 1946.690722] r5:c2a09000 r4:c229f000 +[ 1946.698706] [<c0326d98>] (deactivate_super) from [<c0349a28>] (cleanup_mnt+0xe4/0x14c) +[ 1946.715553] r5:c2a09000 r4:00000000 +[ 1946.723528] [<c0349944>] (cleanup_mnt) from [<c0349b08>] (__cleanup_mnt+0x1c/0x20) +[ 1946.739922] r7:c0dfcb84 r6:c3a12260 r5:c3a126fc r4:00000000 +[ 1946.750088] [<c0349aec>] (__cleanup_mnt) from [<c0143d10>] (task_work_run+0x84/0xb8) +[ 1946.766602] [<c0143c8c>] (task_work_run) from [<c010bdc8>] (do_work_pending+0x470/0x56c) +[ 1946.783540] r7:5ac3c35a r6:c0d0424c r5:c200bfb0 r4:c200a000 +[ 1946.793614] [<c010b958>] (do_work_pending) from [<c01000c0>] (slow_work_pending+0xc/0x20) +[ 1946.810553] Exception stack(0xc200bfb0 to 0xc200bff8) +[ 1946.820129] bfa0: 00000000 00000000 000000aa b5e21430 +[ 1946.837104] bfc0: bef867a0 00000001 bef86840 00000034 bef86838 bef86790 bef86794 bef867a0 +[ 1946.854125] bfe0: 00000000 bef86798 b67b7a1c b6d626a4 60000010 b5a23760 +[ 1946.865335] r10:00000000 r9:c200a000 r8:c0100224 r7:00000034 r6:bef86840 r5:00000001 +[ 1946.881914] r4:bef867a0 +[ 1946.888793] ---[ end trace 7387f2a9725b28d0 ]--- + +Fixes: 5e33f6fdf735 ("usb: gadget: ffs: add eventfd notification about ffs events") +Cc: stable <stable@vger.kernel.org> +Signed-off-by: Vincent Pelletier <plr.vincent@gmail.com> +Link: https://lore.kernel.org/r/f79eeea29f3f98de6782a064ec0f7351ad2f598f.1639793920.git.plr.vincent@gmail.com +Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> +--- + drivers/usb/gadget/function/f_fs.c | 9 ++++++--- + 1 file changed, 6 insertions(+), 3 deletions(-) + +diff --git a/drivers/usb/gadget/function/f_fs.c b/drivers/usb/gadget/function/f_fs.c +index 725e35167837eb..cbb7947f366f93 100644 +--- a/drivers/usb/gadget/function/f_fs.c ++++ b/drivers/usb/gadget/function/f_fs.c +@@ -1772,11 +1772,15 @@ static void ffs_data_clear(struct ffs_data *ffs) + + BUG_ON(ffs->gadget); + +- if (ffs->epfiles) ++ if (ffs->epfiles) { + ffs_epfiles_destroy(ffs->epfiles, ffs->eps_count); ++ ffs->epfiles = NULL; ++ } + +- if (ffs->ffs_eventfd) ++ if (ffs->ffs_eventfd) { + eventfd_ctx_put(ffs->ffs_eventfd); ++ ffs->ffs_eventfd = NULL; ++ } + + kfree(ffs->raw_descs_data); + kfree(ffs->raw_strings); +@@ -1789,7 +1793,6 @@ static void ffs_data_reset(struct ffs_data *ffs) + + ffs_data_clear(ffs); + +- ffs->epfiles = NULL; + ffs->raw_descs_data = NULL; + ffs->raw_descs = NULL; + ffs->raw_strings = NULL; +-- +cgit 1.2.3-korg + diff --git a/meta-openbmc-mods/meta-common/recipes-kernel/linux/linux-aspeed/CVE-2021-46934.patch b/meta-openbmc-mods/meta-common/recipes-kernel/linux/linux-aspeed/CVE-2021-46934.patch new file mode 100644 index 000000000..a8aa64856 --- /dev/null +++ b/meta-openbmc-mods/meta-common/recipes-kernel/linux/linux-aspeed/CVE-2021-46934.patch @@ -0,0 +1,38 @@ +From 407c8708fb1bf2d4afc5337ef50635cf540c364b Mon Sep 17 00:00:00 2001 +From: Pavel Skripkin <paskripkin@gmail.com> +Date: Fri, 31 Dec 2021 01:47:50 +0300 +Subject: i2c: validate user data in compat ioctl + +[ Upstream commit bb436283e25aaf1533ce061605d23a9564447bdf ] + +Wrong user data may cause warning in i2c_transfer(), ex: zero msgs. +Userspace should not be able to trigger warnings, so this patch adds +validation checks for user data in compact ioctl to prevent reported +warnings + +Reported-and-tested-by: syzbot+e417648b303855b91d8a@syzkaller.appspotmail.com +Fixes: 7d5cb45655f2 ("i2c compat ioctls: move to ->compat_ioctl()") +Signed-off-by: Pavel Skripkin <paskripkin@gmail.com> +Signed-off-by: Wolfram Sang <wsa@kernel.org> +Signed-off-by: Sasha Levin <sashal@kernel.org> +--- + drivers/i2c/i2c-dev.c | 3 +++ + 1 file changed, 3 insertions(+) + +diff --git a/drivers/i2c/i2c-dev.c b/drivers/i2c/i2c-dev.c +index 57aece80984166..140dd074fdee5a 100644 +--- a/drivers/i2c/i2c-dev.c ++++ b/drivers/i2c/i2c-dev.c +@@ -544,6 +544,9 @@ static long compat_i2cdev_ioctl(struct file *file, unsigned int cmd, unsigned lo + sizeof(rdwr_arg))) + return -EFAULT; + ++ if (!rdwr_arg.msgs || rdwr_arg.nmsgs == 0) ++ return -EINVAL; ++ + if (rdwr_arg.nmsgs > I2C_RDWR_IOCTL_MAX_MSGS) + return -EINVAL; + +-- +cgit 1.2.3-korg + diff --git a/meta-openbmc-mods/meta-common/recipes-kernel/linux/linux-aspeed/CVE-2021-46936.patch b/meta-openbmc-mods/meta-common/recipes-kernel/linux/linux-aspeed/CVE-2021-46936.patch new file mode 100644 index 000000000..9a3605809 --- /dev/null +++ b/meta-openbmc-mods/meta-common/recipes-kernel/linux/linux-aspeed/CVE-2021-46936.patch @@ -0,0 +1,88 @@ +From 08eacbd141e2495d2fcdde84358a06c4f95cbb13 Mon Sep 17 00:00:00 2001 +From: Muchun Song <songmuchun@bytedance.com> +Date: Tue, 28 Dec 2021 18:41:45 +0800 +Subject: net: fix use-after-free in tw_timer_handler + +commit e22e45fc9e41bf9fcc1e92cfb78eb92786728ef0 upstream. + +A real world panic issue was found as follow in Linux 5.4. + + BUG: unable to handle page fault for address: ffffde49a863de28 + PGD 7e6fe62067 P4D 7e6fe62067 PUD 7e6fe63067 PMD f51e064067 PTE 0 + RIP: 0010:tw_timer_handler+0x20/0x40 + Call Trace: + <IRQ> + call_timer_fn+0x2b/0x120 + run_timer_softirq+0x1ef/0x450 + __do_softirq+0x10d/0x2b8 + irq_exit+0xc7/0xd0 + smp_apic_timer_interrupt+0x68/0x120 + apic_timer_interrupt+0xf/0x20 + +This issue was also reported since 2017 in the thread [1], +unfortunately, the issue was still can be reproduced after fixing +DCCP. + +The ipv4_mib_exit_net is called before tcp_sk_exit_batch when a net +namespace is destroyed since tcp_sk_ops is registered befrore +ipv4_mib_ops, which means tcp_sk_ops is in the front of ipv4_mib_ops +in the list of pernet_list. There will be a use-after-free on +net->mib.net_statistics in tw_timer_handler after ipv4_mib_exit_net +if there are some inflight time-wait timers. + +This bug is not introduced by commit f2bf415cfed7 ("mib: add net to +NET_ADD_STATS_BH") since the net_statistics is a global variable +instead of dynamic allocation and freeing. Actually, commit +61a7e26028b9 ("mib: put net statistics on struct net") introduces +the bug since it put net statistics on struct net and free it when +net namespace is destroyed. + +Moving init_ipv4_mibs() to the front of tcp_init() to fix this bug +and replace pr_crit() with panic() since continuing is meaningless +when init_ipv4_mibs() fails. + +[1] https://groups.google.com/g/syzkaller/c/p1tn-_Kc6l4/m/smuL_FMAAgAJ?pli=1 + +Fixes: 61a7e26028b9 ("mib: put net statistics on struct net") +Signed-off-by: Muchun Song <songmuchun@bytedance.com> +Cc: Cong Wang <cong.wang@bytedance.com> +Cc: Fam Zheng <fam.zheng@bytedance.com> +Cc: <stable@vger.kernel.org> +Link: https://lore.kernel.org/r/20211228104145.9426-1-songmuchun@bytedance.com +Signed-off-by: Jakub Kicinski <kuba@kernel.org> +Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> +--- + net/ipv4/af_inet.c | 10 ++++------ + 1 file changed, 4 insertions(+), 6 deletions(-) + +diff --git a/net/ipv4/af_inet.c b/net/ipv4/af_inet.c +index 3a9422a5873eb4..dcea653a5204ad 100644 +--- a/net/ipv4/af_inet.c ++++ b/net/ipv4/af_inet.c +@@ -2004,6 +2004,10 @@ static int __init inet_init(void) + + ip_init(); + ++ /* Initialise per-cpu ipv4 mibs */ ++ if (init_ipv4_mibs()) ++ panic("%s: Cannot init ipv4 mibs\n", __func__); ++ + /* Setup TCP slab cache for open requests. */ + tcp_init(); + +@@ -2034,12 +2038,6 @@ static int __init inet_init(void) + + if (init_inet_pernet_ops()) + pr_crit("%s: Cannot init ipv4 inet pernet ops\n", __func__); +- /* +- * Initialise per-cpu ipv4 mibs +- */ +- +- if (init_ipv4_mibs()) +- pr_crit("%s: Cannot init ipv4 mibs\n", __func__); + + ipv4_proc_init(); + +-- +cgit 1.2.3-korg + diff --git a/meta-openbmc-mods/meta-common/recipes-kernel/linux/linux-aspeed/CVE-2021-47087.patch b/meta-openbmc-mods/meta-common/recipes-kernel/linux/linux-aspeed/CVE-2021-47087.patch new file mode 100644 index 000000000..a92a8002b --- /dev/null +++ b/meta-openbmc-mods/meta-common/recipes-kernel/linux/linux-aspeed/CVE-2021-47087.patch @@ -0,0 +1,43 @@ +From 806142c805cacd098e61bdc0f72c778a2389fe4a Mon Sep 17 00:00:00 2001 +From: Sumit Garg <sumit.garg@linaro.org> +Date: Thu, 16 Dec 2021 11:17:25 +0530 +Subject: tee: optee: Fix incorrect page free bug + +commit 18549bf4b21c739a9def39f27dcac53e27286ab5 upstream. + +Pointer to the allocated pages (struct page *page) has already +progressed towards the end of allocation. It is incorrect to perform +__free_pages(page, order) using this pointer as we would free any +arbitrary pages. Fix this by stop modifying the page pointer. + +Fixes: ec185dd3ab25 ("optee: Fix memory leak when failing to register shm pages") +Cc: stable@vger.kernel.org +Reported-by: Patrik Lantz <patrik.lantz@axis.com> +Signed-off-by: Sumit Garg <sumit.garg@linaro.org> +Reviewed-by: Tyler Hicks <tyhicks@linux.microsoft.com> +Signed-off-by: Jens Wiklander <jens.wiklander@linaro.org> +Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> +--- + drivers/tee/optee/shm_pool.c | 6 ++---- + 1 file changed, 2 insertions(+), 4 deletions(-) + +diff --git a/drivers/tee/optee/shm_pool.c b/drivers/tee/optee/shm_pool.c +index c41a9a501a6e9d..fa75024f16f7f1 100644 +--- a/drivers/tee/optee/shm_pool.c ++++ b/drivers/tee/optee/shm_pool.c +@@ -41,10 +41,8 @@ static int pool_op_alloc(struct tee_shm_pool_mgr *poolm, + goto err; + } + +- for (i = 0; i < nr_pages; i++) { +- pages[i] = page; +- page++; +- } ++ for (i = 0; i < nr_pages; i++) ++ pages[i] = page + i; + + shm->flags |= TEE_SHM_REGISTER; + rc = optee_shm_register(shm->ctx, shm, pages, nr_pages, +-- +cgit 1.2.3-korg + diff --git a/meta-openbmc-mods/meta-common/recipes-kernel/linux/linux-aspeed/CVE-2022-0847.patch b/meta-openbmc-mods/meta-common/recipes-kernel/linux/linux-aspeed/CVE-2022-0847.patch new file mode 100644 index 000000000..c4be1a8d1 --- /dev/null +++ b/meta-openbmc-mods/meta-common/recipes-kernel/linux/linux-aspeed/CVE-2022-0847.patch @@ -0,0 +1,43 @@ +From 9d2231c5d74e13b2a0546fee6737ee4446017903 Mon Sep 17 00:00:00 2001 +From: Max Kellermann <max.kellermann@ionos.com> +Date: Mon, 21 Feb 2022 11:03:13 +0100 +Subject: lib/iov_iter: initialize "flags" in new pipe_buffer + +The functions copy_page_to_iter_pipe() and push_pipe() can both +allocate a new pipe_buffer, but the "flags" member initializer is +missing. + +Fixes: 241699cd72a8 ("new iov_iter flavour: pipe-backed") +To: Alexander Viro <viro@zeniv.linux.org.uk> +To: linux-fsdevel@vger.kernel.org +To: linux-kernel@vger.kernel.org +Cc: stable@vger.kernel.org +Signed-off-by: Max Kellermann <max.kellermann@ionos.com> +Signed-off-by: Al Viro <viro@zeniv.linux.org.uk> +--- + lib/iov_iter.c | 2 ++ + 1 file changed, 2 insertions(+) + +diff --git a/lib/iov_iter.c b/lib/iov_iter.c +index b0e0acdf96c15..6dd5330f7a995 100644 +--- a/lib/iov_iter.c ++++ b/lib/iov_iter.c +@@ -414,6 +414,7 @@ static size_t copy_page_to_iter_pipe(struct page *page, size_t offset, size_t by + return 0; + + buf->ops = &page_cache_pipe_buf_ops; ++ buf->flags = 0; + get_page(page); + buf->page = page; + buf->offset = offset; +@@ -577,6 +578,7 @@ static size_t push_pipe(struct iov_iter *i, size_t size, + break; + + buf->ops = &default_pipe_buf_ops; ++ buf->flags = 0; + buf->page = page; + buf->offset = 0; + buf->len = min_t(ssize_t, left, PAGE_SIZE); +-- +cgit 1.2.3-korg + diff --git a/meta-openbmc-mods/meta-common/recipes-kernel/linux/linux-aspeed/CVE-2022-40982.patch b/meta-openbmc-mods/meta-common/recipes-kernel/linux/linux-aspeed/CVE-2022-40982.patch new file mode 100644 index 000000000..96f861bcf --- /dev/null +++ b/meta-openbmc-mods/meta-common/recipes-kernel/linux/linux-aspeed/CVE-2022-40982.patch @@ -0,0 +1,77 @@ +From 8974eb588283b7d44a7c91fa09fcbaf380339f3a Mon Sep 17 00:00:00 2001 +From: Daniel Sneddon <daniel.sneddon@linux.intel.com> +Date: Wed, 12 Jul 2023 19:43:11 -0700 +Subject: [PATCH] x86/speculation: Add Gather Data Sampling mitigation + +Gather Data Sampling (GDS) is a hardware vulnerability which allows +unprivileged speculative access to data which was previously stored in +vector registers. + +Intel processors that support AVX2 and AVX512 have gather instructions +that fetch non-contiguous data elements from memory. On vulnerable +hardware, when a gather instruction is transiently executed and +encounters a fault, stale data from architectural or internal vector +registers may get transiently stored to the destination vector +register allowing an attacker to infer the stale data using typical +side channel techniques like cache timing attacks. + +This mitigation is different from many earlier ones for two reasons. +First, it is enabled by default and a bit must be set to *DISABLE* it. +This is the opposite of normal mitigation polarity. This means GDS can +be mitigated simply by updating microcode and leaving the new control +bit alone. + +Second, GDS has a "lock" bit. This lock bit is there because the +mitigation affects the hardware security features KeyLocker and SGX. +It needs to be enabled and *STAY* enabled for these features to be +mitigated against GDS. + +The mitigation is enabled in the microcode by default. Disable it by +setting gather_data_sampling=off or by disabling all mitigations with +mitigations=off. The mitigation status can be checked by reading: + + /sys/devices/system/cpu/vulnerabilities/gather_data_sampling + +Signed-off-by: Daniel Sneddon <daniel.sneddon@linux.intel.com> +Signed-off-by: Dave Hansen <dave.hansen@linux.intel.com> +Acked-by: Josh Poimboeuf <jpoimboe@kernel.org> +--- + drivers/base/cpu.c | 8 ++++++++ + 1 file changed, 8 insertions(+) + +diff --git a/drivers/base/cpu.c b/drivers/base/cpu.c +index 5fc258073bc7..3dd3fe80f8fc 100644 +--- a/drivers/base/cpu.c ++++ b/drivers/base/cpu.c +@@ -564,6 +564,12 @@ ssize_t __weak cpu_show_srbds(struct device *dev, + return sysfs_emit(buf, "Not affected\n"); + } + ++ssize_t __weak cpu_show_gds(struct device *dev, ++ struct device_attribute *attr, char *buf) ++{ ++ return sysfs_emit(buf, "Not affected\n"); ++} ++ + static DEVICE_ATTR(meltdown, 0444, cpu_show_meltdown, NULL); + static DEVICE_ATTR(spectre_v1, 0444, cpu_show_spectre_v1, NULL); + static DEVICE_ATTR(spectre_v2, 0444, cpu_show_spectre_v2, NULL); +@@ -573,6 +579,7 @@ static DEVICE_ATTR(mds, 0444, cpu_show_mds, NULL); + static DEVICE_ATTR(tsx_async_abort, 0444, cpu_show_tsx_async_abort, NULL); + static DEVICE_ATTR(itlb_multihit, 0444, cpu_show_itlb_multihit, NULL); + static DEVICE_ATTR(srbds, 0444, cpu_show_srbds, NULL); ++static DEVICE_ATTR(gather_data_sampling, 0444, cpu_show_gds, NULL); + + static struct attribute *cpu_root_vulnerabilities_attrs[] = { + &dev_attr_meltdown.attr, +@@ -584,6 +591,7 @@ static struct attribute *cpu_root_vulnerabilities_attrs[] = { + &dev_attr_tsx_async_abort.attr, + &dev_attr_itlb_multihit.attr, + &dev_attr_srbds.attr, ++ &dev_attr_gather_data_sampling.attr, + NULL + }; + +-- +2.25.1 + diff --git a/meta-openbmc-mods/meta-common/recipes-kernel/linux/linux-aspeed/CVE-2022-48425.patch b/meta-openbmc-mods/meta-common/recipes-kernel/linux/linux-aspeed/CVE-2022-48425.patch new file mode 100644 index 000000000..10014562c --- /dev/null +++ b/meta-openbmc-mods/meta-common/recipes-kernel/linux/linux-aspeed/CVE-2022-48425.patch @@ -0,0 +1,136 @@ +From 98bea253aa28ad8be2ce565a9ca21beb4a9419e5 Mon Sep 17 00:00:00 2001 +From: Edward Lo <edward.lo@ambergroup.io> +Date: Sat, 5 Nov 2022 23:39:44 +0800 +Subject: fs/ntfs3: Validate MFT flags before replaying logs + +Log load and replay is part of the metadata handle flow during mount +operation. The $MFT record will be loaded and used while replaying logs. +However, a malformed $MFT record, say, has RECORD_FLAG_DIR flag set and +contains an ATTR_ROOT attribute will misguide kernel to treat it as a +directory, and try to free the allocated resources when the +corresponding inode is freed, which will cause an invalid kfree because +the memory hasn't actually been allocated. + +[ 101.368647] BUG: KASAN: invalid-free in kvfree+0x2c/0x40 +[ 101.369457] +[ 101.369986] CPU: 0 PID: 198 Comm: mount Not tainted 6.0.0-rc7+ #5 +[ 101.370529] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.14.0-0-g155821a1990b-prebuilt.qemu.org 04/01/2014 +[ 101.371362] Call Trace: +[ 101.371795] <TASK> +[ 101.372157] dump_stack_lvl+0x49/0x63 +[ 101.372658] print_report.cold+0xf5/0x689 +[ 101.373022] ? ni_write_inode+0x754/0xd90 +[ 101.373378] ? kvfree+0x2c/0x40 +[ 101.373698] kasan_report_invalid_free+0x77/0xf0 +[ 101.374058] ? kvfree+0x2c/0x40 +[ 101.374352] ? kvfree+0x2c/0x40 +[ 101.374668] __kasan_slab_free+0x189/0x1b0 +[ 101.374992] ? kvfree+0x2c/0x40 +[ 101.375271] kfree+0x168/0x3b0 +[ 101.375717] kvfree+0x2c/0x40 +[ 101.376002] indx_clear+0x26/0x60 +[ 101.376316] ni_clear+0xc5/0x290 +[ 101.376661] ntfs_evict_inode+0x45/0x70 +[ 101.377001] evict+0x199/0x280 +[ 101.377432] iput.part.0+0x286/0x320 +[ 101.377819] iput+0x32/0x50 +[ 101.378166] ntfs_loadlog_and_replay+0x143/0x320 +[ 101.378656] ? ntfs_bio_fill_1+0x510/0x510 +[ 101.378968] ? iput.part.0+0x286/0x320 +[ 101.379367] ntfs_fill_super+0xecb/0x1ba0 +[ 101.379729] ? put_ntfs+0x1d0/0x1d0 +[ 101.380046] ? vsprintf+0x20/0x20 +[ 101.380542] ? mutex_unlock+0x81/0xd0 +[ 101.380914] ? set_blocksize+0x95/0x150 +[ 101.381597] get_tree_bdev+0x232/0x370 +[ 101.382254] ? put_ntfs+0x1d0/0x1d0 +[ 101.382699] ntfs_fs_get_tree+0x15/0x20 +[ 101.383094] vfs_get_tree+0x4c/0x130 +[ 101.383675] path_mount+0x654/0xfe0 +[ 101.384203] ? putname+0x80/0xa0 +[ 101.384540] ? finish_automount+0x2e0/0x2e0 +[ 101.384943] ? putname+0x80/0xa0 +[ 101.385362] ? kmem_cache_free+0x1c4/0x440 +[ 101.385968] ? putname+0x80/0xa0 +[ 101.386666] do_mount+0xd6/0xf0 +[ 101.387228] ? path_mount+0xfe0/0xfe0 +[ 101.387585] ? __kasan_check_write+0x14/0x20 +[ 101.387979] __x64_sys_mount+0xca/0x110 +[ 101.388436] do_syscall_64+0x3b/0x90 +[ 101.388757] entry_SYSCALL_64_after_hwframe+0x63/0xcd +[ 101.389289] RIP: 0033:0x7fa0f70e948a +[ 101.390048] Code: 48 8b 0d 11 fa 2a 00 f7 d8 64 89 01 48 83 c8 ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 49 89 ca b8 a5 00 00 008 +[ 101.391297] RSP: 002b:00007ffc24fdecc8 EFLAGS: 00000202 ORIG_RAX: 00000000000000a5 +[ 101.391988] RAX: ffffffffffffffda RBX: 000055932c183060 RCX: 00007fa0f70e948a +[ 101.392494] RDX: 000055932c183260 RSI: 000055932c1832e0 RDI: 000055932c18bce0 +[ 101.393053] RBP: 0000000000000000 R08: 000055932c183280 R09: 0000000000000020 +[ 101.393577] R10: 00000000c0ed0000 R11: 0000000000000202 R12: 000055932c18bce0 +[ 101.394044] R13: 000055932c183260 R14: 0000000000000000 R15: 00000000ffffffff +[ 101.394747] </TASK> +[ 101.395402] +[ 101.396047] Allocated by task 198: +[ 101.396724] kasan_save_stack+0x26/0x50 +[ 101.397400] __kasan_slab_alloc+0x6d/0x90 +[ 101.397974] kmem_cache_alloc_lru+0x192/0x5a0 +[ 101.398524] ntfs_alloc_inode+0x23/0x70 +[ 101.399137] alloc_inode+0x3b/0xf0 +[ 101.399534] iget5_locked+0x54/0xa0 +[ 101.400026] ntfs_iget5+0xaf/0x1780 +[ 101.400414] ntfs_loadlog_and_replay+0xe5/0x320 +[ 101.400883] ntfs_fill_super+0xecb/0x1ba0 +[ 101.401313] get_tree_bdev+0x232/0x370 +[ 101.401774] ntfs_fs_get_tree+0x15/0x20 +[ 101.402224] vfs_get_tree+0x4c/0x130 +[ 101.402673] path_mount+0x654/0xfe0 +[ 101.403160] do_mount+0xd6/0xf0 +[ 101.403537] __x64_sys_mount+0xca/0x110 +[ 101.404058] do_syscall_64+0x3b/0x90 +[ 101.404333] entry_SYSCALL_64_after_hwframe+0x63/0xcd +[ 101.404816] +[ 101.405067] The buggy address belongs to the object at ffff888008cc9ea0 +[ 101.405067] which belongs to the cache ntfs_inode_cache of size 992 +[ 101.406171] The buggy address is located 232 bytes inside of +[ 101.406171] 992-byte region [ffff888008cc9ea0, ffff888008cca280) +[ 101.406995] +[ 101.408559] The buggy address belongs to the physical page: +[ 101.409320] page:00000000dccf19dd refcount:1 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x8cc8 +[ 101.410654] head:00000000dccf19dd order:2 compound_mapcount:0 compound_pincount:0 +[ 101.411533] flags: 0xfffffc0010200(slab|head|node=0|zone=1|lastcpupid=0x1fffff) +[ 101.412665] raw: 000fffffc0010200 0000000000000000 dead000000000122 ffff888003695140 +[ 101.413209] raw: 0000000000000000 00000000800e000e 00000001ffffffff 0000000000000000 +[ 101.413799] page dumped because: kasan: bad access detected +[ 101.414213] +[ 101.414427] Memory state around the buggy address: +[ 101.414991] ffff888008cc9e80: fc fc fc fc 00 00 00 00 00 00 00 00 00 00 00 00 +[ 101.415785] ffff888008cc9f00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 +[ 101.416933] >ffff888008cc9f80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 +[ 101.417857] ^ +[ 101.418566] ffff888008cca000: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 +[ 101.419704] ffff888008cca080: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 + +Signed-off-by: Edward Lo <edward.lo@ambergroup.io> +Signed-off-by: Konstantin Komarov <almaz.alexandrovich@paragon-software.com> +--- + fs/ntfs3/inode.c | 6 ++++++ + 1 file changed, 6 insertions(+) + +diff --git a/fs/ntfs3/inode.c b/fs/ntfs3/inode.c +index ce6bb3bd86b6e..059f288784580 100644 +--- a/fs/ntfs3/inode.c ++++ b/fs/ntfs3/inode.c +@@ -100,6 +100,12 @@ static struct inode *ntfs_read_mft(struct inode *inode, + /* Record should contain $I30 root. */ + is_dir = rec->flags & RECORD_FLAG_DIR; + ++ /* MFT_REC_MFT is not a dir */ ++ if (is_dir && ino == MFT_REC_MFT) { ++ err = -EINVAL; ++ goto out; ++ } ++ + inode->i_generation = le16_to_cpu(rec->seq); + + /* Enumerate all struct Attributes MFT. */ +-- +cgit 1.2.3-korg + diff --git a/meta-openbmc-mods/meta-common/recipes-kernel/linux/linux-aspeed/CVE-2022-48659.patch b/meta-openbmc-mods/meta-common/recipes-kernel/linux/linux-aspeed/CVE-2022-48659.patch new file mode 100644 index 000000000..840e2de82 --- /dev/null +++ b/meta-openbmc-mods/meta-common/recipes-kernel/linux/linux-aspeed/CVE-2022-48659.patch @@ -0,0 +1,73 @@ +From 016b150992eebc32c4a18f783cf2bb6e2545a3d9 Mon Sep 17 00:00:00 2001 +From: Chao Yu <chao.yu@oppo.com> +Date: Wed, 31 Aug 2022 22:54:54 +0800 +Subject: mm/slub: fix to return errno if kmalloc() fails + +commit 7e9c323c52b379d261a72dc7bd38120a761a93cd upstream. + +In create_unique_id(), kmalloc(, GFP_KERNEL) can fail due to +out-of-memory, if it fails, return errno correctly rather than +triggering panic via BUG_ON(); + +kernel BUG at mm/slub.c:5893! +Internal error: Oops - BUG: 0 [#1] PREEMPT SMP + +Call trace: + sysfs_slab_add+0x258/0x260 mm/slub.c:5973 + __kmem_cache_create+0x60/0x118 mm/slub.c:4899 + create_cache mm/slab_common.c:229 [inline] + kmem_cache_create_usercopy+0x19c/0x31c mm/slab_common.c:335 + kmem_cache_create+0x1c/0x28 mm/slab_common.c:390 + f2fs_kmem_cache_create fs/f2fs/f2fs.h:2766 [inline] + f2fs_init_xattr_caches+0x78/0xb4 fs/f2fs/xattr.c:808 + f2fs_fill_super+0x1050/0x1e0c fs/f2fs/super.c:4149 + mount_bdev+0x1b8/0x210 fs/super.c:1400 + f2fs_mount+0x44/0x58 fs/f2fs/super.c:4512 + legacy_get_tree+0x30/0x74 fs/fs_context.c:610 + vfs_get_tree+0x40/0x140 fs/super.c:1530 + do_new_mount+0x1dc/0x4e4 fs/namespace.c:3040 + path_mount+0x358/0x914 fs/namespace.c:3370 + do_mount fs/namespace.c:3383 [inline] + __do_sys_mount fs/namespace.c:3591 [inline] + __se_sys_mount fs/namespace.c:3568 [inline] + __arm64_sys_mount+0x2f8/0x408 fs/namespace.c:3568 + +Cc: <stable@kernel.org> +Fixes: 81819f0fc8285 ("SLUB core") +Reported-by: syzbot+81684812ea68216e08c5@syzkaller.appspotmail.com +Reviewed-by: Muchun Song <songmuchun@bytedance.com> +Reviewed-by: Hyeonggon Yoo <42.hyeyoo@gmail.com> +Signed-off-by: Chao Yu <chao.yu@oppo.com> +Acked-by: David Rientjes <rientjes@google.com> +Signed-off-by: Vlastimil Babka <vbabka@suse.cz> +Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> +--- + mm/slub.c | 5 ++++- + 1 file changed, 4 insertions(+), 1 deletion(-) + +diff --git a/mm/slub.c b/mm/slub.c +index 5211496f6d24fc..17e663cf38f69b 100644 +--- a/mm/slub.c ++++ b/mm/slub.c +@@ -5743,7 +5743,8 @@ static char *create_unique_id(struct kmem_cache *s) + char *name = kmalloc(ID_STR_LENGTH, GFP_KERNEL); + char *p = name; + +- BUG_ON(!name); ++ if (!name) ++ return ERR_PTR(-ENOMEM); + + *p++ = ':'; + /* +@@ -5825,6 +5826,8 @@ static int sysfs_slab_add(struct kmem_cache *s) + * for the symlinks. + */ + name = create_unique_id(s); ++ if (IS_ERR(name)) ++ return PTR_ERR(name); + } + + s->kobj.kset = kset; +-- +cgit 1.2.3-korg + diff --git a/meta-openbmc-mods/meta-common/recipes-kernel/linux/linux-aspeed/CVE-2022-48660.patch b/meta-openbmc-mods/meta-common/recipes-kernel/linux/linux-aspeed/CVE-2022-48660.patch new file mode 100644 index 000000000..c6538d9ac --- /dev/null +++ b/meta-openbmc-mods/meta-common/recipes-kernel/linux/linux-aspeed/CVE-2022-48660.patch @@ -0,0 +1,69 @@ +From 657803b918e097e47d99d1489da83a603c36bcdd Mon Sep 17 00:00:00 2001 +From: Meng Li <Meng.Li@windriver.com> +Date: Wed, 21 Sep 2022 11:20:20 +0800 +Subject: gpiolib: cdev: Set lineevent_state::irq after IRQ register + successfully + +commit 69bef19d6b9700e96285f4b4e28691cda3dcd0d1 upstream. + +When running gpio test on nxp-ls1028 platform with below command +gpiomon --num-events=3 --rising-edge gpiochip1 25 +There will be a warning trace as below: +Call trace: +free_irq+0x204/0x360 +lineevent_free+0x64/0x70 +gpio_ioctl+0x598/0x6a0 +__arm64_sys_ioctl+0xb4/0x100 +invoke_syscall+0x5c/0x130 +...... +el0t_64_sync+0x1a0/0x1a4 +The reason of this issue is that calling request_threaded_irq() +function failed, and then lineevent_free() is invoked to release +the resource. Since the lineevent_state::irq was already set, so +the subsequent invocation of free_irq() would trigger the above +warning call trace. To fix this issue, set the lineevent_state::irq +after the IRQ register successfully. + +Fixes: 468242724143 ("gpiolib: cdev: refactor lineevent cleanup into lineevent_free") +Cc: stable@vger.kernel.org +Signed-off-by: Meng Li <Meng.Li@windriver.com> +Reviewed-by: Kent Gibson <warthog618@gmail.com> +Signed-off-by: Bartosz Golaszewski <brgl@bgdev.pl> +Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> +--- + drivers/gpio/gpiolib-cdev.c | 5 +++-- + 1 file changed, 3 insertions(+), 2 deletions(-) + +diff --git a/drivers/gpio/gpiolib-cdev.c b/drivers/gpio/gpiolib-cdev.c +index 2613881a66e662..381cfa26a4a1a0 100644 +--- a/drivers/gpio/gpiolib-cdev.c ++++ b/drivers/gpio/gpiolib-cdev.c +@@ -1769,7 +1769,6 @@ static int lineevent_create(struct gpio_device *gdev, void __user *ip) + ret = -ENODEV; + goto out_free_le; + } +- le->irq = irq; + + if (eflags & GPIOEVENT_REQUEST_RISING_EDGE) + irqflags |= test_bit(FLAG_ACTIVE_LOW, &desc->flags) ? +@@ -1783,7 +1782,7 @@ static int lineevent_create(struct gpio_device *gdev, void __user *ip) + init_waitqueue_head(&le->wait); + + /* Request a thread to read the events */ +- ret = request_threaded_irq(le->irq, ++ ret = request_threaded_irq(irq, + lineevent_irq_handler, + lineevent_irq_thread, + irqflags, +@@ -1792,6 +1791,8 @@ static int lineevent_create(struct gpio_device *gdev, void __user *ip) + if (ret) + goto out_free_le; + ++ le->irq = irq; ++ + fd = get_unused_fd_flags(O_RDONLY | O_CLOEXEC); + if (fd < 0) { + ret = fd; +-- +cgit 1.2.3-korg + diff --git a/meta-openbmc-mods/meta-common/recipes-kernel/linux/linux-aspeed/CVE-2022-48672.patch b/meta-openbmc-mods/meta-common/recipes-kernel/linux/linux-aspeed/CVE-2022-48672.patch new file mode 100644 index 000000000..93d21e5da --- /dev/null +++ b/meta-openbmc-mods/meta-common/recipes-kernel/linux/linux-aspeed/CVE-2022-48672.patch @@ -0,0 +1,39 @@ +From 2133f451311671c7c42b5640d2b999326b39aa0e Mon Sep 17 00:00:00 2001 +From: Sergey Shtylyov <s.shtylyov@omp.ru> +Date: Sat, 13 Aug 2022 23:34:16 +0300 +Subject: of: fdt: fix off-by-one error in unflatten_dt_nodes() + +[ Upstream commit 2f945a792f67815abca26fa8a5e863ccf3fa1181 ] + +Commit 78c44d910d3e ("drivers/of: Fix depth when unflattening devicetree") +forgot to fix up the depth check in the loop body in unflatten_dt_nodes() +which makes it possible to overflow the nps[] buffer... + +Found by Linux Verification Center (linuxtesting.org) with the SVACE static +analysis tool. + +Fixes: 78c44d910d3e ("drivers/of: Fix depth when unflattening devicetree") +Signed-off-by: Sergey Shtylyov <s.shtylyov@omp.ru> +Signed-off-by: Rob Herring <robh@kernel.org> +Link: https://lore.kernel.org/r/7c354554-006f-6b31-c195-cdfe4caee392@omp.ru +Signed-off-by: Sasha Levin <sashal@kernel.org> +--- + drivers/of/fdt.c | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +diff --git a/drivers/of/fdt.c b/drivers/of/fdt.c +index 520ed965bb7a4e..583ca847a39cba 100644 +--- a/drivers/of/fdt.c ++++ b/drivers/of/fdt.c +@@ -314,7 +314,7 @@ static int unflatten_dt_nodes(const void *blob, + for (offset = 0; + offset >= 0 && depth >= initial_depth; + offset = fdt_next_node(blob, offset, &depth)) { +- if (WARN_ON_ONCE(depth >= FDT_MAX_DEPTH)) ++ if (WARN_ON_ONCE(depth >= FDT_MAX_DEPTH - 1)) + continue; + + if (!IS_ENABLED(CONFIG_OF_KOBJ) && +-- +cgit 1.2.3-korg + diff --git a/meta-openbmc-mods/meta-common/recipes-kernel/linux/linux-aspeed/CVE-2022-48687.patch b/meta-openbmc-mods/meta-common/recipes-kernel/linux/linux-aspeed/CVE-2022-48687.patch new file mode 100644 index 000000000..53b751d83 --- /dev/null +++ b/meta-openbmc-mods/meta-common/recipes-kernel/linux/linux-aspeed/CVE-2022-48687.patch @@ -0,0 +1,76 @@ +From 076f2479fc5a15c4a970ca3b5e57d42ba09a31fa Mon Sep 17 00:00:00 2001 +From: David Lebrun <dlebrun@google.com> +Date: Fri, 2 Sep 2022 10:45:06 +0100 +Subject: ipv6: sr: fix out-of-bounds read when setting HMAC data. + +[ Upstream commit 84a53580c5d2138c7361c7c3eea5b31827e63b35 ] + +The SRv6 layer allows defining HMAC data that can later be used to sign IPv6 +Segment Routing Headers. This configuration is realised via netlink through +four attributes: SEG6_ATTR_HMACKEYID, SEG6_ATTR_SECRET, SEG6_ATTR_SECRETLEN and +SEG6_ATTR_ALGID. Because the SECRETLEN attribute is decoupled from the actual +length of the SECRET attribute, it is possible to provide invalid combinations +(e.g., secret = "", secretlen = 64). This case is not checked in the code and +with an appropriately crafted netlink message, an out-of-bounds read of up +to 64 bytes (max secret length) can occur past the skb end pointer and into +skb_shared_info: + +Breakpoint 1, seg6_genl_sethmac (skb=<optimized out>, info=<optimized out>) at net/ipv6/seg6.c:208 +208 memcpy(hinfo->secret, secret, slen); +(gdb) bt + #0 seg6_genl_sethmac (skb=<optimized out>, info=<optimized out>) at net/ipv6/seg6.c:208 + #1 0xffffffff81e012e9 in genl_family_rcv_msg_doit (skb=skb@entry=0xffff88800b1f9f00, nlh=nlh@entry=0xffff88800b1b7600, + extack=extack@entry=0xffffc90000ba7af0, ops=ops@entry=0xffffc90000ba7a80, hdrlen=4, net=0xffffffff84237580 <init_net>, family=<optimized out>, + family=<optimized out>) at net/netlink/genetlink.c:731 + #2 0xffffffff81e01435 in genl_family_rcv_msg (extack=0xffffc90000ba7af0, nlh=0xffff88800b1b7600, skb=0xffff88800b1f9f00, + family=0xffffffff82fef6c0 <seg6_genl_family>) at net/netlink/genetlink.c:775 + #3 genl_rcv_msg (skb=0xffff88800b1f9f00, nlh=0xffff88800b1b7600, extack=0xffffc90000ba7af0) at net/netlink/genetlink.c:792 + #4 0xffffffff81dfffc3 in netlink_rcv_skb (skb=skb@entry=0xffff88800b1f9f00, cb=cb@entry=0xffffffff81e01350 <genl_rcv_msg>) + at net/netlink/af_netlink.c:2501 + #5 0xffffffff81e00919 in genl_rcv (skb=0xffff88800b1f9f00) at net/netlink/genetlink.c:803 + #6 0xffffffff81dff6ae in netlink_unicast_kernel (ssk=0xffff888010eec800, skb=0xffff88800b1f9f00, sk=0xffff888004aed000) + at net/netlink/af_netlink.c:1319 + #7 netlink_unicast (ssk=ssk@entry=0xffff888010eec800, skb=skb@entry=0xffff88800b1f9f00, portid=portid@entry=0, nonblock=<optimized out>) + at net/netlink/af_netlink.c:1345 + #8 0xffffffff81dff9a4 in netlink_sendmsg (sock=<optimized out>, msg=0xffffc90000ba7e48, len=<optimized out>) at net/netlink/af_netlink.c:1921 +... +(gdb) p/x ((struct sk_buff *)0xffff88800b1f9f00)->head + ((struct sk_buff *)0xffff88800b1f9f00)->end +$1 = 0xffff88800b1b76c0 +(gdb) p/x secret +$2 = 0xffff88800b1b76c0 +(gdb) p slen +$3 = 64 '@' + +The OOB data can then be read back from userspace by dumping HMAC state. This +commit fixes this by ensuring SECRETLEN cannot exceed the actual length of +SECRET. + +Reported-by: Lucas Leong <wmliang.tw@gmail.com> +Tested: verified that EINVAL is correctly returned when secretlen > len(secret) +Fixes: 4f4853dc1c9c1 ("ipv6: sr: implement API to control SR HMAC structure") +Signed-off-by: David Lebrun <dlebrun@google.com> +Signed-off-by: David S. Miller <davem@davemloft.net> +Signed-off-by: Sasha Levin <sashal@kernel.org> +--- + net/ipv6/seg6.c | 5 +++++ + 1 file changed, 5 insertions(+) + +diff --git a/net/ipv6/seg6.c b/net/ipv6/seg6.c +index d2f8138e5a73a5..2278c0234c4979 100644 +--- a/net/ipv6/seg6.c ++++ b/net/ipv6/seg6.c +@@ -135,6 +135,11 @@ static int seg6_genl_sethmac(struct sk_buff *skb, struct genl_info *info) + goto out_unlock; + } + ++ if (slen > nla_len(info->attrs[SEG6_ATTR_SECRET])) { ++ err = -EINVAL; ++ goto out_unlock; ++ } ++ + if (hinfo) { + err = seg6_hmac_info_del(net, hmackeyid); + if (err) +-- +cgit 1.2.3-korg + diff --git a/meta-openbmc-mods/meta-common/recipes-kernel/linux/linux-aspeed/CVE-2022-48689.patch b/meta-openbmc-mods/meta-common/recipes-kernel/linux/linux-aspeed/CVE-2022-48689.patch new file mode 100644 index 000000000..136878aaf --- /dev/null +++ b/meta-openbmc-mods/meta-common/recipes-kernel/linux/linux-aspeed/CVE-2022-48689.patch @@ -0,0 +1,167 @@ +From 3261400639463a853ba2b3be8bd009c2a8089775 Mon Sep 17 00:00:00 2001 +From: Eric Dumazet <edumazet@google.com> +Date: Wed, 31 Aug 2022 23:38:09 +0000 +Subject: [PATCH] tcp: TX zerocopy should not sense pfmemalloc status + +We got a recent syzbot report [1] showing a possible misuse +of pfmemalloc page status in TCP zerocopy paths. + +Indeed, for pages coming from user space or other layers, +using page_is_pfmemalloc() is moot, and possibly could give +false positives. + +There has been attempts to make page_is_pfmemalloc() more robust, +but not using it in the first place in this context is probably better, +removing cpu cycles. + +Note to stable teams : + +You need to backport 84ce071e38a6 ("net: introduce +__skb_fill_page_desc_noacc") as a prereq. + +Race is more probable after commit c07aea3ef4d4 +("mm: add a signature in struct page") because page_is_pfmemalloc() +is now using low order bit from page->lru.next, which can change +more often than page->index. + +Low order bit should never be set for lru.next (when used as an anchor +in LRU list), so KCSAN report is mostly a false positive. + +Backporting to older kernel versions seems not necessary. + +[1] +BUG: KCSAN: data-race in lru_add_fn / tcp_build_frag + +write to 0xffffea0004a1d2c8 of 8 bytes by task 18600 on cpu 0: +__list_add include/linux/list.h:73 [inline] +list_add include/linux/list.h:88 [inline] +lruvec_add_folio include/linux/mm_inline.h:105 [inline] +lru_add_fn+0x440/0x520 mm/swap.c:228 +folio_batch_move_lru+0x1e1/0x2a0 mm/swap.c:246 +folio_batch_add_and_move mm/swap.c:263 [inline] +folio_add_lru+0xf1/0x140 mm/swap.c:490 +filemap_add_folio+0xf8/0x150 mm/filemap.c:948 +__filemap_get_folio+0x510/0x6d0 mm/filemap.c:1981 +pagecache_get_page+0x26/0x190 mm/folio-compat.c:104 +grab_cache_page_write_begin+0x2a/0x30 mm/folio-compat.c:116 +ext4_da_write_begin+0x2dd/0x5f0 fs/ext4/inode.c:2988 +generic_perform_write+0x1d4/0x3f0 mm/filemap.c:3738 +ext4_buffered_write_iter+0x235/0x3e0 fs/ext4/file.c:270 +ext4_file_write_iter+0x2e3/0x1210 +call_write_iter include/linux/fs.h:2187 [inline] +new_sync_write fs/read_write.c:491 [inline] +vfs_write+0x468/0x760 fs/read_write.c:578 +ksys_write+0xe8/0x1a0 fs/read_write.c:631 +__do_sys_write fs/read_write.c:643 [inline] +__se_sys_write fs/read_write.c:640 [inline] +__x64_sys_write+0x3e/0x50 fs/read_write.c:640 +do_syscall_x64 arch/x86/entry/common.c:50 [inline] +do_syscall_64+0x2b/0x70 arch/x86/entry/common.c:80 +entry_SYSCALL_64_after_hwframe+0x63/0xcd + +read to 0xffffea0004a1d2c8 of 8 bytes by task 18611 on cpu 1: +page_is_pfmemalloc include/linux/mm.h:1740 [inline] +__skb_fill_page_desc include/linux/skbuff.h:2422 [inline] +skb_fill_page_desc include/linux/skbuff.h:2443 [inline] +tcp_build_frag+0x613/0xb20 net/ipv4/tcp.c:1018 +do_tcp_sendpages+0x3e8/0xaf0 net/ipv4/tcp.c:1075 +tcp_sendpage_locked net/ipv4/tcp.c:1140 [inline] +tcp_sendpage+0x89/0xb0 net/ipv4/tcp.c:1150 +inet_sendpage+0x7f/0xc0 net/ipv4/af_inet.c:833 +kernel_sendpage+0x184/0x300 net/socket.c:3561 +sock_sendpage+0x5a/0x70 net/socket.c:1054 +pipe_to_sendpage+0x128/0x160 fs/splice.c:361 +splice_from_pipe_feed fs/splice.c:415 [inline] +__splice_from_pipe+0x222/0x4d0 fs/splice.c:559 +splice_from_pipe fs/splice.c:594 [inline] +generic_splice_sendpage+0x89/0xc0 fs/splice.c:743 +do_splice_from fs/splice.c:764 [inline] +direct_splice_actor+0x80/0xa0 fs/splice.c:931 +splice_direct_to_actor+0x305/0x620 fs/splice.c:886 +do_splice_direct+0xfb/0x180 fs/splice.c:974 +do_sendfile+0x3bf/0x910 fs/read_write.c:1249 +__do_sys_sendfile64 fs/read_write.c:1317 [inline] +__se_sys_sendfile64 fs/read_write.c:1303 [inline] +__x64_sys_sendfile64+0x10c/0x150 fs/read_write.c:1303 +do_syscall_x64 arch/x86/entry/common.c:50 [inline] +do_syscall_64+0x2b/0x70 arch/x86/entry/common.c:80 +entry_SYSCALL_64_after_hwframe+0x63/0xcd + +value changed: 0x0000000000000000 -> 0xffffea0004a1d288 + +Reported by Kernel Concurrency Sanitizer on: +CPU: 1 PID: 18611 Comm: syz-executor.4 Not tainted 6.0.0-rc2-syzkaller-00248-ge022620b5d05-dirty #0 +Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 07/22/2022 + +Fixes: c07aea3ef4d4 ("mm: add a signature in struct page") +Reported-by: syzbot <syzkaller@googlegroups.com> +Signed-off-by: Eric Dumazet <edumazet@google.com> +Cc: Shakeel Butt <shakeelb@google.com> +Reviewed-by: Shakeel Butt <shakeelb@google.com> +Signed-off-by: David S. Miller <davem@davemloft.net> +--- + include/linux/skbuff.h | 20 ++++++++++++++++++++ + net/core/datagram.c | 2 +- + net/ipv4/tcp.c | 2 +- + 3 files changed, 22 insertions(+), 2 deletions(-) + +diff --git a/include/linux/skbuff.h b/include/linux/skbuff.h +index 841e2f0f5240..051843e918c8 100644 +--- a/include/linux/skbuff.h ++++ b/include/linux/skbuff.h +@@ -2211,6 +2211,26 @@ static inline void skb_fill_page_desc(struct sk_buff *skb, int i, + skb_shinfo(skb)->nr_frags = i + 1; + } + ++/** ++ * skb_fill_page_desc_noacc - initialise a paged fragment in an skb ++ * @skb: buffer containing fragment to be initialised ++ * @i: paged fragment index to initialise ++ * @page: the page to use for this fragment ++ * @off: the offset to the data with @page ++ * @size: the length of the data ++ * ++ * Variant of skb_fill_page_desc() which does not deal with ++ * pfmemalloc, if page is not owned by us. ++ */ ++static inline void skb_fill_page_desc_noacc(struct sk_buff *skb, int i, ++ struct page *page, int off, ++ int size) ++{ ++ struct skb_shared_info *shinfo = skb_shinfo(skb); ++ ++ shinfo->nr_frags = i + 1; ++} ++ + void skb_add_rx_frag(struct sk_buff *skb, int i, struct page *page, int off, + int size, unsigned int truesize); + +diff --git a/net/core/datagram.c b/net/core/datagram.c +index 15ab9ffb27fe..28e5f921dcaf 100644 +--- a/net/core/datagram.c ++++ b/net/core/datagram.c +@@ -677,7 +677,7 @@ int __zerocopy_sg_from_iter(struct sock *sk, struct sk_buff *skb, + page_ref_sub(last_head, refs); + refs = 0; + } +- skb_fill_page_desc(skb, frag++, head, start, size); ++ skb_fill_page_desc_noacc(skb, frag++, head, start, size); + } + if (refs) + page_ref_sub(last_head, refs); +diff --git a/net/ipv4/tcp.c b/net/ipv4/tcp.c +index c86d27d653be..d066d780010d 100644 +--- a/net/ipv4/tcp.c ++++ b/net/ipv4/tcp.c +@@ -1002,7 +1002,7 @@ struct sk_buff *tcp_build_frag(struct sock *sk, int size_goal, int flags, + skb_frag_size_add(&skb_shinfo(skb)->frags[i - 1], copy); + } else { + get_page(page); +- skb_fill_page_desc(skb, i, page, offset, copy); ++ skb_fill_page_desc_noacc(skb, i, page, offset, copy); + } + + if (!(flags & MSG_NO_SHARED_FRAGS)) +-- +2.25.1 + diff --git a/meta-openbmc-mods/meta-common/recipes-kernel/linux/linux-aspeed/CVE-2023-0386.patch b/meta-openbmc-mods/meta-common/recipes-kernel/linux/linux-aspeed/CVE-2023-0386.patch new file mode 100644 index 000000000..0c457f4a2 --- /dev/null +++ b/meta-openbmc-mods/meta-common/recipes-kernel/linux/linux-aspeed/CVE-2023-0386.patch @@ -0,0 +1,48 @@ +From 4f11ada10d0ad3fd53e2bd67806351de63a4f9c3 Mon Sep 17 00:00:00 2001 +From: Miklos Szeredi <mszeredi@redhat.com> +Date: Tue, 24 Jan 2023 16:41:18 +0100 +Subject: ovl: fail on invalid uid/gid mapping at copy up + +If st_uid/st_gid doesn't have a mapping in the mounter's user_ns, then +copy-up should fail, just like it would fail if the mounter task was doing +the copy using "cp -a". + +There's a corner case where the "cp -a" would succeed but copy up fail: if +there's a mapping of the invalid uid/gid (65534 by default) in the user +namespace. This is because stat(2) will return this value if the mapping +doesn't exist in the current user_ns and "cp -a" will in turn be able to +create a file with this uid/gid. + +This behavior would be inconsistent with POSIX ACL's, which return -1 for +invalid uid/gid which result in a failed copy. + +For consistency and simplicity fail the copy of the st_uid/st_gid are +invalid. + +Fixes: 459c7c565ac3 ("ovl: unprivieged mounts") +Cc: <stable@vger.kernel.org> # v5.11 +Signed-off-by: Miklos Szeredi <mszeredi@redhat.com> +Reviewed-by: Christian Brauner <brauner@kernel.org> +Reviewed-by: Seth Forshee <sforshee@kernel.org> +--- + fs/overlayfs/copy_up.c | 4 ++++ + 1 file changed, 4 insertions(+) + +diff --git a/fs/overlayfs/copy_up.c b/fs/overlayfs/copy_up.c +index 140f2742074d4..c14e90764e356 100644 +--- a/fs/overlayfs/copy_up.c ++++ b/fs/overlayfs/copy_up.c +@@ -1011,6 +1011,10 @@ static int ovl_copy_up_one(struct dentry *parent, struct dentry *dentry, + if (err) + return err; + ++ if (!kuid_has_mapping(current_user_ns(), ctx.stat.uid) || ++ !kgid_has_mapping(current_user_ns(), ctx.stat.gid)) ++ return -EOVERFLOW; ++ + ctx.metacopy = ovl_need_meta_copy_up(dentry, ctx.stat.mode, flags); + + if (parent) { +-- +cgit 1.2.3-korg + diff --git a/meta-openbmc-mods/meta-common/recipes-kernel/linux/linux-aspeed/CVE-2023-0458.patch b/meta-openbmc-mods/meta-common/recipes-kernel/linux/linux-aspeed/CVE-2023-0458.patch new file mode 100644 index 000000000..351debf21 --- /dev/null +++ b/meta-openbmc-mods/meta-common/recipes-kernel/linux/linux-aspeed/CVE-2023-0458.patch @@ -0,0 +1,34 @@ +From 739790605705ddcf18f21782b9c99ad7d53a8c11 Mon Sep 17 00:00:00 2001 +From: Greg Kroah-Hartman <gregkh@linuxfoundation.org> +Date: Fri, 20 Jan 2023 11:03:20 +0100 +Subject: prlimit: do_prlimit needs to have a speculation check + +do_prlimit() adds the user-controlled resource value to a pointer that +will subsequently be dereferenced. In order to help prevent this +codepath from being used as a spectre "gadget" a barrier needs to be +added after checking the range. + +Reported-by: Jordy Zomer <jordyzomer@google.com> +Tested-by: Jordy Zomer <jordyzomer@google.com> +Suggested-by: Linus Torvalds <torvalds@linuxfoundation.org> +Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> +--- + kernel/sys.c | 2 ++ + 1 file changed, 2 insertions(+) + +diff --git a/kernel/sys.c b/kernel/sys.c +index 5fd54bf0e8867..88b31f096fb2d 100644 +--- a/kernel/sys.c ++++ b/kernel/sys.c +@@ -1442,6 +1442,8 @@ static int do_prlimit(struct task_struct *tsk, unsigned int resource, + + if (resource >= RLIM_NLIMITS) + return -EINVAL; ++ resource = array_index_nospec(resource, RLIM_NLIMITS); ++ + if (new_rlim) { + if (new_rlim->rlim_cur > new_rlim->rlim_max) + return -EINVAL; +-- +cgit 1.2.3-korg + diff --git a/meta-openbmc-mods/meta-common/recipes-kernel/linux/linux-aspeed/CVE-2023-2176.patch b/meta-openbmc-mods/meta-common/recipes-kernel/linux/linux-aspeed/CVE-2023-2176.patch new file mode 100644 index 000000000..093151077 --- /dev/null +++ b/meta-openbmc-mods/meta-common/recipes-kernel/linux/linux-aspeed/CVE-2023-2176.patch @@ -0,0 +1,317 @@ +From 8d037973d48c026224ab285e6a06985ccac6f7bf Mon Sep 17 00:00:00 2001 +From: Patrisious Haddad <phaddad@nvidia.com> +Date: Wed, 4 Jan 2023 10:01:38 +0200 +Subject: RDMA/core: Refactor rdma_bind_addr + +Refactor rdma_bind_addr function so that it doesn't require that the +cma destination address be changed before calling it. + +So now it will update the destination address internally only when it is +really needed and after passing all the required checks. + +Which in turn results in a cleaner and more sensible call and error +handling flows for the functions that call it directly or indirectly. + +Signed-off-by: Patrisious Haddad <phaddad@nvidia.com> +Reported-by: Wei Chen <harperchen1110@gmail.com> +Reviewed-by: Mark Zhang <markzhang@nvidia.com> +Link: https://lore.kernel.org/r/3d0e9a2fd62bc10ba02fed1c7c48a48638952320.1672819273.git.leonro@nvidia.com +Signed-off-by: Leon Romanovsky <leon@kernel.org> +--- + drivers/infiniband/core/cma.c | 245 ++++++++++++++++++---------------- + 1 file changed, 130 insertions(+), 115 deletions(-) + +diff --git a/drivers/infiniband/core/cma.c b/drivers/infiniband/core/cma.c +index 704ce595542c..5d673dfa117a 100644 +--- a/drivers/infiniband/core/cma.c ++++ b/drivers/infiniband/core/cma.c +@@ -3357,113 +3357,6 @@ static int cma_resolve_ib_addr(struct rdma_id_private *id_priv) + return ret; + } + +-static int cma_bind_addr(struct rdma_cm_id *id, struct sockaddr *src_addr, +- const struct sockaddr *dst_addr) +-{ +- if (!src_addr || !src_addr->sa_family) { +- src_addr = (struct sockaddr *) &id->route.addr.src_addr; +- src_addr->sa_family = dst_addr->sa_family; +- if (IS_ENABLED(CONFIG_IPV6) && +- dst_addr->sa_family == AF_INET6) { +- struct sockaddr_in6 *src_addr6 = (struct sockaddr_in6 *) src_addr; +- struct sockaddr_in6 *dst_addr6 = (struct sockaddr_in6 *) dst_addr; +- src_addr6->sin6_scope_id = dst_addr6->sin6_scope_id; +- if (ipv6_addr_type(&dst_addr6->sin6_addr) & IPV6_ADDR_LINKLOCAL) +- id->route.addr.dev_addr.bound_dev_if = dst_addr6->sin6_scope_id; +- } else if (dst_addr->sa_family == AF_IB) { +- ((struct sockaddr_ib *) src_addr)->sib_pkey = +- ((struct sockaddr_ib *) dst_addr)->sib_pkey; +- } +- } +- return rdma_bind_addr(id, src_addr); +-} +- +-/* +- * If required, resolve the source address for bind and leave the id_priv in +- * state RDMA_CM_ADDR_BOUND. This oddly uses the state to determine the prior +- * calls made by ULP, a previously bound ID will not be re-bound and src_addr is +- * ignored. +- */ +-static int resolve_prepare_src(struct rdma_id_private *id_priv, +- struct sockaddr *src_addr, +- const struct sockaddr *dst_addr) +-{ +- int ret; +- +- memcpy(cma_dst_addr(id_priv), dst_addr, rdma_addr_size(dst_addr)); +- if (!cma_comp_exch(id_priv, RDMA_CM_ADDR_BOUND, RDMA_CM_ADDR_QUERY)) { +- /* For a well behaved ULP state will be RDMA_CM_IDLE */ +- ret = cma_bind_addr(&id_priv->id, src_addr, dst_addr); +- if (ret) +- goto err_dst; +- if (WARN_ON(!cma_comp_exch(id_priv, RDMA_CM_ADDR_BOUND, +- RDMA_CM_ADDR_QUERY))) { +- ret = -EINVAL; +- goto err_dst; +- } +- } +- +- if (cma_family(id_priv) != dst_addr->sa_family) { +- ret = -EINVAL; +- goto err_state; +- } +- return 0; +- +-err_state: +- cma_comp_exch(id_priv, RDMA_CM_ADDR_QUERY, RDMA_CM_ADDR_BOUND); +-err_dst: +- memset(cma_dst_addr(id_priv), 0, rdma_addr_size(dst_addr)); +- return ret; +-} +- +-int rdma_resolve_addr(struct rdma_cm_id *id, struct sockaddr *src_addr, +- const struct sockaddr *dst_addr, unsigned long timeout_ms) +-{ +- struct rdma_id_private *id_priv = +- container_of(id, struct rdma_id_private, id); +- int ret; +- +- ret = resolve_prepare_src(id_priv, src_addr, dst_addr); +- if (ret) +- return ret; +- +- if (cma_any_addr(dst_addr)) { +- ret = cma_resolve_loopback(id_priv); +- } else { +- if (dst_addr->sa_family == AF_IB) { +- ret = cma_resolve_ib_addr(id_priv); +- } else { +- /* +- * The FSM can return back to RDMA_CM_ADDR_BOUND after +- * rdma_resolve_ip() is called, eg through the error +- * path in addr_handler(). If this happens the existing +- * request must be canceled before issuing a new one. +- * Since canceling a request is a bit slow and this +- * oddball path is rare, keep track once a request has +- * been issued. The track turns out to be a permanent +- * state since this is the only cancel as it is +- * immediately before rdma_resolve_ip(). +- */ +- if (id_priv->used_resolve_ip) +- rdma_addr_cancel(&id->route.addr.dev_addr); +- else +- id_priv->used_resolve_ip = 1; +- ret = rdma_resolve_ip(cma_src_addr(id_priv), dst_addr, +- &id->route.addr.dev_addr, +- timeout_ms, addr_handler, +- false, id_priv); +- } +- } +- if (ret) +- goto err; +- +- return 0; +-err: +- cma_comp_exch(id_priv, RDMA_CM_ADDR_QUERY, RDMA_CM_ADDR_BOUND); +- return ret; +-} +-EXPORT_SYMBOL(rdma_resolve_addr); +- + int rdma_set_reuseaddr(struct rdma_cm_id *id, int reuse) + { + struct rdma_id_private *id_priv; +@@ -3866,27 +3759,26 @@ int rdma_listen(struct rdma_cm_id *id, int backlog) + } + EXPORT_SYMBOL(rdma_listen); + +-int rdma_bind_addr(struct rdma_cm_id *id, struct sockaddr *addr) ++static int rdma_bind_addr_dst(struct rdma_id_private *id_priv, ++ struct sockaddr *addr, const struct sockaddr *daddr) + { +- struct rdma_id_private *id_priv; ++ struct sockaddr *id_daddr; + int ret; +- struct sockaddr *daddr; + + if (addr->sa_family != AF_INET && addr->sa_family != AF_INET6 && + addr->sa_family != AF_IB) + return -EAFNOSUPPORT; + +- id_priv = container_of(id, struct rdma_id_private, id); + if (!cma_comp_exch(id_priv, RDMA_CM_IDLE, RDMA_CM_ADDR_BOUND)) + return -EINVAL; + +- ret = cma_check_linklocal(&id->route.addr.dev_addr, addr); ++ ret = cma_check_linklocal(&id_priv->id.route.addr.dev_addr, addr); + if (ret) + goto err1; + + memcpy(cma_src_addr(id_priv), addr, rdma_addr_size(addr)); + if (!cma_any_addr(addr)) { +- ret = cma_translate_addr(addr, &id->route.addr.dev_addr); ++ ret = cma_translate_addr(addr, &id_priv->id.route.addr.dev_addr); + if (ret) + goto err1; + +@@ -3906,8 +3798,10 @@ int rdma_bind_addr(struct rdma_cm_id *id, struct sockaddr *addr) + } + #endif + } +- daddr = cma_dst_addr(id_priv); +- daddr->sa_family = addr->sa_family; ++ id_daddr = cma_dst_addr(id_priv); ++ if (daddr != id_daddr) ++ memcpy(id_daddr, daddr, rdma_addr_size(addr)); ++ id_daddr->sa_family = addr->sa_family; + + ret = cma_get_port(id_priv); + if (ret) +@@ -3923,6 +3817,127 @@ int rdma_bind_addr(struct rdma_cm_id *id, struct sockaddr *addr) + cma_comp_exch(id_priv, RDMA_CM_ADDR_BOUND, RDMA_CM_IDLE); + return ret; + } ++ ++static int cma_bind_addr(struct rdma_cm_id *id, struct sockaddr *src_addr, ++ const struct sockaddr *dst_addr) ++{ ++ struct rdma_id_private *id_priv = ++ container_of(id, struct rdma_id_private, id); ++ struct sockaddr_storage zero_sock = {}; ++ ++ if (src_addr && src_addr->sa_family) ++ return rdma_bind_addr_dst(id_priv, src_addr, dst_addr); ++ ++ /* ++ * When the src_addr is not specified, automatically supply an any addr ++ */ ++ zero_sock.ss_family = dst_addr->sa_family; ++ if (IS_ENABLED(CONFIG_IPV6) && dst_addr->sa_family == AF_INET6) { ++ struct sockaddr_in6 *src_addr6 = ++ (struct sockaddr_in6 *)&zero_sock; ++ struct sockaddr_in6 *dst_addr6 = ++ (struct sockaddr_in6 *)dst_addr; ++ ++ src_addr6->sin6_scope_id = dst_addr6->sin6_scope_id; ++ if (ipv6_addr_type(&dst_addr6->sin6_addr) & IPV6_ADDR_LINKLOCAL) ++ id->route.addr.dev_addr.bound_dev_if = ++ dst_addr6->sin6_scope_id; ++ } else if (dst_addr->sa_family == AF_IB) { ++ ((struct sockaddr_ib *)&zero_sock)->sib_pkey = ++ ((struct sockaddr_ib *)dst_addr)->sib_pkey; ++ } ++ return rdma_bind_addr_dst(id_priv, (struct sockaddr *)&zero_sock, dst_addr); ++} ++ ++/* ++ * If required, resolve the source address for bind and leave the id_priv in ++ * state RDMA_CM_ADDR_BOUND. This oddly uses the state to determine the prior ++ * calls made by ULP, a previously bound ID will not be re-bound and src_addr is ++ * ignored. ++ */ ++static int resolve_prepare_src(struct rdma_id_private *id_priv, ++ struct sockaddr *src_addr, ++ const struct sockaddr *dst_addr) ++{ ++ int ret; ++ ++ if (!cma_comp_exch(id_priv, RDMA_CM_ADDR_BOUND, RDMA_CM_ADDR_QUERY)) { ++ /* For a well behaved ULP state will be RDMA_CM_IDLE */ ++ ret = cma_bind_addr(&id_priv->id, src_addr, dst_addr); ++ if (ret) ++ return ret; ++ if (WARN_ON(!cma_comp_exch(id_priv, RDMA_CM_ADDR_BOUND, ++ RDMA_CM_ADDR_QUERY))) ++ return -EINVAL; ++ ++ } ++ ++ if (cma_family(id_priv) != dst_addr->sa_family) { ++ ret = -EINVAL; ++ goto err_state; ++ } ++ return 0; ++ ++err_state: ++ cma_comp_exch(id_priv, RDMA_CM_ADDR_QUERY, RDMA_CM_ADDR_BOUND); ++ return ret; ++} ++ ++int rdma_resolve_addr(struct rdma_cm_id *id, struct sockaddr *src_addr, ++ const struct sockaddr *dst_addr, unsigned long timeout_ms) ++{ ++ struct rdma_id_private *id_priv = ++ container_of(id, struct rdma_id_private, id); ++ int ret; ++ ++ ret = resolve_prepare_src(id_priv, src_addr, dst_addr); ++ if (ret) ++ return ret; ++ ++ if (cma_any_addr(dst_addr)) { ++ ret = cma_resolve_loopback(id_priv); ++ } else { ++ if (dst_addr->sa_family == AF_IB) { ++ ret = cma_resolve_ib_addr(id_priv); ++ } else { ++ /* ++ * The FSM can return back to RDMA_CM_ADDR_BOUND after ++ * rdma_resolve_ip() is called, eg through the error ++ * path in addr_handler(). If this happens the existing ++ * request must be canceled before issuing a new one. ++ * Since canceling a request is a bit slow and this ++ * oddball path is rare, keep track once a request has ++ * been issued. The track turns out to be a permanent ++ * state since this is the only cancel as it is ++ * immediately before rdma_resolve_ip(). ++ */ ++ if (id_priv->used_resolve_ip) ++ rdma_addr_cancel(&id->route.addr.dev_addr); ++ else ++ id_priv->used_resolve_ip = 1; ++ ret = rdma_resolve_ip(cma_src_addr(id_priv), dst_addr, ++ &id->route.addr.dev_addr, ++ timeout_ms, addr_handler, ++ false, id_priv); ++ } ++ } ++ if (ret) ++ goto err; ++ ++ return 0; ++err: ++ cma_comp_exch(id_priv, RDMA_CM_ADDR_QUERY, RDMA_CM_ADDR_BOUND); ++ return ret; ++} ++EXPORT_SYMBOL(rdma_resolve_addr); ++ ++int rdma_bind_addr(struct rdma_cm_id *id, struct sockaddr *addr) ++{ ++ struct rdma_id_private *id_priv = ++ container_of(id, struct rdma_id_private, id); ++ ++ return rdma_bind_addr_dst(id_priv, addr, cma_dst_addr(id_priv)); ++} + EXPORT_SYMBOL(rdma_bind_addr); + + static int cma_format_hdr(void *hdr, struct rdma_id_private *id_priv) +-- +cgit 1.2.3-korg diff --git a/meta-openbmc-mods/meta-common/recipes-kernel/linux/linux-aspeed/CVE-2023-2235.patch b/meta-openbmc-mods/meta-common/recipes-kernel/linux/linux-aspeed/CVE-2023-2235.patch new file mode 100644 index 000000000..7271d470c --- /dev/null +++ b/meta-openbmc-mods/meta-common/recipes-kernel/linux/linux-aspeed/CVE-2023-2235.patch @@ -0,0 +1,35 @@ +From fd0815f632c24878e325821943edccc7fde947a2 Mon Sep 17 00:00:00 2001 +From: Budimir Markovic <markovicbudimir@gmail.com> +Date: Wed, 15 Mar 2023 00:29:01 -0700 +Subject: perf: Fix check before add_event_to_groups() in perf_group_detach() + +Events should only be added to a groups rb tree if they have not been +removed from their context by list_del_event(). Since remove_on_exec +made it possible to call list_del_event() on individual events before +they are detached from their group, perf_group_detach() should check each +sibling's attach_state before calling add_event_to_groups() on it. + +Fixes: 2e498d0a74e5 ("perf: Add support for event removal on exec") +Signed-off-by: Budimir Markovic <markovicbudimir@gmail.com> +Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org> +Link: https://lkml.kernel.org/r/ZBFzvQV9tEqoHEtH@gentoo +--- + kernel/events/core.c | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +diff --git a/kernel/events/core.c b/kernel/events/core.c +index 52b4aa0b3bd17..fb3e436bcd4ac 100644 +--- a/kernel/events/core.c ++++ b/kernel/events/core.c +@@ -2163,7 +2163,7 @@ static void perf_group_detach(struct perf_event *event) + /* Inherit group flags from the previous leader */ + sibling->group_caps = event->group_caps; + +- if (!RB_EMPTY_NODE(&event->group_node)) { ++ if (sibling->attach_state & PERF_ATTACH_CONTEXT) { + add_event_to_groups(sibling, event->ctx); + + if (sibling->state == PERF_EVENT_STATE_ACTIVE) +-- +cgit 1.2.3-korg + diff --git a/meta-openbmc-mods/meta-common/recipes-kernel/linux/linux-aspeed/CVE-2023-2860.patch b/meta-openbmc-mods/meta-common/recipes-kernel/linux/linux-aspeed/CVE-2023-2860.patch new file mode 100644 index 000000000..2b0c387d7 --- /dev/null +++ b/meta-openbmc-mods/meta-common/recipes-kernel/linux/linux-aspeed/CVE-2023-2860.patch @@ -0,0 +1,73 @@ +From 84a53580c5d2138c7361c7c3eea5b31827e63b35 Mon Sep 17 00:00:00 2001 +From: David Lebrun <dlebrun@google.com> +Date: Fri, 2 Sep 2022 10:45:06 +0100 +Subject: ipv6: sr: fix out-of-bounds read when setting HMAC data. + +The SRv6 layer allows defining HMAC data that can later be used to sign IPv6 +Segment Routing Headers. This configuration is realised via netlink through +four attributes: SEG6_ATTR_HMACKEYID, SEG6_ATTR_SECRET, SEG6_ATTR_SECRETLEN and +SEG6_ATTR_ALGID. Because the SECRETLEN attribute is decoupled from the actual +length of the SECRET attribute, it is possible to provide invalid combinations +(e.g., secret = "", secretlen = 64). This case is not checked in the code and +with an appropriately crafted netlink message, an out-of-bounds read of up +to 64 bytes (max secret length) can occur past the skb end pointer and into +skb_shared_info: + +Breakpoint 1, seg6_genl_sethmac (skb=<optimized out>, info=<optimized out>) at net/ipv6/seg6.c:208 +208 memcpy(hinfo->secret, secret, slen); +(gdb) bt + #0 seg6_genl_sethmac (skb=<optimized out>, info=<optimized out>) at net/ipv6/seg6.c:208 + #1 0xffffffff81e012e9 in genl_family_rcv_msg_doit (skb=skb@entry=0xffff88800b1f9f00, nlh=nlh@entry=0xffff88800b1b7600, + extack=extack@entry=0xffffc90000ba7af0, ops=ops@entry=0xffffc90000ba7a80, hdrlen=4, net=0xffffffff84237580 <init_net>, family=<optimized out>, + family=<optimized out>) at net/netlink/genetlink.c:731 + #2 0xffffffff81e01435 in genl_family_rcv_msg (extack=0xffffc90000ba7af0, nlh=0xffff88800b1b7600, skb=0xffff88800b1f9f00, + family=0xffffffff82fef6c0 <seg6_genl_family>) at net/netlink/genetlink.c:775 + #3 genl_rcv_msg (skb=0xffff88800b1f9f00, nlh=0xffff88800b1b7600, extack=0xffffc90000ba7af0) at net/netlink/genetlink.c:792 + #4 0xffffffff81dfffc3 in netlink_rcv_skb (skb=skb@entry=0xffff88800b1f9f00, cb=cb@entry=0xffffffff81e01350 <genl_rcv_msg>) + at net/netlink/af_netlink.c:2501 + #5 0xffffffff81e00919 in genl_rcv (skb=0xffff88800b1f9f00) at net/netlink/genetlink.c:803 + #6 0xffffffff81dff6ae in netlink_unicast_kernel (ssk=0xffff888010eec800, skb=0xffff88800b1f9f00, sk=0xffff888004aed000) + at net/netlink/af_netlink.c:1319 + #7 netlink_unicast (ssk=ssk@entry=0xffff888010eec800, skb=skb@entry=0xffff88800b1f9f00, portid=portid@entry=0, nonblock=<optimized out>) + at net/netlink/af_netlink.c:1345 + #8 0xffffffff81dff9a4 in netlink_sendmsg (sock=<optimized out>, msg=0xffffc90000ba7e48, len=<optimized out>) at net/netlink/af_netlink.c:1921 +... +(gdb) p/x ((struct sk_buff *)0xffff88800b1f9f00)->head + ((struct sk_buff *)0xffff88800b1f9f00)->end +$1 = 0xffff88800b1b76c0 +(gdb) p/x secret +$2 = 0xffff88800b1b76c0 +(gdb) p slen +$3 = 64 '@' + +The OOB data can then be read back from userspace by dumping HMAC state. This +commit fixes this by ensuring SECRETLEN cannot exceed the actual length of +SECRET. + +Reported-by: Lucas Leong <wmliang.tw@gmail.com> +Tested: verified that EINVAL is correctly returned when secretlen > len(secret) +Fixes: 4f4853dc1c9c1 ("ipv6: sr: implement API to control SR HMAC structure") +Signed-off-by: David Lebrun <dlebrun@google.com> +Signed-off-by: David S. Miller <davem@davemloft.net> +--- + net/ipv6/seg6.c | 5 +++++ + 1 file changed, 5 insertions(+) + +diff --git a/net/ipv6/seg6.c b/net/ipv6/seg6.c +index 73aaabf0e9665..0b0e34ddc64e0 100644 +--- a/net/ipv6/seg6.c ++++ b/net/ipv6/seg6.c +@@ -191,6 +191,11 @@ static int seg6_genl_sethmac(struct sk_buff *skb, struct genl_info *info) + goto out_unlock; + } + ++ if (slen > nla_len(info->attrs[SEG6_ATTR_SECRET])) { ++ err = -EINVAL; ++ goto out_unlock; ++ } ++ + if (hinfo) { + err = seg6_hmac_info_del(net, hmackeyid); + if (err) +-- +cgit + diff --git a/meta-openbmc-mods/meta-common/recipes-kernel/linux/linux-aspeed/CVE-2023-31085.patch b/meta-openbmc-mods/meta-common/recipes-kernel/linux/linux-aspeed/CVE-2023-31085.patch new file mode 100644 index 000000000..ddf4ded54 --- /dev/null +++ b/meta-openbmc-mods/meta-common/recipes-kernel/linux/linux-aspeed/CVE-2023-31085.patch @@ -0,0 +1,40 @@ +From 017c73a34a661a861712f7cc1393a123e5b2208c Mon Sep 17 00:00:00 2001 +From: Zhihao Cheng <chengzhihao1@huawei.com> +Date: Sun, 23 Apr 2023 19:10:41 +0800 +Subject: ubi: Refuse attaching if mtd's erasesize is 0 + +There exists mtd devices with zero erasesize, which will trigger a +divide-by-zero exception while attaching ubi device. +Fix it by refusing attaching if mtd's erasesize is 0. + +Fixes: 801c135ce73d ("UBI: Unsorted Block Images") +Reported-by: Yu Hao <yhao016@ucr.edu> +Link: https://lore.kernel.org/lkml/977347543.226888.1682011999468.JavaMail.zimbra@nod.at/T/ +Signed-off-by: Zhihao Cheng <chengzhihao1@huawei.com> +Reviewed-by: Miquel Raynal <miquel.raynal@bootlin.com> +Signed-off-by: Richard Weinberger <richard@nod.at> +--- + drivers/mtd/ubi/build.c | 7 +++++++ + 1 file changed, 7 insertions(+) + +diff --git a/drivers/mtd/ubi/build.c b/drivers/mtd/ubi/build.c +index 8b91a55ec0d28..8ee51e49fced5 100644 +--- a/drivers/mtd/ubi/build.c ++++ b/drivers/mtd/ubi/build.c +@@ -894,6 +894,13 @@ int ubi_attach_mtd_dev(struct mtd_info *mtd, int ubi_num, + return -EINVAL; + } + ++ /* UBI cannot work on flashes with zero erasesize. */ ++ if (!mtd->erasesize) { ++ pr_err("ubi: refuse attaching mtd%d - zero erasesize flash is not supported\n", ++ mtd->index); ++ return -EINVAL; ++ } ++ + if (ubi_num == UBI_DEV_NUM_AUTO) { + /* Search for an empty slot in the @ubi_devices array */ + for (ubi_num = 0; ubi_num < UBI_MAX_DEVICES; ubi_num++) +-- +cgit + diff --git a/meta-openbmc-mods/meta-common/recipes-kernel/linux/linux-aspeed/CVE-2023-34256.patch b/meta-openbmc-mods/meta-common/recipes-kernel/linux/linux-aspeed/CVE-2023-34256.patch new file mode 100644 index 000000000..60dc63406 --- /dev/null +++ b/meta-openbmc-mods/meta-common/recipes-kernel/linux/linux-aspeed/CVE-2023-34256.patch @@ -0,0 +1,99 @@ +From 4f04351888a83e595571de672e0a4a8b74f4fb31 Mon Sep 17 00:00:00 2001 +From: Tudor Ambarus <tudor.ambarus@linaro.org> +Date: Thu, 4 May 2023 12:15:25 +0000 +Subject: ext4: avoid a potential slab-out-of-bounds in ext4_group_desc_csum + +When modifying the block device while it is mounted by the filesystem, +syzbot reported the following: + +BUG: KASAN: slab-out-of-bounds in crc16+0x206/0x280 lib/crc16.c:58 +Read of size 1 at addr ffff888075f5c0a8 by task syz-executor.2/15586 + +CPU: 1 PID: 15586 Comm: syz-executor.2 Not tainted 6.2.0-rc5-syzkaller-00205-gc96618275234 #0 +Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/12/2023 +Call Trace: + <TASK> + __dump_stack lib/dump_stack.c:88 [inline] + dump_stack_lvl+0x1b1/0x290 lib/dump_stack.c:106 + print_address_description+0x74/0x340 mm/kasan/report.c:306 + print_report+0x107/0x1f0 mm/kasan/report.c:417 + kasan_report+0xcd/0x100 mm/kasan/report.c:517 + crc16+0x206/0x280 lib/crc16.c:58 + ext4_group_desc_csum+0x81b/0xb20 fs/ext4/super.c:3187 + ext4_group_desc_csum_set+0x195/0x230 fs/ext4/super.c:3210 + ext4_mb_clear_bb fs/ext4/mballoc.c:6027 [inline] + ext4_free_blocks+0x191a/0x2810 fs/ext4/mballoc.c:6173 + ext4_remove_blocks fs/ext4/extents.c:2527 [inline] + ext4_ext_rm_leaf fs/ext4/extents.c:2710 [inline] + ext4_ext_remove_space+0x24ef/0x46a0 fs/ext4/extents.c:2958 + ext4_ext_truncate+0x177/0x220 fs/ext4/extents.c:4416 + ext4_truncate+0xa6a/0xea0 fs/ext4/inode.c:4342 + ext4_setattr+0x10c8/0x1930 fs/ext4/inode.c:5622 + notify_change+0xe50/0x1100 fs/attr.c:482 + do_truncate+0x200/0x2f0 fs/open.c:65 + handle_truncate fs/namei.c:3216 [inline] + do_open fs/namei.c:3561 [inline] + path_openat+0x272b/0x2dd0 fs/namei.c:3714 + do_filp_open+0x264/0x4f0 fs/namei.c:3741 + do_sys_openat2+0x124/0x4e0 fs/open.c:1310 + do_sys_open fs/open.c:1326 [inline] + __do_sys_creat fs/open.c:1402 [inline] + __se_sys_creat fs/open.c:1396 [inline] + __x64_sys_creat+0x11f/0x160 fs/open.c:1396 + do_syscall_x64 arch/x86/entry/common.c:50 [inline] + do_syscall_64+0x3d/0xb0 arch/x86/entry/common.c:80 + entry_SYSCALL_64_after_hwframe+0x63/0xcd +RIP: 0033:0x7f72f8a8c0c9 +Code: 28 00 00 00 75 05 48 83 c4 28 c3 e8 f1 19 00 00 90 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 b8 ff ff ff f7 d8 64 89 01 48 +RSP: 002b:00007f72f97e3168 EFLAGS: 00000246 ORIG_RAX: 0000000000000055 +RAX: ffffffffffffffda RBX: 00007f72f8bac050 RCX: 00007f72f8a8c0c9 +RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000020000280 +RBP: 00007f72f8ae7ae9 R08: 0000000000000000 R09: 0000000000000000 +R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000 +R13: 00007ffd165348bf R14: 00007f72f97e3300 R15: 0000000000022000 + +Replace + le16_to_cpu(sbi->s_es->s_desc_size) +with + sbi->s_desc_size + +It reduces ext4's compiled text size, and makes the code more efficient +(we remove an extra indirect reference and a potential byte +swap on big endian systems), and there is no downside. It also avoids the +potential KASAN / syzkaller failure, as a bonus. + +Reported-by: syzbot+fc51227e7100c9294894@syzkaller.appspotmail.com +Reported-by: syzbot+8785e41224a3afd04321@syzkaller.appspotmail.com +Link: https://syzkaller.appspot.com/bug?id=70d28d11ab14bd7938f3e088365252aa923cff42 +Link: https://syzkaller.appspot.com/bug?id=b85721b38583ecc6b5e72ff524c67302abbc30f3 +Link: https://lore.kernel.org/all/000000000000ece18705f3b20934@google.com/ +Fixes: 717d50e4971b ("Ext4: Uninitialized Block Groups") +Cc: stable@vger.kernel.org +Signed-off-by: Tudor Ambarus <tudor.ambarus@linaro.org> +Link: https://lore.kernel.org/r/20230504121525.3275886-1-tudor.ambarus@linaro.org +Signed-off-by: Theodore Ts'o <tytso@mit.edu> +--- + fs/ext4/super.c | 6 ++---- + 1 file changed, 2 insertions(+), 4 deletions(-) + +diff --git a/fs/ext4/super.c b/fs/ext4/super.c +index 4037c8611c02e..425b95a7a0ab6 100644 +--- a/fs/ext4/super.c ++++ b/fs/ext4/super.c +@@ -3240,11 +3240,9 @@ static __le16 ext4_group_desc_csum(struct super_block *sb, __u32 block_group, + crc = crc16(crc, (__u8 *)gdp, offset); + offset += sizeof(gdp->bg_checksum); /* skip checksum */ + /* for checksum of struct ext4_group_desc do the rest...*/ +- if (ext4_has_feature_64bit(sb) && +- offset < le16_to_cpu(sbi->s_es->s_desc_size)) ++ if (ext4_has_feature_64bit(sb) && offset < sbi->s_desc_size) + crc = crc16(crc, (__u8 *)gdp + offset, +- le16_to_cpu(sbi->s_es->s_desc_size) - +- offset); ++ sbi->s_desc_size - offset); + + out: + return cpu_to_le16(crc); +-- +cgit 1.2.3-korg + diff --git a/meta-openbmc-mods/meta-common/recipes-kernel/linux/linux-aspeed/CVE-2023-4004.patch b/meta-openbmc-mods/meta-common/recipes-kernel/linux/linux-aspeed/CVE-2023-4004.patch new file mode 100644 index 000000000..d1498f247 --- /dev/null +++ b/meta-openbmc-mods/meta-common/recipes-kernel/linux/linux-aspeed/CVE-2023-4004.patch @@ -0,0 +1,58 @@ +From 87b5a5c209405cb6b57424cdfa226a6dbd349232 Mon Sep 17 00:00:00 2001 +From: Florian Westphal <fw@strlen.de> +Date: Wed, 19 Jul 2023 21:08:21 +0200 +Subject: netfilter: nft_set_pipapo: fix improper element removal + +end key should be equal to start unless NFT_SET_EXT_KEY_END is present. + +Its possible to add elements that only have a start key +("{ 1.0.0.0 . 2.0.0.0 }") without an internval end. + +Insertion treats this via: + +if (nft_set_ext_exists(ext, NFT_SET_EXT_KEY_END)) + end = (const u8 *)nft_set_ext_key_end(ext)->data; +else + end = start; + +but removal side always uses nft_set_ext_key_end(). +This is wrong and leads to garbage remaining in the set after removal +next lookup/insert attempt will give: + +BUG: KASAN: slab-use-after-free in pipapo_get+0x8eb/0xb90 +Read of size 1 at addr ffff888100d50586 by task nft-pipapo_uaf_/1399 +Call Trace: + kasan_report+0x105/0x140 + pipapo_get+0x8eb/0xb90 + nft_pipapo_insert+0x1dc/0x1710 + nf_tables_newsetelem+0x31f5/0x4e00 + .. + +Fixes: 3c4287f62044 ("nf_tables: Add set type for arbitrary concatenation of ranges") +Reported-by: lonial con <kongln9170@gmail.com> +Reviewed-by: Stefano Brivio <sbrivio@redhat.com> +Signed-off-by: Florian Westphal <fw@strlen.de> +--- + net/netfilter/nft_set_pipapo.c | 6 +++++- + 1 file changed, 5 insertions(+), 1 deletion(-) + +diff --git a/net/netfilter/nft_set_pipapo.c b/net/netfilter/nft_set_pipapo.c +index db526cb7a4858..49915a2a58eb7 100644 +--- a/net/netfilter/nft_set_pipapo.c ++++ b/net/netfilter/nft_set_pipapo.c +@@ -1929,7 +1929,11 @@ static void nft_pipapo_remove(const struct net *net, const struct nft_set *set, + int i, start, rules_fx; + + match_start = data; +- match_end = (const u8 *)nft_set_ext_key_end(&e->ext)->data; ++ ++ if (nft_set_ext_exists(&e->ext, NFT_SET_EXT_KEY_END)) ++ match_end = (const u8 *)nft_set_ext_key_end(&e->ext)->data; ++ else ++ match_end = data; + + start = first_rule; + rules_fx = rules_f0; +-- +cgit + diff --git a/meta-openbmc-mods/meta-common/recipes-kernel/linux/linux-aspeed/CVE-2023-42754.patch b/meta-openbmc-mods/meta-common/recipes-kernel/linux/linux-aspeed/CVE-2023-42754.patch new file mode 100644 index 000000000..f16fa3f86 --- /dev/null +++ b/meta-openbmc-mods/meta-common/recipes-kernel/linux/linux-aspeed/CVE-2023-42754.patch @@ -0,0 +1,48 @@ +From 0113d9c9d1ccc07f5a3710dac4aa24b6d711278c Mon Sep 17 00:00:00 2001 +From: Kyle Zeng <zengyhkyle@gmail.com> +Date: Thu, 14 Sep 2023 22:12:57 -0700 +Subject: ipv4: fix null-deref in ipv4_link_failure + +Currently, we assume the skb is associated with a device before calling +__ip_options_compile, which is not always the case if it is re-routed by +ipvs. +When skb->dev is NULL, dev_net(skb->dev) will become null-dereference. +This patch adds a check for the edge case and switch to use the net_device +from the rtable when skb->dev is NULL. + +Fixes: ed0de45a1008 ("ipv4: recompile ip options in ipv4_link_failure") +Suggested-by: David Ahern <dsahern@kernel.org> +Signed-off-by: Kyle Zeng <zengyhkyle@gmail.com> +Cc: Stephen Suryaputra <ssuryaextr@gmail.com> +Cc: Vadim Fedorenko <vfedorenko@novek.ru> +Reviewed-by: David Ahern <dsahern@kernel.org> +Signed-off-by: David S. Miller <davem@davemloft.net> +--- + net/ipv4/route.c | 4 +++- + 1 file changed, 3 insertions(+), 1 deletion(-) + +diff --git a/net/ipv4/route.c b/net/ipv4/route.c +index 66f419e7f9a7f..a570622832196 100644 +--- a/net/ipv4/route.c ++++ b/net/ipv4/route.c +@@ -1213,6 +1213,7 @@ EXPORT_INDIRECT_CALLABLE(ipv4_dst_check); + + static void ipv4_send_dest_unreach(struct sk_buff *skb) + { ++ struct net_device *dev; + struct ip_options opt; + int res; + +@@ -1230,7 +1231,8 @@ static void ipv4_send_dest_unreach(struct sk_buff *skb) + opt.optlen = ip_hdr(skb)->ihl * 4 - sizeof(struct iphdr); + + rcu_read_lock(); +- res = __ip_options_compile(dev_net(skb->dev), &opt, skb, NULL); ++ dev = skb->dev ? skb->dev : skb_rtable(skb)->dst.dev; ++ res = __ip_options_compile(dev_net(dev), &opt, skb, NULL); + rcu_read_unlock(); + + if (res) +-- +cgit 1.2.3-korg + diff --git a/meta-openbmc-mods/meta-common/recipes-kernel/linux/linux-aspeed/CVE-2023-45863.patch b/meta-openbmc-mods/meta-common/recipes-kernel/linux/linux-aspeed/CVE-2023-45863.patch new file mode 100644 index 000000000..217b45022 --- /dev/null +++ b/meta-openbmc-mods/meta-common/recipes-kernel/linux/linux-aspeed/CVE-2023-45863.patch @@ -0,0 +1,143 @@ +From 3bb2a01caa813d3a1845d378bbe4169ef280d394 Mon Sep 17 00:00:00 2001 +From: Wang Hai <wanghai38@huawei.com> +Date: Tue, 20 Dec 2022 09:21:43 +0800 +Subject: kobject: Fix slab-out-of-bounds in fill_kobj_path() + +In kobject_get_path(), if kobj->name is changed between calls +get_kobj_path_length() and fill_kobj_path() and the length becomes +longer, then fill_kobj_path() will have an out-of-bounds bug. + +The actual current problem occurs when the ixgbe probe. + +In ixgbe_mii_bus_init(), if the length of netdev->dev.kobj.name +length becomes longer, out-of-bounds will occur. + +cpu0 cpu1 +ixgbe_probe + register_netdev(netdev) + netdev_register_kobject + device_add + kobject_uevent // Sending ADD events + systemd-udevd // rename netdev + dev_change_name + device_rename + kobject_rename + ixgbe_mii_bus_init | + mdiobus_register | + __mdiobus_register | + device_register | + device_add | + kobject_uevent | + kobject_get_path | + len = get_kobj_path_length // old name | + path = kzalloc(len, gfp_mask); | + kobj->name = name; + /* name length becomes + * longer + */ + fill_kobj_path /* kobj path length is + * longer than path, + * resulting in out of + * bounds when filling path + */ + +This is the kasan report: + +================================================================== +BUG: KASAN: slab-out-of-bounds in fill_kobj_path+0x50/0xc0 +Write of size 7 at addr ff1100090573d1fd by task kworker/28:1/673 + + Workqueue: events work_for_cpu_fn + Call Trace: + <TASK> + dump_stack_lvl+0x34/0x48 + print_address_description.constprop.0+0x86/0x1e7 + print_report+0x36/0x4f + kasan_report+0xad/0x130 + kasan_check_range+0x35/0x1c0 + memcpy+0x39/0x60 + fill_kobj_path+0x50/0xc0 + kobject_get_path+0x5a/0xc0 + kobject_uevent_env+0x140/0x460 + device_add+0x5c7/0x910 + __mdiobus_register+0x14e/0x490 + ixgbe_probe.cold+0x441/0x574 [ixgbe] + local_pci_probe+0x78/0xc0 + work_for_cpu_fn+0x26/0x40 + process_one_work+0x3b6/0x6a0 + worker_thread+0x368/0x520 + kthread+0x165/0x1a0 + ret_from_fork+0x1f/0x30 + +This reproducer triggers that bug: + +while: +do + rmmod ixgbe + sleep 0.5 + modprobe ixgbe + sleep 0.5 + +When calling fill_kobj_path() to fill path, if the name length of +kobj becomes longer, return failure and retry. This fixes the problem. + +Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") +Signed-off-by: Wang Hai <wanghai38@huawei.com> +Link: https://lore.kernel.org/r/20221220012143.52141-1-wanghai38@huawei.com +Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> +--- + lib/kobject.c | 12 ++++++++++-- + 1 file changed, 10 insertions(+), 2 deletions(-) + +diff --git a/lib/kobject.c b/lib/kobject.c +index ea53b30cf483..a2604e0fc66b 100644 +--- a/lib/kobject.c ++++ b/lib/kobject.c +@@ -144,7 +144,7 @@ static int get_kobj_path_length(struct kobject *kobj) + return length; + } + +-static void fill_kobj_path(struct kobject *kobj, char *path, int length) ++static int fill_kobj_path(struct kobject *kobj, char *path, int length) + { + struct kobject *parent; + +@@ -153,12 +153,16 @@ static void fill_kobj_path(struct kobject *kobj, char *path, int length) + int cur = strlen(kobject_name(parent)); + /* back up enough to print this name with '/' */ + length -= cur; ++ if (length <= 0) ++ return -EINVAL; + memcpy(path + length, kobject_name(parent), cur); + *(path + --length) = '/'; + } + + pr_debug("kobject: '%s' (%p): %s: path = '%s'\n", kobject_name(kobj), + kobj, __func__, path); ++ ++ return 0; + } + + /** +@@ -173,13 +177,17 @@ char *kobject_get_path(struct kobject *kobj, gfp_t gfp_mask) + char *path; + int len; + ++retry: + len = get_kobj_path_length(kobj); + if (len == 0) + return NULL; + path = kzalloc(len, gfp_mask); + if (!path) + return NULL; +- fill_kobj_path(kobj, path, len); ++ if (fill_kobj_path(kobj, path, len)) { ++ kfree(path); ++ goto retry; ++ } + + return path; + } +-- +cgit 1.2.3-korg + diff --git a/meta-openbmc-mods/meta-common/recipes-kernel/linux/linux-aspeed/CVE-2023-5178.patch b/meta-openbmc-mods/meta-common/recipes-kernel/linux/linux-aspeed/CVE-2023-5178.patch new file mode 100644 index 000000000..6265d8c36 --- /dev/null +++ b/meta-openbmc-mods/meta-common/recipes-kernel/linux/linux-aspeed/CVE-2023-5178.patch @@ -0,0 +1,61 @@ +From d920abd1e7c4884f9ecd0749d1921b7ab19ddfbd Mon Sep 17 00:00:00 2001 +From: Sagi Grimberg <sagi@grimberg.me> +Date: Mon, 2 Oct 2023 13:54:28 +0300 +Subject: nvmet-tcp: Fix a possible UAF in queue intialization setup + +From Alon: +"Due to a logical bug in the NVMe-oF/TCP subsystem in the Linux kernel, +a malicious user can cause a UAF and a double free, which may lead to +RCE (may also lead to an LPE in case the attacker already has local +privileges)." + +Hence, when a queue initialization fails after the ahash requests are +allocated, it is guaranteed that the queue removal async work will be +called, hence leave the deallocation to the queue removal. + +Also, be extra careful not to continue processing the socket, so set +queue rcv_state to NVMET_TCP_RECV_ERR upon a socket error. + +Cc: stable@vger.kernel.org +Reported-by: Alon Zahavi <zahavi.alon@gmail.com> +Tested-by: Alon Zahavi <zahavi.alon@gmail.com> +Signed-off-by: Sagi Grimberg <sagi@grimberg.me> +Reviewed-by: Christoph Hellwig <hch@lst.de> +Reviewed-by: Chaitanya Kulkarni <kch@nvidia.com> +Signed-off-by: Keith Busch <kbusch@kernel.org> +--- + drivers/nvme/target/tcp.c | 7 ++----- + 1 file changed, 2 insertions(+), 5 deletions(-) + +diff --git a/drivers/nvme/target/tcp.c b/drivers/nvme/target/tcp.c +index cd92d7ddf5ed1..197fc2ecb164d 100644 +--- a/drivers/nvme/target/tcp.c ++++ b/drivers/nvme/target/tcp.c +@@ -372,6 +372,7 @@ static void nvmet_tcp_fatal_error(struct nvmet_tcp_queue *queue) + + static void nvmet_tcp_socket_error(struct nvmet_tcp_queue *queue, int status) + { ++ queue->rcv_state = NVMET_TCP_RECV_ERR; + if (status == -EPIPE || status == -ECONNRESET) + kernel_sock_shutdown(queue->sock, SHUT_RDWR); + else +@@ -910,15 +911,11 @@ static int nvmet_tcp_handle_icreq(struct nvmet_tcp_queue *queue) + iov.iov_len = sizeof(*icresp); + ret = kernel_sendmsg(queue->sock, &msg, &iov, 1, iov.iov_len); + if (ret < 0) +- goto free_crypto; ++ return ret; /* queue removal will cleanup */ + + queue->state = NVMET_TCP_Q_LIVE; + nvmet_prepare_receive_pdu(queue); + return 0; +-free_crypto: +- if (queue->hdr_digest || queue->data_digest) +- nvmet_tcp_free_crypto(queue); +- return ret; + } + + static void nvmet_tcp_handle_req_failure(struct nvmet_tcp_queue *queue, +-- +cgit 1.2.3-korg + diff --git a/meta-openbmc-mods/meta-common/recipes-kernel/linux/linux-aspeed/CVE-2023-52435.patch b/meta-openbmc-mods/meta-common/recipes-kernel/linux/linux-aspeed/CVE-2023-52435.patch new file mode 100644 index 000000000..bd9549c73 --- /dev/null +++ b/meta-openbmc-mods/meta-common/recipes-kernel/linux/linux-aspeed/CVE-2023-52435.patch @@ -0,0 +1,115 @@ +From 6c53e8547687d9c767c139cd4b50af566f58c29a Mon Sep 17 00:00:00 2001 +From: Eric Dumazet <edumazet@google.com> +Date: Tue, 12 Dec 2023 16:46:21 +0000 +Subject: net: prevent mss overflow in skb_segment() + +commit 23d05d563b7e7b0314e65c8e882bc27eac2da8e7 upstream. + +Once again syzbot is able to crash the kernel in skb_segment() [1] + +GSO_BY_FRAGS is a forbidden value, but unfortunately the following +computation in skb_segment() can reach it quite easily : + + mss = mss * partial_segs; + +65535 = 3 * 5 * 17 * 257, so many initial values of mss can lead to +a bad final result. + +Make sure to limit segmentation so that the new mss value is smaller +than GSO_BY_FRAGS. + +[1] + +general protection fault, probably for non-canonical address 0xdffffc000000000e: 0000 [#1] PREEMPT SMP KASAN +KASAN: null-ptr-deref in range [0x0000000000000070-0x0000000000000077] +CPU: 1 PID: 5079 Comm: syz-executor993 Not tainted 6.7.0-rc4-syzkaller-00141-g1ae4cd3cbdd0 #0 +Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 11/10/2023 +RIP: 0010:skb_segment+0x181d/0x3f30 net/core/skbuff.c:4551 +Code: 83 e3 02 e9 fb ed ff ff e8 90 68 1c f9 48 8b 84 24 f8 00 00 00 48 8d 78 70 48 b8 00 00 00 00 00 fc ff df 48 89 fa 48 c1 ea 03 <0f> b6 04 02 84 c0 74 08 3c 03 0f 8e 8a 21 00 00 48 8b 84 24 f8 00 +RSP: 0018:ffffc900043473d0 EFLAGS: 00010202 +RAX: dffffc0000000000 RBX: 0000000000010046 RCX: ffffffff886b1597 +RDX: 000000000000000e RSI: ffffffff886b2520 RDI: 0000000000000070 +RBP: ffffc90004347578 R08: 0000000000000005 R09: 000000000000ffff +R10: 000000000000ffff R11: 0000000000000002 R12: ffff888063202ac0 +R13: 0000000000010000 R14: 000000000000ffff R15: 0000000000000046 +FS: 0000555556e7e380(0000) GS:ffff8880b9900000(0000) knlGS:0000000000000000 +CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 +CR2: 0000000020010000 CR3: 0000000027ee2000 CR4: 00000000003506f0 +DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 +DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 +Call Trace: +<TASK> +udp6_ufo_fragment+0xa0e/0xd00 net/ipv6/udp_offload.c:109 +ipv6_gso_segment+0x534/0x17e0 net/ipv6/ip6_offload.c:120 +skb_mac_gso_segment+0x290/0x610 net/core/gso.c:53 +__skb_gso_segment+0x339/0x710 net/core/gso.c:124 +skb_gso_segment include/net/gso.h:83 [inline] +validate_xmit_skb+0x36c/0xeb0 net/core/dev.c:3626 +__dev_queue_xmit+0x6f3/0x3d60 net/core/dev.c:4338 +dev_queue_xmit include/linux/netdevice.h:3134 [inline] +packet_xmit+0x257/0x380 net/packet/af_packet.c:276 +packet_snd net/packet/af_packet.c:3087 [inline] +packet_sendmsg+0x24c6/0x5220 net/packet/af_packet.c:3119 +sock_sendmsg_nosec net/socket.c:730 [inline] +__sock_sendmsg+0xd5/0x180 net/socket.c:745 +__sys_sendto+0x255/0x340 net/socket.c:2190 +__do_sys_sendto net/socket.c:2202 [inline] +__se_sys_sendto net/socket.c:2198 [inline] +__x64_sys_sendto+0xe0/0x1b0 net/socket.c:2198 +do_syscall_x64 arch/x86/entry/common.c:52 [inline] +do_syscall_64+0x40/0x110 arch/x86/entry/common.c:83 +entry_SYSCALL_64_after_hwframe+0x63/0x6b +RIP: 0033:0x7f8692032aa9 +Code: 28 00 00 00 75 05 48 83 c4 28 c3 e8 d1 19 00 00 90 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 b8 ff ff ff f7 d8 64 89 01 48 +RSP: 002b:00007fff8d685418 EFLAGS: 00000246 ORIG_RAX: 000000000000002c +RAX: ffffffffffffffda RBX: 0000000000000003 RCX: 00007f8692032aa9 +RDX: 0000000000010048 RSI: 00000000200000c0 RDI: 0000000000000003 +RBP: 00000000000f4240 R08: 0000000020000540 R09: 0000000000000014 +R10: 0000000000000000 R11: 0000000000000246 R12: 00007fff8d685480 +R13: 0000000000000001 R14: 00007fff8d685480 R15: 0000000000000003 +</TASK> +Modules linked in: +---[ end trace 0000000000000000 ]--- +RIP: 0010:skb_segment+0x181d/0x3f30 net/core/skbuff.c:4551 +Code: 83 e3 02 e9 fb ed ff ff e8 90 68 1c f9 48 8b 84 24 f8 00 00 00 48 8d 78 70 48 b8 00 00 00 00 00 fc ff df 48 89 fa 48 c1 ea 03 <0f> b6 04 02 84 c0 74 08 3c 03 0f 8e 8a 21 00 00 48 8b 84 24 f8 00 +RSP: 0018:ffffc900043473d0 EFLAGS: 00010202 +RAX: dffffc0000000000 RBX: 0000000000010046 RCX: ffffffff886b1597 +RDX: 000000000000000e RSI: ffffffff886b2520 RDI: 0000000000000070 +RBP: ffffc90004347578 R08: 0000000000000005 R09: 000000000000ffff +R10: 000000000000ffff R11: 0000000000000002 R12: ffff888063202ac0 +R13: 0000000000010000 R14: 000000000000ffff R15: 0000000000000046 +FS: 0000555556e7e380(0000) GS:ffff8880b9900000(0000) knlGS:0000000000000000 +CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 +CR2: 0000000020010000 CR3: 0000000027ee2000 CR4: 00000000003506f0 +DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 +DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 + +Fixes: 3953c46c3ac7 ("sk_buff: allow segmenting based on frag sizes") +Signed-off-by: Eric Dumazet <edumazet@google.com> +Cc: Marcelo Ricardo Leitner <marcelo.leitner@gmail.com> +Reviewed-by: Willem de Bruijn <willemb@google.com> +Link: https://lore.kernel.org/r/20231212164621.4131800-1-edumazet@google.com +Signed-off-by: Jakub Kicinski <kuba@kernel.org> +Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> +--- + net/core/skbuff.c | 3 ++- + 1 file changed, 2 insertions(+), 1 deletion(-) + +diff --git a/net/core/skbuff.c b/net/core/skbuff.c +index 7090844af4991a..3dbefce8d14b7f 100644 +--- a/net/core/skbuff.c ++++ b/net/core/skbuff.c +@@ -4079,8 +4079,9 @@ struct sk_buff *skb_segment(struct sk_buff *head_skb, + /* GSO partial only requires that we trim off any excess that + * doesn't fit into an MSS sized block, so take care of that + * now. ++ * Cap len to not accidentally hit GSO_BY_FRAGS. + */ +- partial_segs = len / mss; ++ partial_segs = min(len, GSO_BY_FRAGS - 1U) / mss; + if (partial_segs > 1) + mss *= partial_segs; + else +-- +cgit 1.2.3-korg + diff --git a/meta-openbmc-mods/meta-common/recipes-kernel/linux/linux-aspeed/CVE-2023-52449.patch b/meta-openbmc-mods/meta-common/recipes-kernel/linux/linux-aspeed/CVE-2023-52449.patch new file mode 100644 index 000000000..ebae2414a --- /dev/null +++ b/meta-openbmc-mods/meta-common/recipes-kernel/linux/linux-aspeed/CVE-2023-52449.patch @@ -0,0 +1,83 @@ +From 5389407bba1eab1266c6d83e226fb0840cb98dd5 Mon Sep 17 00:00:00 2001 +From: ZhaoLong Wang <wangzhaolong1@huawei.com> +Date: Wed, 20 Dec 2023 10:46:19 +0800 +Subject: mtd: Fix gluebi NULL pointer dereference caused by ftl notifier +MIME-Version: 1.0 +Content-Type: text/plain; charset=UTF-8 +Content-Transfer-Encoding: 8bit + +[ Upstream commit a43bdc376deab5fff1ceb93dca55bcab8dbdc1d6 ] + +If both ftl.ko and gluebi.ko are loaded, the notifier of ftl +triggers NULL pointer dereference when trying to access +‘gluebi->desc’ in gluebi_read(). + +ubi_gluebi_init + ubi_register_volume_notifier + ubi_enumerate_volumes + ubi_notify_all + gluebi_notify nb->notifier_call() + gluebi_create + mtd_device_register + mtd_device_parse_register + add_mtd_device + blktrans_notify_add not->add() + ftl_add_mtd tr->add_mtd() + scan_header + mtd_read + mtd_read_oob + mtd_read_oob_std + gluebi_read mtd->read() + gluebi->desc - NULL + +Detailed reproduction information available at the Link [1], + +In the normal case, obtain gluebi->desc in the gluebi_get_device(), +and access gluebi->desc in the gluebi_read(). However, +gluebi_get_device() is not executed in advance in the +ftl_add_mtd() process, which leads to NULL pointer dereference. + +The solution for the gluebi module is to run jffs2 on the UBI +volume without considering working with ftl or mtdblock [2]. +Therefore, this problem can be avoided by preventing gluebi from +creating the mtdblock device after creating mtd partition of the +type MTD_UBIVOLUME. + +Fixes: 2ba3d76a1e29 ("UBI: make gluebi a separate module") +Link: https://bugzilla.kernel.org/show_bug.cgi?id=217992 [1] +Link: https://lore.kernel.org/lkml/441107100.23734.1697904580252.JavaMail.zimbra@nod.at/ [2] +Signed-off-by: ZhaoLong Wang <wangzhaolong1@huawei.com> +Reviewed-by: Zhihao Cheng <chengzhihao1@huawei.com> +Acked-by: Richard Weinberger <richard@nod.at> +Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com> +Link: https://lore.kernel.org/linux-mtd/20231220024619.2138625-1-wangzhaolong1@huawei.com +Signed-off-by: Sasha Levin <sashal@kernel.org> +--- + drivers/mtd/mtd_blkdevs.c | 4 ++-- + 1 file changed, 2 insertions(+), 2 deletions(-) + +diff --git a/drivers/mtd/mtd_blkdevs.c b/drivers/mtd/mtd_blkdevs.c +index 60b222799871e8..8ee60605a6dcc3 100644 +--- a/drivers/mtd/mtd_blkdevs.c ++++ b/drivers/mtd/mtd_blkdevs.c +@@ -463,7 +463,7 @@ static void blktrans_notify_add(struct mtd_info *mtd) + { + struct mtd_blktrans_ops *tr; + +- if (mtd->type == MTD_ABSENT) ++ if (mtd->type == MTD_ABSENT || mtd->type == MTD_UBIVOLUME) + return; + + list_for_each_entry(tr, &blktrans_majors, list) +@@ -503,7 +503,7 @@ int register_mtd_blktrans(struct mtd_blktrans_ops *tr) + mutex_lock(&mtd_table_mutex); + list_add(&tr->list, &blktrans_majors); + mtd_for_each_device(mtd) +- if (mtd->type != MTD_ABSENT) ++ if (mtd->type != MTD_ABSENT && mtd->type != MTD_UBIVOLUME) + tr->add_mtd(tr, mtd); + mutex_unlock(&mtd_table_mutex); + return 0; +-- +cgit 1.2.3-korg + diff --git a/meta-openbmc-mods/meta-common/recipes-kernel/linux/linux-aspeed/CVE-2023-52458.patch b/meta-openbmc-mods/meta-common/recipes-kernel/linux/linux-aspeed/CVE-2023-52458.patch new file mode 100644 index 000000000..667131aa2 --- /dev/null +++ b/meta-openbmc-mods/meta-common/recipes-kernel/linux/linux-aspeed/CVE-2023-52458.patch @@ -0,0 +1,67 @@ +From 8f6dfa1f1efe6dcca2d43e575491d8fcbe922f62 Mon Sep 17 00:00:00 2001 +From: Min Li <min15.li@samsung.com> +Date: Thu, 29 Jun 2023 14:25:17 +0000 +Subject: [PATCH] block: add check that partition length needs to be aligned + with block size + +commit 6f64f866aa1ae6975c95d805ed51d7e9433a0016 upstream. + +Before calling add partition or resize partition, there is no check +on whether the length is aligned with the logical block size. +If the logical block size of the disk is larger than 512 bytes, +then the partition size maybe not the multiple of the logical block size, +and when the last sector is read, bio_truncate() will adjust the bio size, +resulting in an IO error if the size of the read command is smaller than +the logical block size.If integrity data is supported, this will also +result in a null pointer dereference when calling bio_integrity_free. + +Cc: <stable@vger.kernel.org> +Signed-off-by: Min Li <min15.li@samsung.com> +Reviewed-by: Damien Le Moal <dlemoal@kernel.org> +Reviewed-by: Chaitanya Kulkarni <kch@nvidia.com> +Reviewed-by: Christoph Hellwig <hch@lst.de> +Link: https://lore.kernel.org/r/20230629142517.121241-1-min15.li@samsung.com +Signed-off-by: Jens Axboe <axboe@kernel.dk> +Signed-off-by: Ashwin Dayanand Kamat <ashwin.kamat@broadcom.com> +Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> +--- + block/ioctl.c | 11 +++++++---- + 1 file changed, 7 insertions(+), 4 deletions(-) + +diff --git a/block/ioctl.c b/block/ioctl.c +index eb0491e90b9a..7c7dd52e50c3 100644 +--- a/block/ioctl.c ++++ b/block/ioctl.c +@@ -18,7 +18,7 @@ static int blkpg_do_ioctl(struct block_device *bdev, + { + struct gendisk *disk = bdev->bd_disk; + struct blkpg_partition p; +- long long start, length; ++ sector_t start, length; + + if (!capable(CAP_SYS_ADMIN)) + return -EACCES; +@@ -33,14 +33,17 @@ static int blkpg_do_ioctl(struct block_device *bdev, + if (op == BLKPG_DEL_PARTITION) + return bdev_del_partition(disk, p.pno); + ++ if (p.start < 0 || p.length <= 0 || p.start + p.length < 0) ++ return -EINVAL; ++ /* Check that the partition is aligned to the block size */ ++ if (!IS_ALIGNED(p.start | p.length, bdev_logical_block_size(bdev))) ++ return -EINVAL; ++ + start = p.start >> SECTOR_SHIFT; + length = p.length >> SECTOR_SHIFT; + + switch (op) { + case BLKPG_ADD_PARTITION: +- /* check if partition is aligned to blocksize */ +- if (p.start & (bdev_logical_block_size(bdev) - 1)) +- return -EINVAL; + return bdev_add_partition(disk, p.pno, start, length); + case BLKPG_RESIZE_PARTITION: + return bdev_resize_partition(disk, p.pno, start, length); +-- +2.25.1 + diff --git a/meta-openbmc-mods/meta-common/recipes-kernel/linux/linux-aspeed/CVE-2023-52467.patch b/meta-openbmc-mods/meta-common/recipes-kernel/linux/linux-aspeed/CVE-2023-52467.patch new file mode 100644 index 000000000..4140fb2eb --- /dev/null +++ b/meta-openbmc-mods/meta-common/recipes-kernel/linux/linux-aspeed/CVE-2023-52467.patch @@ -0,0 +1,38 @@ +From 927626a2073887ee30ba00633260d4d203f8e875 Mon Sep 17 00:00:00 2001 +From: Kunwu Chan <chentao@kylinos.cn> +Date: Mon, 4 Dec 2023 17:24:43 +0800 +Subject: mfd: syscon: Fix null pointer dereference in of_syscon_register() + +[ Upstream commit 41673c66b3d0c09915698fec5c13b24336f18dd1 ] + +kasprintf() returns a pointer to dynamically allocated memory +which can be NULL upon failure. + +Fixes: e15d7f2b81d2 ("mfd: syscon: Use a unique name with regmap_config") +Signed-off-by: Kunwu Chan <chentao@kylinos.cn> +Reviewed-by: Arnd Bergmann <arnd@arndb.de> +Link: https://lore.kernel.org/r/20231204092443.2462115-1-chentao@kylinos.cn +Signed-off-by: Lee Jones <lee@kernel.org> +Signed-off-by: Sasha Levin <sashal@kernel.org> +--- + drivers/mfd/syscon.c | 4 ++++ + 1 file changed, 4 insertions(+) + +diff --git a/drivers/mfd/syscon.c b/drivers/mfd/syscon.c +index df5cebb372a592..60f74144a4f88e 100644 +--- a/drivers/mfd/syscon.c ++++ b/drivers/mfd/syscon.c +@@ -103,6 +103,10 @@ static struct syscon *of_syscon_register(struct device_node *np, bool check_clk) + + syscon_config.name = kasprintf(GFP_KERNEL, "%pOFn@%llx", np, + (u64)res.start); ++ if (!syscon_config.name) { ++ ret = -ENOMEM; ++ goto err_regmap; ++ } + syscon_config.reg_stride = reg_io_width; + syscon_config.val_bits = reg_io_width * 8; + syscon_config.max_register = resource_size(&res) - reg_io_width; +-- +cgit 1.2.3-korg + diff --git a/meta-openbmc-mods/meta-common/recipes-kernel/linux/linux-aspeed/CVE-2023-52522.patch b/meta-openbmc-mods/meta-common/recipes-kernel/linux/linux-aspeed/CVE-2023-52522.patch new file mode 100644 index 000000000..c89cd2ac5 --- /dev/null +++ b/meta-openbmc-mods/meta-common/recipes-kernel/linux/linux-aspeed/CVE-2023-52522.patch @@ -0,0 +1,46 @@ +From 2ea52a2fb8e87067e26bbab4efb8872639240eb0 Mon Sep 17 00:00:00 2001 +From: Eric Dumazet <edumazet@google.com> +Date: Thu, 21 Sep 2023 08:46:26 +0000 +Subject: net: fix possible store tearing in neigh_periodic_work() + +[ Upstream commit 25563b581ba3a1f263a00e8c9a97f5e7363be6fd ] + +While looking at a related syzbot report involving neigh_periodic_work(), +I found that I forgot to add an annotation when deleting an +RCU protected item from a list. + +Readers use rcu_deference(*np), we need to use either +rcu_assign_pointer() or WRITE_ONCE() on writer side +to prevent store tearing. + +I use rcu_assign_pointer() to have lockdep support, +this was the choice made in neigh_flush_dev(). + +Fixes: 767e97e1e0db ("neigh: RCU conversion of struct neighbour") +Signed-off-by: Eric Dumazet <edumazet@google.com> +Reviewed-by: David Ahern <dsahern@kernel.org> +Reviewed-by: Simon Horman <horms@kernel.org> +Signed-off-by: David S. Miller <davem@davemloft.net> +Signed-off-by: Sasha Levin <sashal@kernel.org> +--- + net/core/neighbour.c | 4 +++- + 1 file changed, 3 insertions(+), 1 deletion(-) + +diff --git a/net/core/neighbour.c b/net/core/neighbour.c +index 3b642c412cf322..15267428c4f83d 100644 +--- a/net/core/neighbour.c ++++ b/net/core/neighbour.c +@@ -935,7 +935,9 @@ static void neigh_periodic_work(struct work_struct *work) + if (refcount_read(&n->refcnt) == 1 && + (state == NUD_FAILED || + time_after(jiffies, n->used + NEIGH_VAR(n->parms, GC_STALETIME)))) { +- *np = n->next; ++ rcu_assign_pointer(*np, ++ rcu_dereference_protected(n->next, ++ lockdep_is_held(&tbl->lock))); + neigh_mark_dead(n); + write_unlock(&n->lock); + neigh_cleanup_and_release(n); +-- +cgit 1.2.3-korg + diff --git a/meta-openbmc-mods/meta-common/recipes-kernel/linux/linux-aspeed/CVE-2023-52580.patch b/meta-openbmc-mods/meta-common/recipes-kernel/linux/linux-aspeed/CVE-2023-52580.patch new file mode 100644 index 000000000..fcf344233 --- /dev/null +++ b/meta-openbmc-mods/meta-common/recipes-kernel/linux/linux-aspeed/CVE-2023-52580.patch @@ -0,0 +1,121 @@ +From 488ea2a3e2666022f79abfdd7d12e8305fc27a40 Mon Sep 17 00:00:00 2001 +From: Sasha Neftin <sasha.neftin@intel.com> +Date: Wed, 13 Sep 2023 09:39:05 +0300 +Subject: net/core: Fix ETH_P_1588 flow dissector + +[ Upstream commit 75ad80ed88a182ab2ad5513e448cf07b403af5c3 ] + +When a PTP ethernet raw frame with a size of more than 256 bytes followed +by a 0xff pattern is sent to __skb_flow_dissect, nhoff value calculation +is wrong. For example: hdr->message_length takes the wrong value (0xffff) +and it does not replicate real header length. In this case, 'nhoff' value +was overridden and the PTP header was badly dissected. This leads to a +kernel crash. + +net/core: flow_dissector +net/core flow dissector nhoff = 0x0000000e +net/core flow dissector hdr->message_length = 0x0000ffff +net/core flow dissector nhoff = 0x0001000d (u16 overflow) +... +skb linear: 00000000: 00 a0 c9 00 00 00 00 a0 c9 00 00 00 88 +skb frag: 00000000: f7 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff + +Using the size of the ptp_header struct will allow the corrected +calculation of the nhoff value. + +net/core flow dissector nhoff = 0x0000000e +net/core flow dissector nhoff = 0x00000030 (sizeof ptp_header) +... +skb linear: 00000000: 00 a0 c9 00 00 00 00 a0 c9 00 00 00 88 f7 ff ff +skb linear: 00000010: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff +skb linear: 00000020: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff +skb frag: 00000000: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff + +Kernel trace: +[ 74.984279] ------------[ cut here ]------------ +[ 74.989471] kernel BUG at include/linux/skbuff.h:2440! +[ 74.995237] invalid opcode: 0000 [#1] PREEMPT SMP NOPTI +[ 75.001098] CPU: 4 PID: 0 Comm: swapper/4 Tainted: G U 5.15.85-intel-ese-standard-lts #1 +[ 75.011629] Hardware name: Intel Corporation A-Island (CPU:AlderLake)/A-Island (ID:06), BIOS SB_ADLP.01.01.00.01.03.008.D-6A9D9E73-dirty Mar 30 2023 +[ 75.026507] RIP: 0010:eth_type_trans+0xd0/0x130 +[ 75.031594] Code: 03 88 47 78 eb c7 8b 47 68 2b 47 6c 48 8b 97 c0 00 00 00 83 f8 01 7e 1b 48 85 d2 74 06 66 83 3a ff 74 09 b8 00 04 00 00 eb ab <0f> 0b b8 00 01 00 00 eb a2 48 85 ff 74 eb 48 8d 54 24 06 31 f6 b9 +[ 75.052612] RSP: 0018:ffff9948c0228de0 EFLAGS: 00010297 +[ 75.058473] RAX: 00000000000003f2 RBX: ffff8e47047dc300 RCX: 0000000000001003 +[ 75.066462] RDX: ffff8e4e8c9ea040 RSI: ffff8e4704e0a000 RDI: ffff8e47047dc300 +[ 75.074458] RBP: ffff8e4704e2acc0 R08: 00000000000003f3 R09: 0000000000000800 +[ 75.082466] R10: 000000000000000d R11: ffff9948c0228dec R12: ffff8e4715e4e010 +[ 75.090461] R13: ffff9948c0545018 R14: 0000000000000001 R15: 0000000000000800 +[ 75.098464] FS: 0000000000000000(0000) GS:ffff8e4e8fb00000(0000) knlGS:0000000000000000 +[ 75.107530] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 +[ 75.113982] CR2: 00007f5eb35934a0 CR3: 0000000150e0a002 CR4: 0000000000770ee0 +[ 75.121980] PKRU: 55555554 +[ 75.125035] Call Trace: +[ 75.127792] <IRQ> +[ 75.130063] ? eth_get_headlen+0xa4/0xc0 +[ 75.134472] igc_process_skb_fields+0xcd/0x150 +[ 75.139461] igc_poll+0xc80/0x17b0 +[ 75.143272] __napi_poll+0x27/0x170 +[ 75.147192] net_rx_action+0x234/0x280 +[ 75.151409] __do_softirq+0xef/0x2f4 +[ 75.155424] irq_exit_rcu+0xc7/0x110 +[ 75.159432] common_interrupt+0xb8/0xd0 +[ 75.163748] </IRQ> +[ 75.166112] <TASK> +[ 75.168473] asm_common_interrupt+0x22/0x40 +[ 75.173175] RIP: 0010:cpuidle_enter_state+0xe2/0x350 +[ 75.178749] Code: 85 c0 0f 8f 04 02 00 00 31 ff e8 39 6c 67 ff 45 84 ff 74 12 9c 58 f6 c4 02 0f 85 50 02 00 00 31 ff e8 52 b0 6d ff fb 45 85 f6 <0f> 88 b1 00 00 00 49 63 ce 4c 2b 2c 24 48 89 c8 48 6b d1 68 48 c1 +[ 75.199757] RSP: 0018:ffff9948c013bea8 EFLAGS: 00000202 +[ 75.205614] RAX: ffff8e4e8fb00000 RBX: ffffb948bfd23900 RCX: 000000000000001f +[ 75.213619] RDX: 0000000000000004 RSI: ffffffff94206161 RDI: ffffffff94212e20 +[ 75.221620] RBP: 0000000000000004 R08: 000000117568973a R09: 0000000000000001 +[ 75.229622] R10: 000000000000afc8 R11: ffff8e4e8fb29ce4 R12: ffffffff945ae980 +[ 75.237628] R13: 000000117568973a R14: 0000000000000004 R15: 0000000000000000 +[ 75.245635] ? cpuidle_enter_state+0xc7/0x350 +[ 75.250518] cpuidle_enter+0x29/0x40 +[ 75.254539] do_idle+0x1d9/0x260 +[ 75.258166] cpu_startup_entry+0x19/0x20 +[ 75.262582] secondary_startup_64_no_verify+0xc2/0xcb +[ 75.268259] </TASK> +[ 75.270721] Modules linked in: 8021q snd_sof_pci_intel_tgl snd_sof_intel_hda_common tpm_crb snd_soc_hdac_hda snd_sof_intel_hda snd_hda_ext_core snd_sof_pci snd_sof snd_sof_xtensa_dsp snd_soc_acpi_intel_match snd_soc_acpi snd_soc_core snd_compress iTCO_wdt ac97_bus intel_pmc_bxt mei_hdcp iTCO_vendor_support snd_hda_codec_hdmi pmt_telemetry intel_pmc_core pmt_class snd_hda_intel x86_pkg_temp_thermal snd_intel_dspcfg snd_hda_codec snd_hda_core kvm_intel snd_pcm snd_timer kvm snd mei_me soundcore tpm_tis irqbypass i2c_i801 mei tpm_tis_core pcspkr intel_rapl_msr tpm i2c_smbus intel_pmt thermal sch_fq_codel uio uhid i915 drm_buddy video drm_display_helper drm_kms_helper syscopyarea sysfillrect sysimgblt fb_sys_fops ttm fuse configfs +[ 75.342736] ---[ end trace 3785f9f360400e3a ]--- +[ 75.347913] RIP: 0010:eth_type_trans+0xd0/0x130 +[ 75.352984] Code: 03 88 47 78 eb c7 8b 47 68 2b 47 6c 48 8b 97 c0 00 00 00 83 f8 01 7e 1b 48 85 d2 74 06 66 83 3a ff 74 09 b8 00 04 00 00 eb ab <0f> 0b b8 00 01 00 00 eb a2 48 85 ff 74 eb 48 8d 54 24 06 31 f6 b9 +[ 75.373994] RSP: 0018:ffff9948c0228de0 EFLAGS: 00010297 +[ 75.379860] RAX: 00000000000003f2 RBX: ffff8e47047dc300 RCX: 0000000000001003 +[ 75.387856] RDX: ffff8e4e8c9ea040 RSI: ffff8e4704e0a000 RDI: ffff8e47047dc300 +[ 75.395864] RBP: ffff8e4704e2acc0 R08: 00000000000003f3 R09: 0000000000000800 +[ 75.403857] R10: 000000000000000d R11: ffff9948c0228dec R12: ffff8e4715e4e010 +[ 75.411863] R13: ffff9948c0545018 R14: 0000000000000001 R15: 0000000000000800 +[ 75.419875] FS: 0000000000000000(0000) GS:ffff8e4e8fb00000(0000) knlGS:0000000000000000 +[ 75.428946] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 +[ 75.435403] CR2: 00007f5eb35934a0 CR3: 0000000150e0a002 CR4: 0000000000770ee0 +[ 75.443410] PKRU: 55555554 +[ 75.446477] Kernel panic - not syncing: Fatal exception in interrupt +[ 75.453738] Kernel Offset: 0x11c00000 from 0xffffffff81000000 (relocation range: 0xffffffff80000000-0xffffffffbfffffff) +[ 75.465794] ---[ end Kernel panic - not syncing: Fatal exception in interrupt ]--- + +Fixes: 4f1cc51f3488 ("net: flow_dissector: Parse PTP L2 packet header") +Signed-off-by: Sasha Neftin <sasha.neftin@intel.com> +Reviewed-by: Jiri Pirko <jiri@nvidia.com> +Signed-off-by: David S. Miller <davem@davemloft.net> +Signed-off-by: Sasha Levin <sashal@kernel.org> +--- + net/core/flow_dissector.c | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +diff --git a/net/core/flow_dissector.c b/net/core/flow_dissector.c +index 3288490590f276..0c85c8a9e752f3 100644 +--- a/net/core/flow_dissector.c ++++ b/net/core/flow_dissector.c +@@ -1366,7 +1366,7 @@ proto_again: + break; + } + +- nhoff += ntohs(hdr->message_length); ++ nhoff += sizeof(struct ptp_header); + fdret = FLOW_DISSECT_RET_OUT_GOOD; + break; + } +-- +cgit 1.2.3-korg + diff --git a/meta-openbmc-mods/meta-common/recipes-kernel/linux/linux-aspeed/CVE-2023-52597.patch b/meta-openbmc-mods/meta-common/recipes-kernel/linux/linux-aspeed/CVE-2023-52597.patch new file mode 100644 index 000000000..2c417d22e --- /dev/null +++ b/meta-openbmc-mods/meta-common/recipes-kernel/linux/linux-aspeed/CVE-2023-52597.patch @@ -0,0 +1,68 @@ +From 0671f42a9c1084db10d68ac347d08dbf6689ecb3 Mon Sep 17 00:00:00 2001 +From: Heiko Carstens <hca@linux.ibm.com> +Date: Thu, 30 Nov 2023 18:56:00 +0100 +Subject: KVM: s390: fix setting of fpc register + +[ Upstream commit b988b1bb0053c0dcd26187d29ef07566a565cf55 ] + +kvm_arch_vcpu_ioctl_set_fpu() allows to set the floating point control +(fpc) register of a guest cpu. The new value is tested for validity by +temporarily loading it into the fpc register. + +This may lead to corruption of the fpc register of the host process: +if an interrupt happens while the value is temporarily loaded into the fpc +register, and within interrupt context floating point or vector registers +are used, the current fp/vx registers are saved with save_fpu_regs() +assuming they belong to user space and will be loaded into fp/vx registers +when returning to user space. + +test_fp_ctl() restores the original user space / host process fpc register +value, however it will be discarded, when returning to user space. + +In result the host process will incorrectly continue to run with the value +that was supposed to be used for a guest cpu. + +Fix this by simply removing the test. There is another test right before +the SIE context is entered which will handles invalid values. + +This results in a change of behaviour: invalid values will now be accepted +instead of that the ioctl fails with -EINVAL. This seems to be acceptable, +given that this interface is most likely not used anymore, and this is in +addition the same behaviour implemented with the memory mapped interface +(replace invalid values with zero) - see sync_regs() in kvm-s390.c. + +Reviewed-by: Christian Borntraeger <borntraeger@linux.ibm.com> +Reviewed-by: Claudio Imbrenda <imbrenda@linux.ibm.com> +Signed-off-by: Heiko Carstens <hca@linux.ibm.com> +Signed-off-by: Alexander Gordeev <agordeev@linux.ibm.com> +Signed-off-by: Sasha Levin <sashal@kernel.org> +--- + arch/s390/kvm/kvm-s390.c | 5 ----- + 1 file changed, 5 deletions(-) + +diff --git a/arch/s390/kvm/kvm-s390.c b/arch/s390/kvm/kvm-s390.c +index 3775363471f0c6..f604946ab2c85e 100644 +--- a/arch/s390/kvm/kvm-s390.c ++++ b/arch/s390/kvm/kvm-s390.c +@@ -4138,10 +4138,6 @@ int kvm_arch_vcpu_ioctl_set_fpu(struct kvm_vcpu *vcpu, struct kvm_fpu *fpu) + + vcpu_load(vcpu); + +- if (test_fp_ctl(fpu->fpc)) { +- ret = -EINVAL; +- goto out; +- } + vcpu->run->s.regs.fpc = fpu->fpc; + if (MACHINE_HAS_VX) + convert_fp_to_vx((__vector128 *) vcpu->run->s.regs.vrs, +@@ -4149,7 +4145,6 @@ int kvm_arch_vcpu_ioctl_set_fpu(struct kvm_vcpu *vcpu, struct kvm_fpu *fpu) + else + memcpy(vcpu->run->s.regs.fprs, &fpu->fprs, sizeof(fpu->fprs)); + +-out: + vcpu_put(vcpu); + return ret; + } +-- +cgit 1.2.3-korg + diff --git a/meta-openbmc-mods/meta-common/recipes-kernel/linux/linux-aspeed/CVE-2023-52598.patch b/meta-openbmc-mods/meta-common/recipes-kernel/linux/linux-aspeed/CVE-2023-52598.patch new file mode 100644 index 000000000..02c7ab205 --- /dev/null +++ b/meta-openbmc-mods/meta-common/recipes-kernel/linux/linux-aspeed/CVE-2023-52598.patch @@ -0,0 +1,69 @@ +From 02c6bbfb08bad78dd014e24c7b893723c15ec7a1 Mon Sep 17 00:00:00 2001 +From: Heiko Carstens <hca@linux.ibm.com> +Date: Thu, 30 Nov 2023 18:55:59 +0100 +Subject: s390/ptrace: handle setting of fpc register correctly + +[ Upstream commit 8b13601d19c541158a6e18b278c00ba69ae37829 ] + +If the content of the floating point control (fpc) register of a traced +process is modified with the ptrace interface the new value is tested for +validity by temporarily loading it into the fpc register. + +This may lead to corruption of the fpc register of the tracing process: +if an interrupt happens while the value is temporarily loaded into the +fpc register, and within interrupt context floating point or vector +registers are used, the current fp/vx registers are saved with +save_fpu_regs() assuming they belong to user space and will be loaded into +fp/vx registers when returning to user space. + +test_fp_ctl() restores the original user space fpc register value, however +it will be discarded, when returning to user space. + +In result the tracer will incorrectly continue to run with the value that +was supposed to be used for the traced process. + +Fix this by saving fpu register contents with save_fpu_regs() before using +test_fp_ctl(). + +Reviewed-by: Claudio Imbrenda <imbrenda@linux.ibm.com> +Signed-off-by: Heiko Carstens <hca@linux.ibm.com> +Signed-off-by: Alexander Gordeev <agordeev@linux.ibm.com> +Signed-off-by: Sasha Levin <sashal@kernel.org> +--- + arch/s390/kernel/ptrace.c | 6 +++--- + 1 file changed, 3 insertions(+), 3 deletions(-) + +diff --git a/arch/s390/kernel/ptrace.c b/arch/s390/kernel/ptrace.c +index ea244a73efad9d..512b8147375935 100644 +--- a/arch/s390/kernel/ptrace.c ++++ b/arch/s390/kernel/ptrace.c +@@ -385,6 +385,7 @@ static int __poke_user(struct task_struct *child, addr_t addr, addr_t data) + /* + * floating point control reg. is in the thread structure + */ ++ save_fpu_regs(); + if ((unsigned int) data != 0 || + test_fp_ctl(data >> (BITS_PER_LONG - 32))) + return -EINVAL; +@@ -741,6 +742,7 @@ static int __poke_user_compat(struct task_struct *child, + /* + * floating point control reg. is in the thread structure + */ ++ save_fpu_regs(); + if (test_fp_ctl(tmp)) + return -EINVAL; + child->thread.fpu.fpc = data; +@@ -904,9 +906,7 @@ static int s390_fpregs_set(struct task_struct *target, + int rc = 0; + freg_t fprs[__NUM_FPRS]; + +- if (target == current) +- save_fpu_regs(); +- ++ save_fpu_regs(); + if (MACHINE_HAS_VX) + convert_vx_to_fp(fprs, target->thread.fpu.vxrs); + else +-- +cgit 1.2.3-korg + diff --git a/meta-openbmc-mods/meta-common/recipes-kernel/linux/linux-aspeed/CVE-2023-52612.patch b/meta-openbmc-mods/meta-common/recipes-kernel/linux/linux-aspeed/CVE-2023-52612.patch new file mode 100644 index 000000000..65fc76942 --- /dev/null +++ b/meta-openbmc-mods/meta-common/recipes-kernel/linux/linux-aspeed/CVE-2023-52612.patch @@ -0,0 +1,55 @@ +From 1142d65c5b881590962ad763f94505b6dd67d2fe Mon Sep 17 00:00:00 2001 +From: Chengming Zhou <zhouchengming@bytedance.com> +Date: Wed, 27 Dec 2023 09:35:23 +0000 +Subject: crypto: scomp - fix req->dst buffer overflow + +[ Upstream commit 744e1885922a9943458954cfea917b31064b4131 ] + +The req->dst buffer size should be checked before copying from the +scomp_scratch->dst to avoid req->dst buffer overflow problem. + +Fixes: 1ab53a77b772 ("crypto: acomp - add driver-side scomp interface") +Reported-by: syzbot+3eff5e51bf1db122a16e@syzkaller.appspotmail.com +Closes: https://lore.kernel.org/all/0000000000000b05cd060d6b5511@google.com/ +Signed-off-by: Chengming Zhou <zhouchengming@bytedance.com> +Reviewed-by: Barry Song <v-songbaohua@oppo.com> +Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au> +Signed-off-by: Sasha Levin <sashal@kernel.org> +--- + crypto/scompress.c | 6 ++++++ + 1 file changed, 6 insertions(+) + +diff --git a/crypto/scompress.c b/crypto/scompress.c +index 3702f1648ea8c9..34174f55a6d6ed 100644 +--- a/crypto/scompress.c ++++ b/crypto/scompress.c +@@ -132,6 +132,7 @@ static int scomp_acomp_comp_decomp(struct acomp_req *req, int dir) + struct crypto_scomp *scomp = *tfm_ctx; + void **ctx = acomp_request_ctx(req); + struct scomp_scratch *scratch; ++ unsigned int dlen; + int ret; + + if (!req->src || !req->slen || req->slen > SCOMP_SCRATCH_SIZE) +@@ -143,6 +144,8 @@ static int scomp_acomp_comp_decomp(struct acomp_req *req, int dir) + if (!req->dlen || req->dlen > SCOMP_SCRATCH_SIZE) + req->dlen = SCOMP_SCRATCH_SIZE; + ++ dlen = req->dlen; ++ + scratch = raw_cpu_ptr(&scomp_scratch); + spin_lock(&scratch->lock); + +@@ -160,6 +163,9 @@ static int scomp_acomp_comp_decomp(struct acomp_req *req, int dir) + ret = -ENOMEM; + goto out; + } ++ } else if (req->dlen > dlen) { ++ ret = -ENOSPC; ++ goto out; + } + scatterwalk_map_and_copy(scratch->dst, req->dst, 0, req->dlen, + 1); +-- +cgit 1.2.3-korg + diff --git a/meta-openbmc-mods/meta-common/recipes-kernel/linux/linux-aspeed/CVE-2023-52615.patch b/meta-openbmc-mods/meta-common/recipes-kernel/linux/linux-aspeed/CVE-2023-52615.patch new file mode 100644 index 000000000..9cb2c119c --- /dev/null +++ b/meta-openbmc-mods/meta-common/recipes-kernel/linux/linux-aspeed/CVE-2023-52615.patch @@ -0,0 +1,120 @@ +From 26cc6d7006f922df6cc4389248032d955750b2a0 Mon Sep 17 00:00:00 2001 +From: Herbert Xu <herbert@gondor.apana.org.au> +Date: Sat, 2 Dec 2023 09:01:54 +0800 +Subject: hwrng: core - Fix page fault dead lock on mmap-ed hwrng + +commit 78aafb3884f6bc6636efcc1760c891c8500b9922 upstream. + +There is a dead-lock in the hwrng device read path. This triggers +when the user reads from /dev/hwrng into memory also mmap-ed from +/dev/hwrng. The resulting page fault triggers a recursive read +which then dead-locks. + +Fix this by using a stack buffer when calling copy_to_user. + +Reported-by: Edward Adam Davis <eadavis@qq.com> +Reported-by: syzbot+c52ab18308964d248092@syzkaller.appspotmail.com +Fixes: 9996508b3353 ("hwrng: core - Replace u32 in driver API with byte array") +Cc: <stable@vger.kernel.org> +Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au> +Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> +--- + drivers/char/hw_random/core.c | 34 +++++++++++++++++++++------------- + 1 file changed, 21 insertions(+), 13 deletions(-) + +diff --git a/drivers/char/hw_random/core.c b/drivers/char/hw_random/core.c +index cfb085de876b70..c3a2df67e0e997 100644 +--- a/drivers/char/hw_random/core.c ++++ b/drivers/char/hw_random/core.c +@@ -24,10 +24,13 @@ + #include <linux/random.h> + #include <linux/sched.h> + #include <linux/slab.h> ++#include <linux/string.h> + #include <linux/uaccess.h> + + #define RNG_MODULE_NAME "hw_random" + ++#define RNG_BUFFER_SIZE (SMP_CACHE_BYTES < 32 ? 32 : SMP_CACHE_BYTES) ++ + static struct hwrng *current_rng; + /* the current rng has been explicitly chosen by user via sysfs */ + static int cur_rng_set_by_user; +@@ -59,7 +62,7 @@ static inline int rng_get_data(struct hwrng *rng, u8 *buffer, size_t size, + + static size_t rng_buffer_size(void) + { +- return SMP_CACHE_BYTES < 32 ? 32 : SMP_CACHE_BYTES; ++ return RNG_BUFFER_SIZE; + } + + static void add_early_randomness(struct hwrng *rng) +@@ -206,6 +209,7 @@ static inline int rng_get_data(struct hwrng *rng, u8 *buffer, size_t size, + static ssize_t rng_dev_read(struct file *filp, char __user *buf, + size_t size, loff_t *offp) + { ++ u8 buffer[RNG_BUFFER_SIZE]; + ssize_t ret = 0; + int err = 0; + int bytes_read, len; +@@ -233,34 +237,37 @@ static ssize_t rng_dev_read(struct file *filp, char __user *buf, + if (bytes_read < 0) { + err = bytes_read; + goto out_unlock_reading; ++ } else if (bytes_read == 0 && ++ (filp->f_flags & O_NONBLOCK)) { ++ err = -EAGAIN; ++ goto out_unlock_reading; + } ++ + data_avail = bytes_read; + } + +- if (!data_avail) { +- if (filp->f_flags & O_NONBLOCK) { +- err = -EAGAIN; +- goto out_unlock_reading; +- } +- } else { +- len = data_avail; ++ len = data_avail; ++ if (len) { + if (len > size) + len = size; + + data_avail -= len; + +- if (copy_to_user(buf + ret, rng_buffer + data_avail, +- len)) { ++ memcpy(buffer, rng_buffer + data_avail, len); ++ } ++ mutex_unlock(&reading_mutex); ++ put_rng(rng); ++ ++ if (len) { ++ if (copy_to_user(buf + ret, buffer, len)) { + err = -EFAULT; +- goto out_unlock_reading; ++ goto out; + } + + size -= len; + ret += len; + } + +- mutex_unlock(&reading_mutex); +- put_rng(rng); + + if (need_resched()) + schedule_timeout_interruptible(1); +@@ -271,6 +278,7 @@ static ssize_t rng_dev_read(struct file *filp, char __user *buf, + } + } + out: ++ memzero_explicit(buffer, sizeof(buffer)); + return ret ? : err; + + out_unlock_reading: +-- +cgit 1.2.3-korg + diff --git a/meta-openbmc-mods/meta-common/recipes-kernel/linux/linux-aspeed/CVE-2023-52619.patch b/meta-openbmc-mods/meta-common/recipes-kernel/linux/linux-aspeed/CVE-2023-52619.patch new file mode 100644 index 000000000..647e66a9a --- /dev/null +++ b/meta-openbmc-mods/meta-common/recipes-kernel/linux/linux-aspeed/CVE-2023-52619.patch @@ -0,0 +1,45 @@ +From 0593cfd321df9001142a9d2c58d4144917dff7ee Mon Sep 17 00:00:00 2001 +From: Weichen Chen <weichen.chen@mediatek.com> +Date: Fri, 24 Feb 2023 10:36:32 +0800 +Subject: pstore/ram: Fix crash when setting number of cpus to an odd number + +[ Upstream commit d49270a04623ce3c0afddbf3e984cb245aa48e9c ] + +When the number of cpu cores is adjusted to 7 or other odd numbers, +the zone size will become an odd number. +The address of the zone will become: + addr of zone0 = BASE + addr of zone1 = BASE + zone_size + addr of zone2 = BASE + zone_size*2 + ... +The address of zone1/3/5/7 will be mapped to non-alignment va. +Eventually crashes will occur when accessing these va. + +So, use ALIGN_DOWN() to make sure the zone size is even +to avoid this bug. + +Signed-off-by: Weichen Chen <weichen.chen@mediatek.com> +Reviewed-by: Matthias Brugger <matthias.bgg@gmail.com> +Tested-by: "Guilherme G. Piccoli" <gpiccoli@igalia.com> +Link: https://lore.kernel.org/r/20230224023632.6840-1-weichen.chen@mediatek.com +Signed-off-by: Kees Cook <keescook@chromium.org> +Signed-off-by: Sasha Levin <sashal@kernel.org> +--- + fs/pstore/ram.c | 1 + + 1 file changed, 1 insertion(+) + +diff --git a/fs/pstore/ram.c b/fs/pstore/ram.c +index d36702c7ab3c43..88b34fdbf7592f 100644 +--- a/fs/pstore/ram.c ++++ b/fs/pstore/ram.c +@@ -529,6 +529,7 @@ static int ramoops_init_przs(const char *name, + } + + zone_sz = mem_sz / *cnt; ++ zone_sz = ALIGN_DOWN(zone_sz, 2); + if (!zone_sz) { + dev_err(dev, "%s zone size == 0\n", name); + goto fail; +-- +cgit 1.2.3-korg + diff --git a/meta-openbmc-mods/meta-common/recipes-kernel/linux/linux-aspeed/CVE-2023-52622.patch b/meta-openbmc-mods/meta-common/recipes-kernel/linux/linux-aspeed/CVE-2023-52622.patch new file mode 100644 index 000000000..9f16384b9 --- /dev/null +++ b/meta-openbmc-mods/meta-common/recipes-kernel/linux/linux-aspeed/CVE-2023-52622.patch @@ -0,0 +1,131 @@ +From b183fe8702e78bba3dcef8e7193cab6898abee07 Mon Sep 17 00:00:00 2001 +From: Baokun Li <libaokun1@huawei.com> +Date: Mon, 23 Oct 2023 09:30:56 +0800 +Subject: ext4: avoid online resizing failures due to oversized flex bg +MIME-Version: 1.0 +Content-Type: text/plain; charset=UTF-8 +Content-Transfer-Encoding: 8bit + +[ Upstream commit 5d1935ac02ca5aee364a449a35e2977ea84509b0 ] + +When we online resize an ext4 filesystem with a oversized flexbg_size, + + mkfs.ext4 -F -G 67108864 $dev -b 4096 100M + mount $dev $dir + resize2fs $dev 16G + +the following WARN_ON is triggered: +================================================================== +WARNING: CPU: 0 PID: 427 at mm/page_alloc.c:4402 __alloc_pages+0x411/0x550 +Modules linked in: sg(E) +CPU: 0 PID: 427 Comm: resize2fs Tainted: G E 6.6.0-rc5+ #314 +RIP: 0010:__alloc_pages+0x411/0x550 +Call Trace: + <TASK> + __kmalloc_large_node+0xa2/0x200 + __kmalloc+0x16e/0x290 + ext4_resize_fs+0x481/0xd80 + __ext4_ioctl+0x1616/0x1d90 + ext4_ioctl+0x12/0x20 + __x64_sys_ioctl+0xf0/0x150 + do_syscall_64+0x3b/0x90 +================================================================== + +This is because flexbg_size is too large and the size of the new_group_data +array to be allocated exceeds MAX_ORDER. Currently, the minimum value of +MAX_ORDER is 8, the minimum value of PAGE_SIZE is 4096, the corresponding +maximum number of groups that can be allocated is: + + (PAGE_SIZE << MAX_ORDER) / sizeof(struct ext4_new_group_data) ≈ 21845 + +And the value that is down-aligned to the power of 2 is 16384. Therefore, +this value is defined as MAX_RESIZE_BG, and the number of groups added +each time does not exceed this value during resizing, and is added multiple +times to complete the online resizing. The difference is that the metadata +in a flex_bg may be more dispersed. + +Signed-off-by: Baokun Li <libaokun1@huawei.com> +Reviewed-by: Jan Kara <jack@suse.cz> +Link: https://lore.kernel.org/r/20231023013057.2117948-4-libaokun1@huawei.com +Signed-off-by: Theodore Ts'o <tytso@mit.edu> +Signed-off-by: Sasha Levin <sashal@kernel.org> +--- + fs/ext4/resize.c | 25 +++++++++++++++++-------- + 1 file changed, 17 insertions(+), 8 deletions(-) + +diff --git a/fs/ext4/resize.c b/fs/ext4/resize.c +index b63cb88ccdae..355acc064a14 100644 +--- a/fs/ext4/resize.c ++++ b/fs/ext4/resize.c +@@ -217,10 +217,16 @@ struct ext4_new_flex_group_data { + in the flex group */ + __u16 *bg_flags; /* block group flags of groups + in @groups */ ++ ext4_group_t resize_bg; /* number of allocated ++ new_group_data */ + ext4_group_t count; /* number of groups in @groups + */ + }; + ++/* ++ * Avoiding memory allocation failures due to too many groups added each time. ++ */ ++#define MAX_RESIZE_BG 16384 + /* + * alloc_flex_gd() allocates a ext4_new_flex_group_data with size of + * @flexbg_size. +@@ -237,15 +243,18 @@ static struct ext4_new_flex_group_data *alloc_flex_gd(unsigned long flexbg_size) + + if (flexbg_size >= UINT_MAX / sizeof(struct ext4_new_group_data)) + goto out2; +- flex_gd->count = flexbg_size; ++ if (unlikely(flexbg_size > MAX_RESIZE_BG)) ++ flex_gd->resize_bg = MAX_RESIZE_BG; ++ else ++ flex_gd->resize_bg = flexbg_size; + +- flex_gd->groups = kmalloc_array(flexbg_size, +- sizeof(struct ext4_new_group_data), +- GFP_NOFS); ++ flex_gd->groups = kmalloc_array(flex_gd->resize_bg, ++ sizeof(struct ext4_new_group_data), ++ GFP_NOFS); + if (flex_gd->groups == NULL) + goto out2; + +- flex_gd->bg_flags = kmalloc_array(flexbg_size, sizeof(__u16), ++ flex_gd->bg_flags = kmalloc_array(flex_gd->resize_bg, sizeof(__u16), + GFP_NOFS); + if (flex_gd->bg_flags == NULL) + goto out1; +@@ -1566,8 +1575,7 @@ static int ext4_flex_group_add(struct super_block *sb, + + static int ext4_setup_next_flex_gd(struct super_block *sb, + struct ext4_new_flex_group_data *flex_gd, +- ext4_fsblk_t n_blocks_count, +- unsigned long flexbg_size) ++ ext4_fsblk_t n_blocks_count) + { + struct ext4_sb_info *sbi = EXT4_SB(sb); + struct ext4_super_block *es = sbi->s_es; +@@ -1591,7 +1599,7 @@ static int ext4_setup_next_flex_gd(struct super_block *sb, + BUG_ON(last); + ext4_get_group_no_and_offset(sb, n_blocks_count - 1, &n_group, &last); + +- last_group = group | (flexbg_size - 1); ++ last_group = group | (flex_gd->resize_bg - 1); + if (last_group > n_group) + last_group = n_group; + +@@ -2087,8 +2095,7 @@ int ext4_resize_fs(struct super_block *sb, ext4_fsblk_t n_blocks_count) + /* Add flex groups. Note that a regular group is a + * flex group with 1 group. + */ +- while (ext4_setup_next_flex_gd(sb, flex_gd, n_blocks_count, +- flexbg_size)) { ++ while (ext4_setup_next_flex_gd(sb, flex_gd, n_blocks_count)) { + if (jiffies - last_update_time > HZ * 10) { + if (last_update_time) + ext4_msg(sb, KERN_INFO, +cgit 1.2.3-korg + diff --git a/meta-openbmc-mods/meta-common/recipes-kernel/linux/linux-aspeed/CVE-2024-0562.patch b/meta-openbmc-mods/meta-common/recipes-kernel/linux/linux-aspeed/CVE-2024-0562.patch new file mode 100644 index 000000000..600b764f6 --- /dev/null +++ b/meta-openbmc-mods/meta-common/recipes-kernel/linux/linux-aspeed/CVE-2024-0562.patch @@ -0,0 +1,143 @@ +From f87904c075515f3e1d8f4a7115869d3b914674fd Mon Sep 17 00:00:00 2001 +From: Khazhismel Kumykov <khazhy@chromium.org> +Date: Mon, 1 Aug 2022 08:50:34 -0700 +Subject: writeback: avoid use-after-free after removing device + +When a disk is removed, bdi_unregister gets called to stop further +writeback and wait for associated delayed work to complete. However, +wb_inode_writeback_end() may schedule bandwidth estimation dwork after +this has completed, which can result in the timer attempting to access the +just freed bdi_writeback. + +Fix this by checking if the bdi_writeback is alive, similar to when +scheduling writeback work. + +Since this requires wb->work_lock, and wb_inode_writeback_end() may get +called from interrupt, switch wb->work_lock to an irqsafe lock. + +Link: https://lkml.kernel.org/r/20220801155034.3772543-1-khazhy@google.com +Fixes: 45a2966fd641 ("writeback: fix bandwidth estimate for spiky workload") +Signed-off-by: Khazhismel Kumykov <khazhy@google.com> +Reviewed-by: Jan Kara <jack@suse.cz> +Cc: Michael Stapelberg <stapelberg+linux@google.com> +Cc: Wu Fengguang <fengguang.wu@intel.com> +Cc: Alexander Viro <viro@zeniv.linux.org.uk> +Cc: <stable@vger.kernel.org> +Signed-off-by: Andrew Morton <akpm@linux-foundation.org> +--- + fs/fs-writeback.c | 12 ++++++------ + mm/backing-dev.c | 10 +++++----- + mm/page-writeback.c | 6 +++++- + 3 files changed, 16 insertions(+), 12 deletions(-) + +diff --git a/fs/fs-writeback.c b/fs/fs-writeback.c +index 05221366a16dc9..08a1993ab7fd39 100644 +--- a/fs/fs-writeback.c ++++ b/fs/fs-writeback.c +@@ -134,10 +134,10 @@ static bool inode_io_list_move_locked(struct inode *inode, + + static void wb_wakeup(struct bdi_writeback *wb) + { +- spin_lock_bh(&wb->work_lock); ++ spin_lock_irq(&wb->work_lock); + if (test_bit(WB_registered, &wb->state)) + mod_delayed_work(bdi_wq, &wb->dwork, 0); +- spin_unlock_bh(&wb->work_lock); ++ spin_unlock_irq(&wb->work_lock); + } + + static void finish_writeback_work(struct bdi_writeback *wb, +@@ -164,7 +164,7 @@ static void wb_queue_work(struct bdi_writeback *wb, + if (work->done) + atomic_inc(&work->done->cnt); + +- spin_lock_bh(&wb->work_lock); ++ spin_lock_irq(&wb->work_lock); + + if (test_bit(WB_registered, &wb->state)) { + list_add_tail(&work->list, &wb->work_list); +@@ -172,7 +172,7 @@ static void wb_queue_work(struct bdi_writeback *wb, + } else + finish_writeback_work(wb, work); + +- spin_unlock_bh(&wb->work_lock); ++ spin_unlock_irq(&wb->work_lock); + } + + /** +@@ -2082,13 +2082,13 @@ static struct wb_writeback_work *get_next_work_item(struct bdi_writeback *wb) + { + struct wb_writeback_work *work = NULL; + +- spin_lock_bh(&wb->work_lock); ++ spin_lock_irq(&wb->work_lock); + if (!list_empty(&wb->work_list)) { + work = list_entry(wb->work_list.next, + struct wb_writeback_work, list); + list_del_init(&work->list); + } +- spin_unlock_bh(&wb->work_lock); ++ spin_unlock_irq(&wb->work_lock); + return work; + } + +diff --git a/mm/backing-dev.c b/mm/backing-dev.c +index 95550b8fa7fe2e..de65cb1e5f7611 100644 +--- a/mm/backing-dev.c ++++ b/mm/backing-dev.c +@@ -260,10 +260,10 @@ void wb_wakeup_delayed(struct bdi_writeback *wb) + unsigned long timeout; + + timeout = msecs_to_jiffies(dirty_writeback_interval * 10); +- spin_lock_bh(&wb->work_lock); ++ spin_lock_irq(&wb->work_lock); + if (test_bit(WB_registered, &wb->state)) + queue_delayed_work(bdi_wq, &wb->dwork, timeout); +- spin_unlock_bh(&wb->work_lock); ++ spin_unlock_irq(&wb->work_lock); + } + + static void wb_update_bandwidth_workfn(struct work_struct *work) +@@ -334,12 +334,12 @@ static void cgwb_remove_from_bdi_list(struct bdi_writeback *wb); + static void wb_shutdown(struct bdi_writeback *wb) + { + /* Make sure nobody queues further work */ +- spin_lock_bh(&wb->work_lock); ++ spin_lock_irq(&wb->work_lock); + if (!test_and_clear_bit(WB_registered, &wb->state)) { +- spin_unlock_bh(&wb->work_lock); ++ spin_unlock_irq(&wb->work_lock); + return; + } +- spin_unlock_bh(&wb->work_lock); ++ spin_unlock_irq(&wb->work_lock); + + cgwb_remove_from_bdi_list(wb); + /* +diff --git a/mm/page-writeback.c b/mm/page-writeback.c +index d0d466a5c804ca..032a7bf8d25930 100644 +--- a/mm/page-writeback.c ++++ b/mm/page-writeback.c +@@ -2892,6 +2892,7 @@ static void wb_inode_writeback_start(struct bdi_writeback *wb) + + static void wb_inode_writeback_end(struct bdi_writeback *wb) + { ++ unsigned long flags; + atomic_dec(&wb->writeback_inodes); + /* + * Make sure estimate of writeback throughput gets updated after +@@ -2900,7 +2901,10 @@ static void wb_inode_writeback_end(struct bdi_writeback *wb) + * that if multiple inodes end writeback at a similar time, they get + * batched into one bandwidth update. + */ +- queue_delayed_work(bdi_wq, &wb->bw_dwork, BANDWIDTH_INTERVAL); ++ spin_lock_irqsave(&wb->work_lock, flags); ++ if (test_bit(WB_registered, &wb->state)) ++ queue_delayed_work(bdi_wq, &wb->bw_dwork, BANDWIDTH_INTERVAL); ++ spin_unlock_irqrestore(&wb->work_lock, flags); + } + + int test_clear_page_writeback(struct page *page) +-- +cgit 1.2.3-korg + diff --git a/meta-openbmc-mods/meta-common/recipes-kernel/linux/linux-aspeed/CVE-2024-0639.patch b/meta-openbmc-mods/meta-common/recipes-kernel/linux/linux-aspeed/CVE-2024-0639.patch new file mode 100644 index 000000000..86e3532c5 --- /dev/null +++ b/meta-openbmc-mods/meta-common/recipes-kernel/linux/linux-aspeed/CVE-2024-0639.patch @@ -0,0 +1,52 @@ +From 6feb37b3b06e9049e20dcf7e23998f92c9c5be9a Mon Sep 17 00:00:00 2001 +From: Chengfeng Ye <dg573847474@gmail.com> +Date: Tue, 27 Jun 2023 12:03:40 +0000 +Subject: sctp: fix potential deadlock on &net->sctp.addr_wq_lock + +As &net->sctp.addr_wq_lock is also acquired by the timer +sctp_addr_wq_timeout_handler() in protocal.c, the same lock acquisition +at sctp_auto_asconf_init() seems should disable irq since it is called +from sctp_accept() under process context. + +Possible deadlock scenario: +sctp_accept() + -> sctp_sock_migrate() + -> sctp_auto_asconf_init() + -> spin_lock(&net->sctp.addr_wq_lock) + <timer interrupt> + -> sctp_addr_wq_timeout_handler() + -> spin_lock_bh(&net->sctp.addr_wq_lock); (deadlock here) + +This flaw was found using an experimental static analysis tool we are +developing for irq-related deadlock. + +The tentative patch fix the potential deadlock by spin_lock_bh(). + +Signed-off-by: Chengfeng Ye <dg573847474@gmail.com> +Fixes: 34e5b0118685 ("sctp: delay auto_asconf init until binding the first addr") +Acked-by: Xin Long <lucien.xin@gmail.com> +Link: https://lore.kernel.org/r/20230627120340.19432-1-dg573847474@gmail.com +Signed-off-by: Paolo Abeni <pabeni@redhat.com> +--- + net/sctp/socket.c | 4 ++-- + 1 file changed, 2 insertions(+), 2 deletions(-) + +diff --git a/net/sctp/socket.c b/net/sctp/socket.c +index 6554a357fe33f1..9388d98aebc033 100644 +--- a/net/sctp/socket.c ++++ b/net/sctp/socket.c +@@ -364,9 +364,9 @@ static void sctp_auto_asconf_init(struct sctp_sock *sp) + struct net *net = sock_net(&sp->inet.sk); + + if (net->sctp.default_auto_asconf) { +- spin_lock(&net->sctp.addr_wq_lock); ++ spin_lock_bh(&net->sctp.addr_wq_lock); + list_add_tail(&sp->auto_asconf_list, &net->sctp.auto_asconf_splist); +- spin_unlock(&net->sctp.addr_wq_lock); ++ spin_unlock_bh(&net->sctp.addr_wq_lock); + sp->do_auto_asconf = 1; + } + } +-- +cgit 1.2.3-korg + diff --git a/meta-openbmc-mods/meta-common/recipes-kernel/linux/linux-aspeed/CVE-2024-0775.patch b/meta-openbmc-mods/meta-common/recipes-kernel/linux/linux-aspeed/CVE-2024-0775.patch new file mode 100644 index 000000000..82b48fa97 --- /dev/null +++ b/meta-openbmc-mods/meta-common/recipes-kernel/linux/linux-aspeed/CVE-2024-0775.patch @@ -0,0 +1,62 @@ +From 4c0b4818b1f636bc96359f7817a2d8bab6370162 Mon Sep 17 00:00:00 2001 +From: Theodore Ts'o <tytso@mit.edu> +Date: Fri, 5 May 2023 22:20:29 -0400 +Subject: ext4: improve error recovery code paths in __ext4_remount() + +If there are failures while changing the mount options in +__ext4_remount(), we need to restore the old mount options. + +This commit fixes two problem. The first is there is a chance that we +will free the old quota file names before a potential failure leading +to a use-after-free. The second problem addressed in this commit is +if there is a failed read/write to read-only transition, if the quota +has already been suspended, we need to renable quota handling. + +Cc: stable@kernel.org +Link: https://lore.kernel.org/r/20230506142419.984260-2-tytso@mit.edu +Signed-off-by: Theodore Ts'o <tytso@mit.edu> +--- + fs/ext4/super.c | 13 ++++++++++--- + 1 file changed, 10 insertions(+), 3 deletions(-) + +diff --git a/fs/ext4/super.c b/fs/ext4/super.c +index c7bc4a2709cc25..bc0b4a98b337ec 100644 +--- a/fs/ext4/super.c ++++ b/fs/ext4/super.c +@@ -6617,9 +6617,6 @@ static int __ext4_remount(struct fs_context *fc, struct super_block *sb) + } + + #ifdef CONFIG_QUOTA +- /* Release old quota file names */ +- for (i = 0; i < EXT4_MAXQUOTAS; i++) +- kfree(old_opts.s_qf_names[i]); + if (enable_quota) { + if (sb_any_quota_suspended(sb)) + dquot_resume(sb, -1); +@@ -6629,6 +6626,9 @@ static int __ext4_remount(struct fs_context *fc, struct super_block *sb) + goto restore_opts; + } + } ++ /* Release old quota file names */ ++ for (i = 0; i < EXT4_MAXQUOTAS; i++) ++ kfree(old_opts.s_qf_names[i]); + #endif + if (!test_opt(sb, BLOCK_VALIDITY) && sbi->s_system_blks) + ext4_release_system_zone(sb); +@@ -6642,6 +6642,13 @@ static int __ext4_remount(struct fs_context *fc, struct super_block *sb) + return 0; + + restore_opts: ++ /* ++ * If there was a failing r/w to ro transition, we may need to ++ * re-enable quota ++ */ ++ if ((sb->s_flags & SB_RDONLY) && !(old_sb_flags & SB_RDONLY) && ++ sb_any_quota_suspended(sb)) ++ dquot_resume(sb, -1); + sb->s_flags = old_sb_flags; + sbi->s_mount_opt = old_opts.s_mount_opt; + sbi->s_mount_opt2 = old_opts.s_mount_opt2; +-- +cgit 1.2.3-korg + diff --git a/meta-openbmc-mods/meta-common/recipes-kernel/linux/linux-aspeed/CVE-2024-26001.patch b/meta-openbmc-mods/meta-common/recipes-kernel/linux/linux-aspeed/CVE-2024-26001.patch new file mode 100644 index 000000000..7978b435f --- /dev/null +++ b/meta-openbmc-mods/meta-common/recipes-kernel/linux/linux-aspeed/CVE-2024-26001.patch @@ -0,0 +1,67 @@ +From c1317822e2de80e78f137d3a2d99febab1b80326 Mon Sep 17 00:00:00 2001 +From: Baokun Li <libaokun1@huawei.com> +Date: Thu, 4 Jan 2024 22:20:35 +0800 +Subject:ext4: regenerate buddy after block freeing failed if under fc + replay + +commit c9b528c35795b711331ed36dc3dbee90d5812d4e upstream. + +This mostly reverts commit 6bd97bf273bd ("ext4: remove redundant +mb_regenerate_buddy()") and reintroduces mb_regenerate_buddy(). Based on +code in mb_free_blocks(), fast commit replay can end up marking as free +blocks that are already marked as such. This causes corruption of the +buddy bitmap so we need to regenerate it in that case. + +Reported-by: Jan Kara <jack@suse.cz> +Fixes: 6bd97bf273bd ("ext4: remove redundant mb_regenerate_buddy()") +Signed-off-by: Baokun Li <libaokun1@huawei.com> +Reviewed-by: Jan Kara <jack@suse.cz> +Link: https://lore.kernel.org/r/20240104142040.2835097-4-libaokun1@huawei.com +Signed-off-by: Theodore Ts'o <tytso@mit.edu> +Signed-off-by: Baokun Li <libaokun1@huawei.com> +Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> +--- + fs/ext4/mballoc.c | 20 ++++++++++++++++++++ + 1 file changed, 20 insertions(+) + +diff --git a/fs/ext4/mballoc.c b/fs/ext4/mballoc.c +index e436acb8f0cc..c3d76f2e59d2 100644 +--- a/fs/ext4/mballoc.c ++++ b/fs/ext4/mballoc.c +@@ -1160,6 +1160,24 @@ void ext4_mb_generate_buddy(struct super_block *sb, + mb_update_avg_fragment_size(sb, grp); + } + ++static void mb_regenerate_buddy(struct ext4_buddy *e4b) ++{ ++ int count; ++ int order = 1; ++ void *buddy; ++ ++ while ((buddy = mb_find_buddy(e4b, order++, &count))) ++ ext4_set_bits(buddy, 0, count); ++ ++ e4b->bd_info->bb_fragments = 0; ++ memset(e4b->bd_info->bb_counters, 0, ++ sizeof(*e4b->bd_info->bb_counters) * ++ (e4b->bd_sb->s_blocksize_bits + 2)); ++ ++ ext4_mb_generate_buddy(e4b->bd_sb, e4b->bd_buddy, ++ e4b->bd_bitmap, e4b->bd_group); ++} ++ + /* The buddy information is attached the buddy cache inode + * for convenience. The information regarding each group + * is loaded via ext4_mb_load_buddy. The information involve +@@ -1827,6 +1845,8 @@ static void mb_free_blocks(struct inode *inode, struct ext4_buddy *e4b, + ext4_mark_group_bitmap_corrupted( + sb, e4b->bd_group, + EXT4_GROUP_INFO_BBITMAP_CORRUPT); ++ } else { ++ mb_regenerate_buddy(e4b); + } + goto done; + } +-- +2.25.1 + diff --git a/meta-openbmc-mods/meta-common/recipes-kernel/linux/linux-aspeed/CVE-2024-26602.patch b/meta-openbmc-mods/meta-common/recipes-kernel/linux/linux-aspeed/CVE-2024-26602.patch new file mode 100644 index 000000000..b9f68cca6 --- /dev/null +++ b/meta-openbmc-mods/meta-common/recipes-kernel/linux/linux-aspeed/CVE-2024-26602.patch @@ -0,0 +1,89 @@ +From 2441a64070b85c14eecc3728cc87e883f953f265 Mon Sep 17 00:00:00 2001 +From: Linus Torvalds <torvalds@linuxfoundation.org> +Date: Sun, 4 Feb 2024 15:25:12 +0000 +Subject: sched/membarrier: reduce the ability to hammer on sys_membarrier + +commit 944d5fe50f3f03daacfea16300e656a1691c4a23 upstream. + +On some systems, sys_membarrier can be very expensive, causing overall +slowdowns for everything. So put a lock on the path in order to +serialize the accesses to prevent the ability for this to be called at +too high of a frequency and saturate the machine. + +Reviewed-and-tested-by: Mathieu Desnoyers <mathieu.desnoyers@efficios.com> +Acked-by: Borislav Petkov <bp@alien8.de> +Fixes: 22e4ebb97582 ("membarrier: Provide expedited private command") +Fixes: c5f58bd58f43 ("membarrier: Provide GLOBAL_EXPEDITED command") +Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> +[ converted to explicit mutex_*() calls - cleanup.h is not in this stable + branch - gregkh ] +Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> +--- + kernel/sched/membarrier.c | 9 +++++++++ + 1 file changed, 9 insertions(+) + +diff --git a/kernel/sched/membarrier.c b/kernel/sched/membarrier.c +index b5add64d9698..0b5e3e520bf6 100644 +--- a/kernel/sched/membarrier.c ++++ b/kernel/sched/membarrier.c +@@ -161,6 +161,8 @@ + | MEMBARRIER_CMD_REGISTER_PRIVATE_EXPEDITED \ + | MEMBARRIER_PRIVATE_EXPEDITED_SYNC_CORE_BITMASK) + ++static DEFINE_MUTEX(membarrier_ipi_mutex); ++ + static void ipi_mb(void *info) + { + smp_mb(); /* IPIs should be serializing but paranoid. */ +@@ -258,6 +260,7 @@ static int membarrier_global_expedited(void) + if (!zalloc_cpumask_var(&tmpmask, GFP_KERNEL)) + return -ENOMEM; + ++ mutex_lock(&membarrier_ipi_mutex); + cpus_read_lock(); + rcu_read_lock(); + for_each_online_cpu(cpu) { +@@ -303,6 +306,8 @@ static int membarrier_global_expedited(void) + * rq->curr modification in scheduler. + */ + smp_mb(); /* exit from system call is not a mb */ ++ mutex_unlock(&membarrier_ipi_mutex); ++ + return 0; + } + +@@ -346,6 +351,7 @@ static int membarrier_private_expedited(int flags, int cpu_id) + if (cpu_id < 0 && !zalloc_cpumask_var(&tmpmask, GFP_KERNEL)) + return -ENOMEM; + ++ mutex_lock(&membarrier_ipi_mutex); + cpus_read_lock(); + + if (cpu_id >= 0) { +@@ -418,6 +424,7 @@ static int membarrier_private_expedited(int flags, int cpu_id) + * rq->curr modification in scheduler. + */ + smp_mb(); /* exit from system call is not a mb */ ++ mutex_unlock(&membarrier_ipi_mutex); + + return 0; + } +@@ -459,6 +466,7 @@ static int sync_runqueues_membarrier_state(struct mm_struct *mm) + * between threads which are users of @mm has its membarrier state + * updated. + */ ++ mutex_lock(&membarrier_ipi_mutex); + cpus_read_lock(); + rcu_read_lock(); + for_each_online_cpu(cpu) { +@@ -475,6 +483,7 @@ static int sync_runqueues_membarrier_state(struct mm_struct *mm) + + free_cpumask_var(tmpmask); + cpus_read_unlock(); ++ mutex_unlock(&membarrier_ipi_mutex); + + return 0; + } +-- +2.25.1 + diff --git a/meta-openbmc-mods/meta-common/recipes-kernel/linux/linux-aspeed/CVE-2024-26631.patch b/meta-openbmc-mods/meta-common/recipes-kernel/linux/linux-aspeed/CVE-2024-26631.patch new file mode 100644 index 000000000..1020a2c6b --- /dev/null +++ b/meta-openbmc-mods/meta-common/recipes-kernel/linux/linux-aspeed/CVE-2024-26631.patch @@ -0,0 +1,76 @@ +From 2e7ef287f07c74985f1bf2858bedc62bd9ebf155 Mon Sep 17 00:00:00 2001 +From: Nikita Zhandarovich <n.zhandarovich@fintech.ru> +Date: Wed, 17 Jan 2024 09:21:02 -0800 +Subject: ipv6: mcast: fix data-race in ipv6_mc_down / mld_ifc_work + +idev->mc_ifc_count can be written over without proper locking. + +Originally found by syzbot [1], fix this issue by encapsulating calls +to mld_ifc_stop_work() (and mld_gq_stop_work() for good measure) with +mutex_lock() and mutex_unlock() accordingly as these functions +should only be called with mc_lock per their declarations. + +[1] +BUG: KCSAN: data-race in ipv6_mc_down / mld_ifc_work + +write to 0xffff88813a80c832 of 1 bytes by task 3771 on cpu 0: + mld_ifc_stop_work net/ipv6/mcast.c:1080 [inline] + ipv6_mc_down+0x10a/0x280 net/ipv6/mcast.c:2725 + addrconf_ifdown+0xe32/0xf10 net/ipv6/addrconf.c:3949 + addrconf_notify+0x310/0x980 + notifier_call_chain kernel/notifier.c:93 [inline] + raw_notifier_call_chain+0x6b/0x1c0 kernel/notifier.c:461 + __dev_notify_flags+0x205/0x3d0 + dev_change_flags+0xab/0xd0 net/core/dev.c:8685 + do_setlink+0x9f6/0x2430 net/core/rtnetlink.c:2916 + rtnl_group_changelink net/core/rtnetlink.c:3458 [inline] + __rtnl_newlink net/core/rtnetlink.c:3717 [inline] + rtnl_newlink+0xbb3/0x1670 net/core/rtnetlink.c:3754 + rtnetlink_rcv_msg+0x807/0x8c0 net/core/rtnetlink.c:6558 + netlink_rcv_skb+0x126/0x220 net/netlink/af_netlink.c:2545 + rtnetlink_rcv+0x1c/0x20 net/core/rtnetlink.c:6576 + netlink_unicast_kernel net/netlink/af_netlink.c:1342 [inline] + netlink_unicast+0x589/0x650 net/netlink/af_netlink.c:1368 + netlink_sendmsg+0x66e/0x770 net/netlink/af_netlink.c:1910 + ... + +write to 0xffff88813a80c832 of 1 bytes by task 22 on cpu 1: + mld_ifc_work+0x54c/0x7b0 net/ipv6/mcast.c:2653 + process_one_work kernel/workqueue.c:2627 [inline] + process_scheduled_works+0x5b8/0xa30 kernel/workqueue.c:2700 + worker_thread+0x525/0x730 kernel/workqueue.c:2781 + ... + +Fixes: 2d9a93b4902b ("mld: convert from timer to delayed work") +Reported-by: syzbot+a9400cabb1d784e49abf@syzkaller.appspotmail.com +Link: https://lore.kernel.org/all/000000000000994e09060ebcdffb@google.com/ +Signed-off-by: Nikita Zhandarovich <n.zhandarovich@fintech.ru> +Acked-by: Taehee Yoo <ap420073@gmail.com> +Reviewed-by: Eric Dumazet <edumazet@google.com> +Reviewed-by: Hangbin Liu <liuhangbin@gmail.com> +Link: https://lore.kernel.org/r/20240117172102.12001-1-n.zhandarovich@fintech.ru +Signed-off-by: Jakub Kicinski <kuba@kernel.org> +--- + net/ipv6/mcast.c | 4 ++++ + 1 file changed, 4 insertions(+) + +diff --git a/net/ipv6/mcast.c b/net/ipv6/mcast.c +index b75d3c9d41bb50..bc6e0a0bad3c12 100644 +--- a/net/ipv6/mcast.c ++++ b/net/ipv6/mcast.c +@@ -2722,8 +2722,12 @@ void ipv6_mc_down(struct inet6_dev *idev) + synchronize_net(); + mld_query_stop_work(idev); + mld_report_stop_work(idev); ++ ++ mutex_lock(&idev->mc_lock); + mld_ifc_stop_work(idev); + mld_gq_stop_work(idev); ++ mutex_unlock(&idev->mc_lock); ++ + mld_dad_stop_work(idev); + } + +-- +cgit 1.2.3-korg + diff --git a/meta-openbmc-mods/meta-common/recipes-kernel/linux/linux-aspeed/CVE-2024-26671.patch b/meta-openbmc-mods/meta-common/recipes-kernel/linux/linux-aspeed/CVE-2024-26671.patch new file mode 100644 index 000000000..9e9fedb09 --- /dev/null +++ b/meta-openbmc-mods/meta-common/recipes-kernel/linux/linux-aspeed/CVE-2024-26671.patch @@ -0,0 +1,70 @@ +From 1d9c777d3e70bdc57dddf7a14a80059d65919e56 Mon Sep 17 00:00:00 2001 +From: Ming Lei <ming.lei@redhat.com> +Date: Fri, 12 Jan 2024 20:26:26 +0800 +Subject: blk-mq: fix IO hang from sbitmap wakeup race + +[ Upstream commit 5266caaf5660529e3da53004b8b7174cab6374ed ] + +In blk_mq_mark_tag_wait(), __add_wait_queue() may be re-ordered +with the following blk_mq_get_driver_tag() in case of getting driver +tag failure. + +Then in __sbitmap_queue_wake_up(), waitqueue_active() may not observe +the added waiter in blk_mq_mark_tag_wait() and wake up nothing, meantime +blk_mq_mark_tag_wait() can't get driver tag successfully. + +This issue can be reproduced by running the following test in loop, and +fio hang can be observed in < 30min when running it on my test VM +in laptop. + + modprobe -r scsi_debug + modprobe scsi_debug delay=0 dev_size_mb=4096 max_queue=1 host_max_queue=1 submit_queues=4 + dev=`ls -d /sys/bus/pseudo/drivers/scsi_debug/adapter*/host*/target*/*/block/* | head -1 | xargs basename` + fio --filename=/dev/"$dev" --direct=1 --rw=randrw --bs=4k --iodepth=1 \ + --runtime=100 --numjobs=40 --time_based --name=test \ + --ioengine=libaio + +Fix the issue by adding one explicit barrier in blk_mq_mark_tag_wait(), which +is just fine in case of running out of tag. + +Cc: Jan Kara <jack@suse.cz> +Cc: Kemeng Shi <shikemeng@huaweicloud.com> +Reported-by: Changhui Zhong <czhong@redhat.com> +Signed-off-by: Ming Lei <ming.lei@redhat.com> +Link: https://lore.kernel.org/r/20240112122626.4181044-1-ming.lei@redhat.com +Signed-off-by: Jens Axboe <axboe@kernel.dk> +Signed-off-by: Sasha Levin <sashal@kernel.org> +--- + block/blk-mq.c | 16 ++++++++++++++++ + 1 file changed, 16 insertions(+) + +diff --git a/block/blk-mq.c b/block/blk-mq.c +index b3f99dda45300a..c07e5eebcbd853 100644 +--- a/block/blk-mq.c ++++ b/block/blk-mq.c +@@ -1859,6 +1859,22 @@ static bool blk_mq_mark_tag_wait(struct blk_mq_hw_ctx *hctx, + wait->flags &= ~WQ_FLAG_EXCLUSIVE; + __add_wait_queue(wq, wait); + ++ /* ++ * Add one explicit barrier since blk_mq_get_driver_tag() may ++ * not imply barrier in case of failure. ++ * ++ * Order adding us to wait queue and allocating driver tag. ++ * ++ * The pair is the one implied in sbitmap_queue_wake_up() which ++ * orders clearing sbitmap tag bits and waitqueue_active() in ++ * __sbitmap_queue_wake_up(), since waitqueue_active() is lockless ++ * ++ * Otherwise, re-order of adding wait queue and getting driver tag ++ * may cause __sbitmap_queue_wake_up() to wake up nothing because ++ * the waitqueue_active() may not observe us in wait queue. ++ */ ++ smp_mb(); ++ + /* + * It's possible that a tag was freed in the window between the + * allocation failure and adding the hardware queue to the wait +-- +cgit 1.2.3-korg + diff --git a/meta-openbmc-mods/meta-common/recipes-kernel/linux/linux-aspeed/CVE-2024-26676.patch b/meta-openbmc-mods/meta-common/recipes-kernel/linux/linux-aspeed/CVE-2024-26676.patch new file mode 100644 index 000000000..2ff7af39d --- /dev/null +++ b/meta-openbmc-mods/meta-common/recipes-kernel/linux/linux-aspeed/CVE-2024-26676.patch @@ -0,0 +1,107 @@ +From 1279f9d9dec2d7462823a18c29ad61359e0a007d Mon Sep 17 00:00:00 2001 +From: Kuniyuki Iwashima <kuniyu@amazon.com> +Date: Sat, 3 Feb 2024 10:31:49 -0800 +Subject: af_unix: Call kfree_skb() for dead unix_(sk)->oob_skb in GC. + +syzbot reported a warning [0] in __unix_gc() with a repro, which +creates a socketpair and sends one socket's fd to itself using the +peer. + + socketpair(AF_UNIX, SOCK_STREAM, 0, [3, 4]) = 0 + sendmsg(4, {msg_name=NULL, msg_namelen=0, msg_iov=[{iov_base="\360", iov_len=1}], + msg_iovlen=1, msg_control=[{cmsg_len=20, cmsg_level=SOL_SOCKET, + cmsg_type=SCM_RIGHTS, cmsg_data=[3]}], + msg_controllen=24, msg_flags=0}, MSG_OOB|MSG_PROBE|MSG_DONTWAIT|MSG_ZEROCOPY) = 1 + +This forms a self-cyclic reference that GC should finally untangle +but does not due to lack of MSG_OOB handling, resulting in memory +leak. + +Recently, commit 11498715f266 ("af_unix: Remove io_uring code for +GC.") removed io_uring's dead code in GC and revealed the problem. + +The code was executed at the final stage of GC and unconditionally +moved all GC candidates from gc_candidates to gc_inflight_list. +That papered over the reported problem by always making the following +WARN_ON_ONCE(!list_empty(&gc_candidates)) false. + +The problem has been there since commit 2aab4b969002 ("af_unix: fix +struct pid leaks in OOB support") added full scm support for MSG_OOB +while fixing another bug. + +To fix this problem, we must call kfree_skb() for unix_sk(sk)->oob_skb +if the socket still exists in gc_candidates after purging collected skb. + +Then, we need to set NULL to oob_skb before calling kfree_skb() because +it calls last fput() and triggers unix_release_sock(), where we call +duplicate kfree_skb(u->oob_skb) if not NULL. + +Note that the leaked socket remained being linked to a global list, so +kmemleak also could not detect it. We need to check /proc/net/protocol +to notice the unfreed socket. + +[0]: +WARNING: CPU: 0 PID: 2863 at net/unix/garbage.c:345 __unix_gc+0xc74/0xe80 net/unix/garbage.c:345 +Modules linked in: +CPU: 0 PID: 2863 Comm: kworker/u4:11 Not tainted 6.8.0-rc1-syzkaller-00583-g1701940b1a02 #0 +Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/25/2024 +Workqueue: events_unbound __unix_gc +RIP: 0010:__unix_gc+0xc74/0xe80 net/unix/garbage.c:345 +Code: 8b 5c 24 50 e9 86 f8 ff ff e8 f8 e4 22 f8 31 d2 48 c7 c6 30 6a 69 89 4c 89 ef e8 97 ef ff ff e9 80 f9 ff ff e8 dd e4 22 f8 90 <0f> 0b 90 e9 7b fd ff ff 48 89 df e8 5c e7 7c f8 e9 d3 f8 ff ff e8 +RSP: 0018:ffffc9000b03fba0 EFLAGS: 00010293 +RAX: 0000000000000000 RBX: ffffc9000b03fc10 RCX: ffffffff816c493e +RDX: ffff88802c02d940 RSI: ffffffff896982f3 RDI: ffffc9000b03fb30 +RBP: ffffc9000b03fce0 R08: 0000000000000001 R09: fffff52001607f66 +R10: 0000000000000003 R11: 0000000000000002 R12: dffffc0000000000 +R13: ffffc9000b03fc10 R14: ffffc9000b03fc10 R15: 0000000000000001 +FS: 0000000000000000(0000) GS:ffff8880b9400000(0000) knlGS:0000000000000000 +CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 +CR2: 00005559c8677a60 CR3: 000000000d57a000 CR4: 00000000003506f0 +DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 +DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 +Call Trace: + <TASK> + process_one_work+0x889/0x15e0 kernel/workqueue.c:2633 + process_scheduled_works kernel/workqueue.c:2706 [inline] + worker_thread+0x8b9/0x12a0 kernel/workqueue.c:2787 + kthread+0x2c6/0x3b0 kernel/kthread.c:388 + ret_from_fork+0x45/0x80 arch/x86/kernel/process.c:147 + ret_from_fork_asm+0x1b/0x30 arch/x86/entry/entry_64.S:242 + </TASK> + +Reported-by: syzbot+fa3ef895554bdbfd1183@syzkaller.appspotmail.com +Closes: https://syzkaller.appspot.com/bug?extid=fa3ef895554bdbfd1183 +Fixes: 2aab4b969002 ("af_unix: fix struct pid leaks in OOB support") +Signed-off-by: Kuniyuki Iwashima <kuniyu@amazon.com> +Reviewed-by: Eric Dumazet <edumazet@google.com> +Link: https://lore.kernel.org/r/20240203183149.63573-1-kuniyu@amazon.com +Signed-off-by: Jakub Kicinski <kuba@kernel.org> +--- + net/unix/garbage.c | 11 +++++++++++ + 1 file changed, 11 insertions(+) + +diff --git a/net/unix/garbage.c b/net/unix/garbage.c +index 2405f0f9af31c0..8f63f0b4bf0129 100644 +--- a/net/unix/garbage.c ++++ b/net/unix/garbage.c +@@ -314,6 +314,17 @@ void unix_gc(void) + /* Here we are. Hitlist is filled. Die. */ + __skb_queue_purge(&hitlist); + ++#if IS_ENABLED(CONFIG_AF_UNIX_OOB) ++ list_for_each_entry_safe(u, next, &gc_candidates, link) { ++ struct sk_buff *skb = u->oob_skb; ++ ++ if (skb) { ++ u->oob_skb = NULL; ++ kfree_skb(skb); ++ } ++ } ++#endif ++ + spin_lock(&unix_gc_lock); + + /* All candidates should have been detached by now. */ +-- +cgit 1.2.3-korg + diff --git a/meta-openbmc-mods/meta-common/recipes-kernel/linux/linux-aspeed/CVE-2024-26679.patch b/meta-openbmc-mods/meta-common/recipes-kernel/linux/linux-aspeed/CVE-2024-26679.patch new file mode 100644 index 000000000..3c2827929 --- /dev/null +++ b/meta-openbmc-mods/meta-common/recipes-kernel/linux/linux-aspeed/CVE-2024-26679.patch @@ -0,0 +1,44 @@ +From 307fa8a75ab7423fa5c73573ec3d192de5027830 Mon Sep 17 00:00:00 2001 +From: Eric Dumazet <edumazet@google.com> +Date: Fri, 2 Feb 2024 09:54:04 +0000 +Subject: inet: read sk->sk_family once in inet_recv_error() + +[ Upstream commit eef00a82c568944f113f2de738156ac591bbd5cd ] + +inet_recv_error() is called without holding the socket lock. + +IPv6 socket could mutate to IPv4 with IPV6_ADDRFORM +socket option and trigger a KCSAN warning. + +Fixes: f4713a3dfad0 ("net-timestamp: make tcp_recvmsg call ipv6_recv_error for AF_INET6 socks") +Signed-off-by: Eric Dumazet <edumazet@google.com> +Cc: Willem de Bruijn <willemb@google.com> +Reviewed-by: Willem de Bruijn <willemb@google.com> +Signed-off-by: David S. Miller <davem@davemloft.net> +Signed-off-by: Sasha Levin <sashal@kernel.org> +--- + net/ipv4/af_inet.c | 6 ++++-- + 1 file changed, 4 insertions(+), 2 deletions(-) + +diff --git a/net/ipv4/af_inet.c b/net/ipv4/af_inet.c +index 1c58bd72e1245d..e59962f34caa6c 100644 +--- a/net/ipv4/af_inet.c ++++ b/net/ipv4/af_inet.c +@@ -1628,10 +1628,12 @@ EXPORT_SYMBOL(inet_current_timestamp); + + int inet_recv_error(struct sock *sk, struct msghdr *msg, int len, int *addr_len) + { +- if (sk->sk_family == AF_INET) ++ unsigned int family = READ_ONCE(sk->sk_family); ++ ++ if (family == AF_INET) + return ip_recv_error(sk, msg, len, addr_len); + #if IS_ENABLED(CONFIG_IPV6) +- if (sk->sk_family == AF_INET6) ++ if (family == AF_INET6) + return pingv6_ops.ipv6_recv_error(sk, msg, len, addr_len); + #endif + return -EINVAL; +-- +cgit 1.2.3-korg + diff --git a/meta-openbmc-mods/meta-common/recipes-kernel/linux/linux-aspeed/CVE-2024-26686.patch b/meta-openbmc-mods/meta-common/recipes-kernel/linux/linux-aspeed/CVE-2024-26686.patch new file mode 100644 index 000000000..7bed5bc46 --- /dev/null +++ b/meta-openbmc-mods/meta-common/recipes-kernel/linux/linux-aspeed/CVE-2024-26686.patch @@ -0,0 +1,161 @@ +From 27978243f165b44e342f28f449b91327944ea071 Mon Sep 17 00:00:00 2001 +From: Oleg Nesterov <oleg@redhat.com> +Date: Tue, 23 Jan 2024 16:33:57 +0100 +Subject: [PATCH] fs/proc: do_task_stat: use sig->stats_lock to gather the + threads/children stats + +commit 7601df8031fd67310af891897ef6cc0df4209305 upstream. + +lock_task_sighand() can trigger a hard lockup. If NR_CPUS threads call +do_task_stat() at the same time and the process has NR_THREADS, it will +spin with irqs disabled O(NR_CPUS * NR_THREADS) time. + +Change do_task_stat() to use sig->stats_lock to gather the statistics +outside of ->siglock protected section, in the likely case this code will +run lockless. + +Link: https://lkml.kernel.org/r/20240123153357.GA21857@redhat.com +Signed-off-by: Oleg Nesterov <oleg@redhat.com> +Signed-off-by: Dylan Hatch <dylanbhatch@google.com> +Cc: Eric W. Biederman <ebiederm@xmission.com> +Cc: <stable@vger.kernel.org> +Signed-off-by: Andrew Morton <akpm@linux-foundation.org> +Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> +--- + fs/proc/array.c | 76 ++++++++++++++++++++++++++++--------------------- + 1 file changed, 43 insertions(+), 33 deletions(-) + +diff --git a/fs/proc/array.c b/fs/proc/array.c +index 49be8c8ef555..c6b840e25151 100644 +--- a/fs/proc/array.c ++++ b/fs/proc/array.c +@@ -462,12 +462,13 @@ static int do_task_stat(struct seq_file *m, struct pid_namespace *ns, + int permitted; + struct mm_struct *mm; + unsigned long long start_time; +- unsigned long cmin_flt = 0, cmaj_flt = 0; +- unsigned long min_flt = 0, maj_flt = 0; +- u64 cutime, cstime, utime, stime; +- u64 cgtime, gtime; ++ unsigned long cmin_flt, cmaj_flt, min_flt, maj_flt; ++ u64 cutime, cstime, cgtime, utime, stime, gtime; + unsigned long rsslim = 0; + unsigned long flags; ++ int exit_code = task->exit_code; ++ struct signal_struct *sig = task->signal; ++ unsigned int seq = 1; + + state = *get_task_state(task); + vsize = eip = esp = 0; +@@ -495,12 +496,8 @@ static int do_task_stat(struct seq_file *m, struct pid_namespace *ns, + + sigemptyset(&sigign); + sigemptyset(&sigcatch); +- cutime = cstime = utime = stime = 0; +- cgtime = gtime = 0; + + if (lock_task_sighand(task, &flags)) { +- struct signal_struct *sig = task->signal; +- + if (sig->tty) { + struct pid *pgrp = tty_get_pgrp(sig->tty); + tty_pgrp = pid_nr_ns(pgrp, ns); +@@ -511,26 +508,11 @@ static int do_task_stat(struct seq_file *m, struct pid_namespace *ns, + num_threads = get_nr_threads(task); + collect_sigign_sigcatch(task, &sigign, &sigcatch); + +- cmin_flt = sig->cmin_flt; +- cmaj_flt = sig->cmaj_flt; +- cutime = sig->cutime; +- cstime = sig->cstime; +- cgtime = sig->cgtime; + rsslim = READ_ONCE(sig->rlim[RLIMIT_RSS].rlim_cur); + +- /* add up live thread stats at the group level */ + if (whole) { +- struct task_struct *t = task; +- do { +- min_flt += t->min_flt; +- maj_flt += t->maj_flt; +- gtime += task_gtime(t); +- } while_each_thread(task, t); +- +- min_flt += sig->min_flt; +- maj_flt += sig->maj_flt; +- thread_group_cputime_adjusted(task, &utime, &stime); +- gtime += sig->gtime; ++ if (sig->flags & (SIGNAL_GROUP_EXIT | SIGNAL_STOP_STOPPED)) ++ exit_code = sig->group_exit_code; + } + + sid = task_session_nr_ns(task, ns); +@@ -541,11 +523,42 @@ static int do_task_stat(struct seq_file *m, struct pid_namespace *ns, + } + + if (permitted && (!whole || num_threads < 2)) +- wchan = get_wchan(task); +- if (!whole) { ++ wchan = !task_is_running(task); ++ ++ do { ++ seq++; /* 2 on the 1st/lockless path, otherwise odd */ ++ flags = read_seqbegin_or_lock_irqsave(&sig->stats_lock, &seq); ++ ++ cmin_flt = sig->cmin_flt; ++ cmaj_flt = sig->cmaj_flt; ++ cutime = sig->cutime; ++ cstime = sig->cstime; ++ cgtime = sig->cgtime; ++ ++ if (whole) { ++ struct task_struct *t; ++ ++ min_flt = sig->min_flt; ++ maj_flt = sig->maj_flt; ++ gtime = sig->gtime; ++ ++ rcu_read_lock(); ++ __for_each_thread(sig, t) { ++ min_flt += t->min_flt; ++ maj_flt += t->maj_flt; ++ gtime += task_gtime(t); ++ } ++ rcu_read_unlock(); ++ } ++ } while (need_seqretry(&sig->stats_lock, seq)); ++ done_seqretry_irqrestore(&sig->stats_lock, seq, flags); ++ ++ if (whole) { ++ thread_group_cputime_adjusted(task, &utime, &stime); ++ } else { ++ task_cputime_adjusted(task, &utime, &stime); + min_flt = task->min_flt; + maj_flt = task->maj_flt; +- task_cputime_adjusted(task, &utime, &stime); + gtime = task_gtime(task); + } + +@@ -606,10 +619,7 @@ static int do_task_stat(struct seq_file *m, struct pid_namespace *ns, + * + * This works with older implementations of procps as well. + */ +- if (wchan) +- seq_puts(m, " 1"); +- else +- seq_puts(m, " 0"); ++ seq_put_decimal_ull(m, " ", wchan); + + seq_put_decimal_ull(m, " ", 0); + seq_put_decimal_ull(m, " ", 0); +@@ -633,7 +643,7 @@ static int do_task_stat(struct seq_file *m, struct pid_namespace *ns, + seq_puts(m, " 0 0 0 0 0 0 0"); + + if (permitted) +- seq_put_decimal_ll(m, " ", task->exit_code); ++ seq_put_decimal_ll(m, " ", exit_code); + else + seq_puts(m, " 0"); + +-- +2.25.1 + diff --git a/meta-openbmc-mods/meta-common/recipes-kernel/linux/linux-aspeed/CVE-2024-26704.patch b/meta-openbmc-mods/meta-common/recipes-kernel/linux/linux-aspeed/CVE-2024-26704.patch new file mode 100644 index 000000000..0fb6d112d --- /dev/null +++ b/meta-openbmc-mods/meta-common/recipes-kernel/linux/linux-aspeed/CVE-2024-26704.patch @@ -0,0 +1,71 @@ +From 185eab30486ba3e7bf8b9c2e049c79a06ffd2bc1 Mon Sep 17 00:00:00 2001 +From: Baokun Li <libaokun1@huawei.com> +Date: Thu, 4 Jan 2024 22:20:33 +0800 +Subject: ext4: fix double-free of blocks due to wrong extents moved_len + +commit 55583e899a5357308274601364741a83e78d6ac4 upstream. + +In ext4_move_extents(), moved_len is only updated when all moves are +successfully executed, and only discards orig_inode and donor_inode +preallocations when moved_len is not zero. When the loop fails to exit +after successfully moving some extents, moved_len is not updated and +remains at 0, so it does not discard the preallocations. + +If the moved extents overlap with the preallocated extents, the +overlapped extents are freed twice in ext4_mb_release_inode_pa() and +ext4_process_freed_data() (as described in commit 94d7c16cbbbd ("ext4: +Fix double-free of blocks with EXT4_IOC_MOVE_EXT")), and bb_free is +incremented twice. Hence when trim is executed, a zero-division bug is +triggered in mb_update_avg_fragment_size() because bb_free is not zero +and bb_fragments is zero. + +Therefore, update move_len after each extent move to avoid the issue. + +Reported-by: Wei Chen <harperchen1110@gmail.com> +Reported-by: xingwei lee <xrivendell7@gmail.com> +Closes: https://lore.kernel.org/r/CAO4mrferzqBUnCag8R3m2zf897ts9UEuhjFQGPtODT92rYyR2Q@mail.gmail.com +Fixes: fcf6b1b729bc ("ext4: refactor ext4_move_extents code base") +CC: <stable@vger.kernel.org> # 3.18 +Signed-off-by: Baokun Li <libaokun1@huawei.com> +Reviewed-by: Jan Kara <jack@suse.cz> +Link: https://lore.kernel.org/r/20240104142040.2835097-2-libaokun1@huawei.com +Signed-off-by: Theodore Ts'o <tytso@mit.edu> +Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> +--- + fs/ext4/move_extent.c | 6 ++---- + 1 file changed, 2 insertions(+), 4 deletions(-) + +diff --git a/fs/ext4/move_extent.c b/fs/ext4/move_extent.c +index dedc9d445f2433..8e3ff150bc36b1 100644 +--- a/fs/ext4/move_extent.c ++++ b/fs/ext4/move_extent.c +@@ -621,6 +621,7 @@ ext4_move_extents(struct file *o_filp, struct file *d_filp, __u64 orig_blk, + goto out; + o_end = o_start + len; + ++ *moved_len = 0; + while (o_start < o_end) { + struct ext4_extent *ex; + ext4_lblk_t cur_blk, next_blk; +@@ -675,7 +676,7 @@ ext4_move_extents(struct file *o_filp, struct file *d_filp, __u64 orig_blk, + */ + ext4_double_up_write_data_sem(orig_inode, donor_inode); + /* Swap original branches with new branches */ +- move_extent_per_page(o_filp, donor_inode, ++ *moved_len += move_extent_per_page(o_filp, donor_inode, + orig_page_index, donor_page_index, + offset_in_page, cur_len, + unwritten, &ret); +@@ -685,9 +686,6 @@ ext4_move_extents(struct file *o_filp, struct file *d_filp, __u64 orig_blk, + o_start += cur_len; + d_start += cur_len; + } +- *moved_len = o_start - orig_blk; +- if (*moved_len > len) +- *moved_len = len; + + out: + if (*moved_len) { +-- +cgit 1.2.3-korg + diff --git a/meta-openbmc-mods/meta-common/recipes-kernel/linux/linux-aspeed/CVE-2024-26720.patch b/meta-openbmc-mods/meta-common/recipes-kernel/linux/linux-aspeed/CVE-2024-26720.patch new file mode 100644 index 000000000..0bb927550 --- /dev/null +++ b/meta-openbmc-mods/meta-common/recipes-kernel/linux/linux-aspeed/CVE-2024-26720.patch @@ -0,0 +1,49 @@ +From 16b1025eaa8fc223ab4273ece20d1c3a4211a95d Mon Sep 17 00:00:00 2001 +From: Zach O'Keefe <zokeefe@google.com> +Date: Thu, 18 Jan 2024 10:19:53 -0800 +Subject: mm/writeback: fix possible divide-by-zero in wb_dirty_limits(), again + +commit 9319b647902cbd5cc884ac08a8a6d54ce111fc78 upstream. + +(struct dirty_throttle_control *)->thresh is an unsigned long, but is +passed as the u32 divisor argument to div_u64(). On architectures where +unsigned long is 64 bytes, the argument will be implicitly truncated. + +Use div64_u64() instead of div_u64() so that the value used in the "is +this a safe division" check is the same as the divisor. + +Also, remove redundant cast of the numerator to u64, as that should happen +implicitly. + +This would be difficult to exploit in memcg domain, given the ratio-based +arithmetic domain_drity_limits() uses, but is much easier in global +writeback domain with a BDI_CAP_STRICTLIMIT-backing device, using e.g. +vm.dirty_bytes=(1<<32)*PAGE_SIZE so that dtc->thresh == (1<<32) + +Link: https://lkml.kernel.org/r/20240118181954.1415197-1-zokeefe@google.com +Fixes: f6789593d5ce ("mm/page-writeback.c: fix divide by zero in bdi_dirty_limits()") +Signed-off-by: Zach O'Keefe <zokeefe@google.com> +Cc: Maxim Patlasov <MPatlasov@parallels.com> +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(-) + +diff --git a/mm/page-writeback.c b/mm/page-writeback.c +index de5f69921b9465..d3e9d12860b9f4 100644 +--- a/mm/page-writeback.c ++++ b/mm/page-writeback.c +@@ -1526,7 +1526,7 @@ static inline void wb_dirty_limits(struct dirty_throttle_control *dtc) + */ + dtc->wb_thresh = __wb_calc_thresh(dtc); + dtc->wb_bg_thresh = dtc->thresh ? +- div_u64((u64)dtc->wb_thresh * dtc->bg_thresh, dtc->thresh) : 0; ++ div64_u64(dtc->wb_thresh * dtc->bg_thresh, dtc->thresh) : 0; + + /* + * In order to avoid the stacked BDI deadlock we need +-- +cgit 1.2.3-korg + diff --git a/meta-openbmc-mods/meta-common/recipes-kernel/linux/linux-aspeed/CVE-2024-26735.patch b/meta-openbmc-mods/meta-common/recipes-kernel/linux/linux-aspeed/CVE-2024-26735.patch new file mode 100644 index 000000000..5446d2696 --- /dev/null +++ b/meta-openbmc-mods/meta-common/recipes-kernel/linux/linux-aspeed/CVE-2024-26735.patch @@ -0,0 +1,72 @@ +From 02b08db594e8218cfbc0e4680d4331b457968a9b Mon Sep 17 00:00:00 2001 +From: Vasiliy Kovalev <kovalev@altlinux.org> +Date: Thu, 15 Feb 2024 23:27:17 +0300 +Subject: ipv6: sr: fix possible use-after-free and null-ptr-deref + +[ Upstream commit 5559cea2d5aa3018a5f00dd2aca3427ba09b386b ] + +The pernet operations structure for the subsystem must be registered +before registering the generic netlink family. + +Fixes: 915d7e5e5930 ("ipv6: sr: add code base for control plane support of SR-IPv6") +Signed-off-by: Vasiliy Kovalev <kovalev@altlinux.org> +Link: https://lore.kernel.org/r/20240215202717.29815-1-kovalev@altlinux.org +Signed-off-by: Paolo Abeni <pabeni@redhat.com> +Signed-off-by: Sasha Levin <sashal@kernel.org> +--- + net/ipv6/seg6.c | 20 +++++++++++--------- + 1 file changed, 11 insertions(+), 9 deletions(-) + +diff --git a/net/ipv6/seg6.c b/net/ipv6/seg6.c +index 29346a6eec9ffe..35508abd76f43d 100644 +--- a/net/ipv6/seg6.c ++++ b/net/ipv6/seg6.c +@@ -512,22 +512,24 @@ int __init seg6_init(void) + { + int err; + +- err = genl_register_family(&seg6_genl_family); ++ err = register_pernet_subsys(&ip6_segments_ops); + if (err) + goto out; + +- err = register_pernet_subsys(&ip6_segments_ops); ++ err = genl_register_family(&seg6_genl_family); + if (err) +- goto out_unregister_genl; ++ goto out_unregister_pernet; + + #ifdef CONFIG_IPV6_SEG6_LWTUNNEL + err = seg6_iptunnel_init(); + if (err) +- goto out_unregister_pernet; ++ goto out_unregister_genl; + + err = seg6_local_init(); +- if (err) +- goto out_unregister_pernet; ++ if (err) { ++ seg6_iptunnel_exit(); ++ goto out_unregister_genl; ++ } + #endif + + #ifdef CONFIG_IPV6_SEG6_HMAC +@@ -548,11 +550,11 @@ out_unregister_iptun: + #endif + #endif + #ifdef CONFIG_IPV6_SEG6_LWTUNNEL +-out_unregister_pernet: +- unregister_pernet_subsys(&ip6_segments_ops); +-#endif + out_unregister_genl: + genl_unregister_family(&seg6_genl_family); ++#endif ++out_unregister_pernet: ++ unregister_pernet_subsys(&ip6_segments_ops); + goto out; + } + +-- +cgit 1.2.3-korg + diff --git a/meta-openbmc-mods/meta-common/recipes-kernel/linux/linux-aspeed/CVE-2024-26772.patch b/meta-openbmc-mods/meta-common/recipes-kernel/linux/linux-aspeed/CVE-2024-26772.patch new file mode 100644 index 000000000..0a2e78077 --- /dev/null +++ b/meta-openbmc-mods/meta-common/recipes-kernel/linux/linux-aspeed/CVE-2024-26772.patch @@ -0,0 +1,52 @@ +From 21dbe20589c7f48e9c5d336ce6402bcebfa6d76a Mon Sep 17 00:00:00 2001 +From: Baokun Li <libaokun1@huawei.com> +Date: Thu, 4 Jan 2024 22:20:39 +0800 +Subject: ext4: avoid allocating blocks from corrupted group in + ext4_mb_find_by_goal() + +[ Upstream commit 832698373a25950942c04a512daa652c18a9b513 ] + +Places the logic for checking if the group's block bitmap is corrupt under +the protection of the group lock to avoid allocating blocks from the group +with a corrupted block bitmap. + +Signed-off-by: Baokun Li <libaokun1@huawei.com> +Reviewed-by: Jan Kara <jack@suse.cz> +Link: https://lore.kernel.org/r/20240104142040.2835097-8-libaokun1@huawei.com +Signed-off-by: Theodore Ts'o <tytso@mit.edu> +Signed-off-by: Sasha Levin <sashal@kernel.org> +--- + fs/ext4/mballoc.c | 9 ++++----- + 1 file changed, 4 insertions(+), 5 deletions(-) + +diff --git a/fs/ext4/mballoc.c b/fs/ext4/mballoc.c +index 1bc615d6219171..7497a789d002eb 100644 +--- a/fs/ext4/mballoc.c ++++ b/fs/ext4/mballoc.c +@@ -2342,12 +2342,10 @@ int ext4_mb_find_by_goal(struct ext4_allocation_context *ac, + if (err) + return err; + +- if (unlikely(EXT4_MB_GRP_BBITMAP_CORRUPT(e4b->bd_info))) { +- ext4_mb_unload_buddy(e4b); +- return 0; +- } +- + ext4_lock_group(ac->ac_sb, group); ++ if (unlikely(EXT4_MB_GRP_BBITMAP_CORRUPT(e4b->bd_info))) ++ goto out; ++ + max = mb_find_extent(e4b, ac->ac_g_ex.fe_start, + ac->ac_g_ex.fe_len, &ex); + ex.fe_logical = 0xDEADFA11; /* debug value */ +@@ -2380,6 +2378,7 @@ int ext4_mb_find_by_goal(struct ext4_allocation_context *ac, + ac->ac_b_ex = ex; + ext4_mb_use_best_found(ac, e4b); + } ++out: + ext4_unlock_group(ac->ac_sb, group); + ext4_mb_unload_buddy(e4b); + +-- +cgit 1.2.3-korg + diff --git a/meta-openbmc-mods/meta-common/recipes-kernel/linux/linux-aspeed/CVE-2024-26773.patch b/meta-openbmc-mods/meta-common/recipes-kernel/linux/linux-aspeed/CVE-2024-26773.patch new file mode 100644 index 000000000..c5bf1503c --- /dev/null +++ b/meta-openbmc-mods/meta-common/recipes-kernel/linux/linux-aspeed/CVE-2024-26773.patch @@ -0,0 +1,63 @@ +From 21f8cfe79f776287459343e9cfa6055af61328ea Mon Sep 17 00:00:00 2001 +From: Baokun Li <libaokun1@huawei.com> +Date: Thu, 4 Jan 2024 22:20:38 +0800 +Subject: ext4: avoid allocating blocks from corrupted group in + ext4_mb_try_best_found() + +[ Upstream commit 4530b3660d396a646aad91a787b6ab37cf604b53 ] + +Determine if the group block bitmap is corrupted before using ac_b_ex in +ext4_mb_try_best_found() to avoid allocating blocks from a group with a +corrupted block bitmap in the following concurrency and making the +situation worse. + +ext4_mb_regular_allocator + ext4_lock_group(sb, group) + ext4_mb_good_group + // check if the group bbitmap is corrupted + ext4_mb_complex_scan_group + // Scan group gets ac_b_ex but doesn't use it + ext4_unlock_group(sb, group) + ext4_mark_group_bitmap_corrupted(group) + // The block bitmap was corrupted during + // the group unlock gap. + ext4_mb_try_best_found + ext4_lock_group(ac->ac_sb, group) + ext4_mb_use_best_found + mb_mark_used + // Allocating blocks in block bitmap corrupted group + +Signed-off-by: Baokun Li <libaokun1@huawei.com> +Reviewed-by: Jan Kara <jack@suse.cz> +Link: https://lore.kernel.org/r/20240104142040.2835097-7-libaokun1@huawei.com +Signed-off-by: Theodore Ts'o <tytso@mit.edu> +Signed-off-by: Sasha Levin <sashal@kernel.org> +--- + fs/ext4/mballoc.c | 4 ++++ + 1 file changed, 4 insertions(+) + +diff --git a/fs/ext4/mballoc.c b/fs/ext4/mballoc.c +index df390979058fd7..e0dd01cb1a0e77 100644 +--- a/fs/ext4/mballoc.c ++++ b/fs/ext4/mballoc.c +@@ -1802,6 +1802,9 @@ int ext4_mb_try_best_found(struct ext4_allocation_context *ac, + return err; + + ext4_lock_group(ac->ac_sb, group); ++ if (unlikely(EXT4_MB_GRP_BBITMAP_CORRUPT(e4b->bd_info))) ++ goto out; ++ + max = mb_find_extent(e4b, ex.fe_start, ex.fe_len, &ex); + + if (max > 0) { +@@ -1809,6 +1812,7 @@ int ext4_mb_try_best_found(struct ext4_allocation_context *ac, + ext4_mb_use_best_found(ac, e4b); + } + ++out: + ext4_unlock_group(ac->ac_sb, group); + ext4_mb_unload_buddy(e4b); + +-- +cgit 1.2.3-korg + diff --git a/meta-openbmc-mods/meta-common/recipes-kernel/linux/linux-aspeed/CVE-2024-26774.patch b/meta-openbmc-mods/meta-common/recipes-kernel/linux/linux-aspeed/CVE-2024-26774.patch new file mode 100644 index 000000000..b16497843 --- /dev/null +++ b/meta-openbmc-mods/meta-common/recipes-kernel/linux/linux-aspeed/CVE-2024-26774.patch @@ -0,0 +1,36 @@ +From 687061cfaa2ac3095170e136dd9c29a4974f41d4 Mon Sep 17 00:00:00 2001 +From: Baokun Li <libaokun1@huawei.com> +Date: Thu, 4 Jan 2024 22:20:37 +0800 +Subject: ext4: avoid dividing by 0 in mb_update_avg_fragment_size() when block + bitmap corrupt + +[ Upstream commit 993bf0f4c393b3667830918f9247438a8f6fdb5b ] + +Determine if bb_fragments is 0 instead of determining bb_free to eliminate +the risk of dividing by zero when the block bitmap is corrupted. + +Signed-off-by: Baokun Li <libaokun1@huawei.com> +Reviewed-by: Jan Kara <jack@suse.cz> +Link: https://lore.kernel.org/r/20240104142040.2835097-6-libaokun1@huawei.com +Signed-off-by: Theodore Ts'o <tytso@mit.edu> +Signed-off-by: Sasha Levin <sashal@kernel.org> +--- + fs/ext4/mballoc.c | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +diff --git a/fs/ext4/mballoc.c b/fs/ext4/mballoc.c +index 762c2f8b5b2a86..48930df9ae565b 100644 +--- a/fs/ext4/mballoc.c ++++ b/fs/ext4/mballoc.c +@@ -853,7 +853,7 @@ mb_update_avg_fragment_size(struct super_block *sb, struct ext4_group_info *grp) + { + struct ext4_sb_info *sbi = EXT4_SB(sb); + +- if (!test_opt2(sb, MB_OPTIMIZE_SCAN) || grp->bb_free == 0) ++ if (!test_opt2(sb, MB_OPTIMIZE_SCAN) || grp->bb_fragments == 0) + return; + + write_lock(&sbi->s_mb_rb_lock); +-- +cgit 1.2.3-korg + diff --git a/meta-openbmc-mods/meta-common/recipes-kernel/linux/linux-aspeed/CVE-2024-26795.patch b/meta-openbmc-mods/meta-common/recipes-kernel/linux/linux-aspeed/CVE-2024-26795.patch new file mode 100644 index 000000000..fe34515b7 --- /dev/null +++ b/meta-openbmc-mods/meta-common/recipes-kernel/linux/linux-aspeed/CVE-2024-26795.patch @@ -0,0 +1,48 @@ +From 2a1728c15ec4f45ed9248ae22f626541c179bfbe Mon Sep 17 00:00:00 2001 +From: Dimitris Vlachos <dvlachos@ics.forth.gr> +Date: Thu, 29 Feb 2024 21:17:23 +0200 +Subject: riscv: Sparse-Memory/vmemmap out-of-bounds fix +MIME-Version: 1.0 +Content-Type: text/plain; charset=UTF-8 +Content-Transfer-Encoding: 8bit + +[ Upstream commit a11dd49dcb9376776193e15641f84fcc1e5980c9 ] + +Offset vmemmap so that the first page of vmemmap will be mapped +to the first page of physical memory in order to ensure that +vmemmap’s bounds will be respected during +pfn_to_page()/page_to_pfn() operations. +The conversion macros will produce correct SV39/48/57 addresses +for every possible/valid DRAM_BASE inside the physical memory limits. + +v2:Address Alex's comments + +Suggested-by: Alexandre Ghiti <alexghiti@rivosinc.com> +Signed-off-by: Dimitris Vlachos <dvlachos@ics.forth.gr> +Reported-by: Dimitris Vlachos <dvlachos@ics.forth.gr> +Closes: https://lore.kernel.org/linux-riscv/20240202135030.42265-1-csd4492@csd.uoc.gr +Fixes: d95f1a542c3d ("RISC-V: Implement sparsemem") +Reviewed-by: Alexandre Ghiti <alexghiti@rivosinc.com> +Link: https://lore.kernel.org/r/20240229191723.32779-1-dvlachos@ics.forth.gr +Signed-off-by: Palmer Dabbelt <palmer@rivosinc.com> +Signed-off-by: Sasha Levin <sashal@kernel.org> +--- + arch/riscv/include/asm/pgtable.h | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +diff --git a/arch/riscv/include/asm/pgtable.h b/arch/riscv/include/asm/pgtable.h +index ec8468ddad4a09..76b131e7bbcad4 100644 +--- a/arch/riscv/include/asm/pgtable.h ++++ b/arch/riscv/include/asm/pgtable.h +@@ -84,7 +84,7 @@ + * Define vmemmap for pfn_to_page & page_to_pfn calls. Needed if kernel + * is configured with CONFIG_SPARSEMEM_VMEMMAP enabled. + */ +-#define vmemmap ((struct page *)VMEMMAP_START) ++#define vmemmap ((struct page *)VMEMMAP_START - (phys_ram_base >> PAGE_SHIFT)) + + #define PCI_IO_SIZE SZ_16M + #define PCI_IO_END VMEMMAP_START +-- +cgit 1.2.3-korg + diff --git a/meta-openbmc-mods/meta-common/recipes-kernel/linux/linux-aspeed/CVE-2024-26900.patch b/meta-openbmc-mods/meta-common/recipes-kernel/linux/linux-aspeed/CVE-2024-26900.patch new file mode 100644 index 000000000..eecc87e6e --- /dev/null +++ b/meta-openbmc-mods/meta-common/recipes-kernel/linux/linux-aspeed/CVE-2024-26900.patch @@ -0,0 +1,67 @@ +From 3948abaa4e2be938ccdfc289385a27342fb13d43 Mon Sep 17 00:00:00 2001 +From: Nikita Zhandarovich <n.zhandarovich@fintech.ru> +Date: Fri, 19 Jan 2024 07:39:06 -0800 +Subject: do_sys_name_to_handle(): use kzalloc() to fix kernel-infoleak + +syzbot identified a kernel information leak vulnerability in +do_sys_name_to_handle() and issued the following report [1]. + +[1] +"BUG: KMSAN: kernel-infoleak in instrument_copy_to_user include/linux/instrumented.h:114 [inline] +BUG: KMSAN: kernel-infoleak in _copy_to_user+0xbc/0x100 lib/usercopy.c:40 + instrument_copy_to_user include/linux/instrumented.h:114 [inline] + _copy_to_user+0xbc/0x100 lib/usercopy.c:40 + copy_to_user include/linux/uaccess.h:191 [inline] + do_sys_name_to_handle fs/fhandle.c:73 [inline] + __do_sys_name_to_handle_at fs/fhandle.c:112 [inline] + __se_sys_name_to_handle_at+0x949/0xb10 fs/fhandle.c:94 + __x64_sys_name_to_handle_at+0xe4/0x140 fs/fhandle.c:94 + ... + +Uninit was created at: + slab_post_alloc_hook+0x129/0xa70 mm/slab.h:768 + slab_alloc_node mm/slub.c:3478 [inline] + __kmem_cache_alloc_node+0x5c9/0x970 mm/slub.c:3517 + __do_kmalloc_node mm/slab_common.c:1006 [inline] + __kmalloc+0x121/0x3c0 mm/slab_common.c:1020 + kmalloc include/linux/slab.h:604 [inline] + do_sys_name_to_handle fs/fhandle.c:39 [inline] + __do_sys_name_to_handle_at fs/fhandle.c:112 [inline] + __se_sys_name_to_handle_at+0x441/0xb10 fs/fhandle.c:94 + __x64_sys_name_to_handle_at+0xe4/0x140 fs/fhandle.c:94 + ... + +Bytes 18-19 of 20 are uninitialized +Memory access of size 20 starts at ffff888128a46380 +Data copied to user address 0000000020000240" + +Per Chuck Lever's suggestion, use kzalloc() instead of kmalloc() to +solve the problem. + +Fixes: 990d6c2d7aee ("vfs: Add name to file handle conversion support") +Suggested-by: Chuck Lever III <chuck.lever@oracle.com> +Reported-and-tested-by: <syzbot+09b349b3066c2e0b1e96@syzkaller.appspotmail.com> +Signed-off-by: Nikita Zhandarovich <n.zhandarovich@fintech.ru> +Link: https://lore.kernel.org/r/20240119153906.4367-1-n.zhandarovich@fintech.ru +Reviewed-by: Jan Kara <jack@suse.cz> +Signed-off-by: Christian Brauner <brauner@kernel.org> +--- + fs/fhandle.c | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +diff --git a/fs/fhandle.c b/fs/fhandle.c +index 18b3ba8dc8ead7..57a12614addfd4 100644 +--- a/fs/fhandle.c ++++ b/fs/fhandle.c +@@ -36,7 +36,7 @@ static long do_sys_name_to_handle(const struct path *path, + if (f_handle.handle_bytes > MAX_HANDLE_SZ) + return -EINVAL; + +- handle = kmalloc(sizeof(struct file_handle) + f_handle.handle_bytes, ++ handle = kzalloc(sizeof(struct file_handle) + f_handle.handle_bytes, + GFP_KERNEL); + if (!handle) + return -ENOMEM; +-- +cgit 1.2.3-korg + diff --git a/meta-openbmc-mods/meta-common/recipes-kernel/linux/linux-aspeed/CVE-2024-35984.patch b/meta-openbmc-mods/meta-common/recipes-kernel/linux/linux-aspeed/CVE-2024-35984.patch new file mode 100644 index 000000000..39f07ce42 --- /dev/null +++ b/meta-openbmc-mods/meta-common/recipes-kernel/linux/linux-aspeed/CVE-2024-35984.patch @@ -0,0 +1,63 @@ +From 357c64ef1ef39b1e7cd91ab6bdd304d043702c83 Mon Sep 17 00:00:00 2001 +From: Wolfram Sang <wsa+renesas@sang-engineering.com> +Date: Fri, 26 Apr 2024 08:44:08 +0200 +Subject: [PATCH] i2c: smbus: fix NULL function pointer dereference + +[ Upstream commit 91811a31b68d3765b3065f4bb6d7d6d84a7cfc9f ] + +Baruch reported an OOPS when using the designware controller as target +only. Target-only modes break the assumption of one transfer function +always being available. Fix this by always checking the pointer in +__i2c_transfer. + +Reported-by: Baruch Siach <baruch@tkos.co.il> +Closes: https://lore.kernel.org/r/4269631780e5ba789cf1ae391eec1b959def7d99.1712761976.git.baruch@tkos.co.il +Fixes: 4b1acc43331d ("i2c: core changes for slave support") +[wsa: dropped the simplification in core-smbus to avoid theoretical regressions] +Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com> +Tested-by: Baruch Siach <baruch@tkos.co.il> +Signed-off-by: Sasha Levin <sashal@kernel.org> +--- + drivers/i2c/i2c-core-base.c | 12 ++++++------ + 1 file changed, 6 insertions(+), 6 deletions(-) + +diff --git a/drivers/i2c/i2c-core-base.c b/drivers/i2c/i2c-core-base.c +index be242605df91..43eededcb654 100644 +--- a/drivers/i2c/i2c-core-base.c ++++ b/drivers/i2c/i2c-core-base.c +@@ -2200,7 +2200,7 @@ static int i2c_check_for_quirks(struct i2c_adapter *adap, struct i2c_msg *msgs, + * Returns negative errno, else the number of messages executed. + * + * Adapter lock must be held when calling this function. No debug logging +- * takes place. adap->algo->master_xfer existence isn't checked. ++ * takes place. + */ + int __i2c_transfer(struct i2c_adapter *adap, struct i2c_msg *msgs, int num) + { +@@ -2209,6 +2209,11 @@ int __i2c_transfer(struct i2c_adapter *adap, struct i2c_msg *msgs, int num) + unsigned long timeout; + int ret, try; + ++ if (!adap->algo->master_xfer) { ++ dev_dbg(&adap->dev, "I2C level transfers not supported\n"); ++ return -EOPNOTSUPP; ++ } ++ + if (WARN_ON(!msgs || num < 1)) + return -EINVAL; + +@@ -2302,11 +2307,6 @@ int i2c_transfer(struct i2c_adapter *adap, struct i2c_msg *msgs, int num) + bool do_bus_lock = true; + int ret; + +- if (!adap->algo->master_xfer) { +- dev_dbg(&adap->dev, "I2C level transfers not supported\n"); +- return -EOPNOTSUPP; +- } +- + /* REVISIT the fault reporting model here is weak: + * + * - When we get an error after receiving N bytes from a slave, +-- +2.25.1 + diff --git a/meta-openbmc-mods/meta-common/recipes-kernel/linux/linux-aspeed/CVE-2024-36008.patch b/meta-openbmc-mods/meta-common/recipes-kernel/linux/linux-aspeed/CVE-2024-36008.patch new file mode 100644 index 000000000..240e50046 --- /dev/null +++ b/meta-openbmc-mods/meta-common/recipes-kernel/linux/linux-aspeed/CVE-2024-36008.patch @@ -0,0 +1,81 @@ +From 03b5a9b2b526862b21bcc31976e393a6e63785d1 Mon Sep 17 00:00:00 2001 +From: Eric Dumazet <edumazet@google.com> +Date: Sun, 21 Apr 2024 18:43:26 +0000 +Subject: ipv4: check for NULL idev in ip_route_use_hint() + +[ Upstream commit 58a4c9b1e5a3e53c9148e80b90e1e43897ce77d1 ] + +syzbot was able to trigger a NULL deref in fib_validate_source() +in an old tree [1]. + +It appears the bug exists in latest trees. + +All calls to __in_dev_get_rcu() must be checked for a NULL result. + +[1] +general protection fault, probably for non-canonical address 0xdffffc0000000000: 0000 [#1] SMP KASAN +KASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007] +CPU: 2 PID: 3257 Comm: syz-executor.3 Not tainted 5.10.0-syzkaller #0 +Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2~bpo12+1 04/01/2014 + RIP: 0010:fib_validate_source+0xbf/0x15a0 net/ipv4/fib_frontend.c:425 +Code: 18 f2 f2 f2 f2 42 c7 44 20 23 f3 f3 f3 f3 48 89 44 24 78 42 c6 44 20 27 f3 e8 5d 88 48 fc 4c 89 e8 48 c1 e8 03 48 89 44 24 18 <42> 80 3c 20 00 74 08 4c 89 ef e8 d2 15 98 fc 48 89 5c 24 10 41 bf +RSP: 0018:ffffc900015fee40 EFLAGS: 00010246 +RAX: 0000000000000000 RBX: ffff88800f7a4000 RCX: ffff88800f4f90c0 +RDX: 0000000000000000 RSI: 0000000004001eac RDI: ffff8880160c64c0 +RBP: ffffc900015ff060 R08: 0000000000000000 R09: ffff88800f7a4000 +R10: 0000000000000002 R11: ffff88800f4f90c0 R12: dffffc0000000000 +R13: 0000000000000000 R14: 0000000000000000 R15: ffff88800f7a4000 +FS: 00007f938acfe6c0(0000) GS:ffff888058c00000(0000) knlGS:0000000000000000 +CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 +CR2: 00007f938acddd58 CR3: 000000001248e000 CR4: 0000000000352ef0 +DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 +DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 +Call Trace: + ip_route_use_hint+0x410/0x9b0 net/ipv4/route.c:2231 + ip_rcv_finish_core+0x2c4/0x1a30 net/ipv4/ip_input.c:327 + ip_list_rcv_finish net/ipv4/ip_input.c:612 [inline] + ip_sublist_rcv+0x3ed/0xe50 net/ipv4/ip_input.c:638 + ip_list_rcv+0x422/0x470 net/ipv4/ip_input.c:673 + __netif_receive_skb_list_ptype net/core/dev.c:5572 [inline] + __netif_receive_skb_list_core+0x6b1/0x890 net/core/dev.c:5620 + __netif_receive_skb_list net/core/dev.c:5672 [inline] + netif_receive_skb_list_internal+0x9f9/0xdc0 net/core/dev.c:5764 + netif_receive_skb_list+0x55/0x3e0 net/core/dev.c:5816 + xdp_recv_frames net/bpf/test_run.c:257 [inline] + xdp_test_run_batch net/bpf/test_run.c:335 [inline] + bpf_test_run_xdp_live+0x1818/0x1d00 net/bpf/test_run.c:363 + bpf_prog_test_run_xdp+0x81f/0x1170 net/bpf/test_run.c:1376 + bpf_prog_test_run+0x349/0x3c0 kernel/bpf/syscall.c:3736 + __sys_bpf+0x45c/0x710 kernel/bpf/syscall.c:5115 + __do_sys_bpf kernel/bpf/syscall.c:5201 [inline] + __se_sys_bpf kernel/bpf/syscall.c:5199 [inline] + __x64_sys_bpf+0x7c/0x90 kernel/bpf/syscall.c:5199 + +Fixes: 02b24941619f ("ipv4: use dst hint for ipv4 list receive") +Reported-by: syzbot <syzkaller@googlegroups.com> +Signed-off-by: Eric Dumazet <edumazet@google.com> +Acked-by: Paolo Abeni <pabeni@redhat.com> +Link: https://lore.kernel.org/r/20240421184326.1704930-1-edumazet@google.com +Signed-off-by: Jakub Kicinski <kuba@kernel.org> +Signed-off-by: Sasha Levin <sashal@kernel.org> +--- + net/ipv4/route.c | 3 +++ + 1 file changed, 3 insertions(+) + +diff --git a/net/ipv4/route.c b/net/ipv4/route.c +index 4ff94596f8cd5a..895754439393e1 100644 +--- a/net/ipv4/route.c ++++ b/net/ipv4/route.c +@@ -2173,6 +2173,9 @@ int ip_route_use_hint(struct sk_buff *skb, __be32 daddr, __be32 saddr, + int err = -EINVAL; + u32 tag = 0; + ++ if (!in_dev) ++ return -EINVAL; ++ + if (ipv4_is_multicast(saddr) || ipv4_is_lbcast(saddr)) + goto martian_source; + +-- +cgit 1.2.3-korg + diff --git a/meta-openbmc-mods/meta-common/recipes-kernel/linux/linux-aspeed_%.bbappend b/meta-openbmc-mods/meta-common/recipes-kernel/linux/linux-aspeed_%.bbappend index 54ddf246e..0d15f61d7 100644 --- a/meta-openbmc-mods/meta-common/recipes-kernel/linux/linux-aspeed_%.bbappend +++ b/meta-openbmc-mods/meta-common/recipes-kernel/linux/linux-aspeed_%.bbappend @@ -18,6 +18,14 @@ SRC_URI += " \ file://0001-peci-aspeed-Improve-workaround-for-controller-hang.patch \ file://0002-gpio-gpio-aspeed-sgpio-Fix-wrong-hwirq-base-in-irq-h.patch \ file://0003-Add-mux-deselect-support-on-timeout.patch \ + file://CVE-2022-0847.patch \ + file://CVE-2022-48425.patch \ + file://CVE-2023-0386.patch \ + file://CVE-2023-0458.patch \ + file://CVE-2023-2235.patch \ + file://CVE-2023-34256.patch \ + file://CVE-2023-42754.patch \ + file://CVE-2023-5178.patch \ file://CVE-2022-0185.patch \ file://CVE-2021-22600.patch \ file://CVE-2022-24122.patch \ @@ -71,8 +79,57 @@ SRC_URI += " \ file://CVE-2023-2156.patch \ file://CVE-2023-3355.patch \ file://CVE-2023-3357.patch \ + file://CVE-2023-52458.patch \ file://CVE-2022-3566.patch \ file://CVE-2023-3161.patch \ + file://CVE-2022-40982.patch \ + file://CVE-2023-2860.patch \ + file://CVE-2023-31085.patch \ + file://CVE-2023-4004.patch \ + file://CVE-2023-2176.patch \ + file://CVE-2023-45863.patch \ + file://CVE-2021-33631.patch \ + file://CVE-2024-0562.patch \ + file://CVE-2024-0639.patch \ + file://CVE-2024-0775.patch \ + file://CVE-2023-52449.patch \ + file://CVE-2023-52435.patch \ + file://CVE-2021-46933.patch \ + file://CVE-2021-46934.patch \ + file://CVE-2021-46936.patch \ + file://CVE-2021-46923.patch \ + file://CVE-2023-52580.patch \ + file://CVE-2023-52597.patch \ + file://CVE-2023-52598.patch \ + file://CVE-2023-52612.patch \ + file://CVE-2023-52615.patch \ + file://CVE-2023-52619.patch \ + file://CVE-2024-26631.patch \ + file://CVE-2024-26671.patch \ + file://CVE-2024-26679.patch \ + file://CVE-2024-26772.patch \ + file://CVE-2024-26773.patch \ + file://CVE-2024-26774.patch \ + file://CVE-2024-26704.patch \ + file://CVE-2024-26720.patch \ + file://CVE-2024-26735.patch \ + file://CVE-2024-26795.patch \ + file://CVE-2021-47087.patch \ + file://CVE-2023-52467.patch \ + file://CVE-2023-52522.patch \ + file://CVE-2023-52622.patch \ + file://CVE-2024-26676.patch \ + file://CVE-2024-26602.patch \ + file://CVE-2024-26001.patch \ + file://CVE-2024-26686.patch \ + file://CVE-2022-48659.patch \ + file://CVE-2022-48660.patch \ + file://CVE-2022-48672.patch \ + file://CVE-2022-48687.patch \ + file://CVE-2022-48689.patch \ + file://CVE-2024-26900.patch \ + file://CVE-2024-35984.patch \ + file://CVE-2024-36008.patch \ " SRC_URI += "${@bb.utils.contains('IMAGE_FSTYPES', 'intel-pfr', 'file://1000-128MB-flashmap-for-PFR.patch', '', d)}" SRC_URI += "${@bb.utils.contains('EXTRA_IMAGE_FEATURES', 'debug-tweaks', 'file://debug.cfg', '', d)}" |