Re: CFI violation in drivers/infiniband/core/sysfs.c
On Fri, Apr 02, 2021 at 06:29:55PM -0700, Kees Cook wrote:
> On Fri, Apr 02, 2021 at 08:30:18PM -0300, Jason Gunthorpe wrote:
> > On Fri, Apr 02, 2021 at 04:03:30PM -0700, Kees Cook wrote:
> >
> > > > relevant. It seems to me that the hw_counters 'struct attribute_group'
> > > > should probably be its own kobj within both of these structures so they
> > > > can have their own sysfs ops (unless there is some other way to do this
> > > > that I am missing).
> >
> > Err, yes, every subclass of the attribute should be accompanied by a
> > distinct kobject type to relay the show methods with typesafety, this
> > is how this design pattern is intended to be used.
> >
> > If I understand your report properly the hw_stats_attribute is being
> > assigned to a 'port_type' kobject and it only works by pure luck because
> > the show/store happens to overlap between port and hsa attributes?
>
> "happens to" :) Yeah, they're all like this, unfortunately:
> https://lore.kernel.org/lkml/202006112217.2E6CE093@keescook/
All? I think these are all bugs, no?
struct kobj_attribute is only to be used with a kobj_sysfs_ops type
kobject
To cross it over to a 'struct device' kobj is completely wrong, the
same basic wrongness being done here.
> I'm not convinced that just backing everything off to kobject isn't
> simpler?
It might be simpler, but isn't right - everything should continue to
work after a patch like this:
--- a/drivers/infiniband/core/sysfs.c
+++ b/drivers/infiniband/core/sysfs.c
@@ -67,6 +67,7 @@ struct ib_port {
struct port_attribute {
struct attribute attr;
+ uu64 pad[2];
ssize_t (*show)(struct ib_port *, struct port_attribute *, char *buf);
ssize_t (*store)(struct ib_port *, struct port_attribute *,
const char *buf, size_t count);
If it doesn't it is still broken.
Using container_of() with the wrong types is an unconditional
error. A kasn test to catch this would be very cool (think like RTTI
and dynamic_cast<>() in C++)
> > And then two show/set functions that bounce through the correct types
> > to the data.
>
> I'd like to make these things compile-time safe (there is not type
> associated with use the __ATTR() macro, for example). That I haven't
> really figured out how to do right.
They are in many places, for instance.
int device_create_file(struct device *dev,
const struct device_attribute *attr)
We loose the type safety when working with attribute arrays, and
people can just bypass the "proper" APIs to raw sysfs ones whenever
they like.
It is fundamentally completely wrong to attach a 'struct
kobject_attribute' to a 'struct device' kobject.
Which is what is happening here and the link above.
Jason
Re: CFI violation in drivers/infiniband/core/sysfs.c
On Fri, Apr 02, 2021 at 04:03:30PM -0700, Kees Cook wrote: > On Fri, Apr 02, 2021 at 12:52:41PM -0700, Nathan Chancellor wrote: > > Hi all, > > > > I am testing the Clang Control Flow Integrity series that is being > > worked on right now [1] and I encounter a violation in the Infiniband > > sysfs core (drivers/infiniband/core/sysfs.c) on an arm64 server with mlx5: > > > > $ cat /sys/class/infiniband/mlx5_bond_0/ports/1/hw_counters/lifespan > > 12 > > > > $ echo "10" | sudo tee > > /sys/class/infiniband/mlx5_bond_0/ports/1/hw_counters/lifespan > > 10 > > > > $ sudo dmesg > > [64198.670342] [ cut here ] > > [64198.670362] CFI failure (target: show_stats_lifespan+0x0/0x8 [ib_core]): > > [64198.671291] WARNING: CPU: 20 PID: 15786 at kernel/cfi.c:29 > > __ubsan_handle_cfi_check_fail+0x58/0x60 > > [64198.671336] Modules linked in: binfmt_misc nls_iso8859_1 dm_multipath > > scsi_dh_rdac scsi_dh_emc scsi_dh_alua ast drm_vram_helper drm_ttm_helper > > ttm aes_ce_blk crypto_simd drm_kms_helper cryptd cec rc_core > > aes_ce_cipher crct10dif_ce sysimgblt ghash_ce syscopyarea sysfillrect > > acpi_ipmi sha2_ce fb_sys_fops ipmi_ssif sha256_arm64 ipmi_devintf > > sha1_ce drm efi_pstore sbsa_gwdt tcp_westwood evbug ipmi_msghandler > > cppc_cpufreq xgene_hwmon ib_iser rdma_cm iw_cm ib_cm iscsi_tcp > > libiscsi_tcp libiscsi scsi_transport_iscsi bonding ip_tables x_tables > > autofs4 raid10 raid456 libcrc32c async_raid6_recov async_pq raid6_pq > > async_xor xor xor_neon async_memcpy async_tx raid1 raid0 multipath > > linear mlx5_ib ib_uverbs ib_core mlx5_core mlxfw igb i2c_algo_bit tls > > i2c_xgene_slimpro ahci_platform gpio_dwapb > > [64198.671958] CPU: 20 PID: 15786 Comm: cat Tainted: GW > > 5.12.0-rc5+ #5 > > [64198.671980] Hardware name: Lenovo HR330A7X33CTO1WW > > /HR350A , BIOS HVE104D-1.02 03/08/2019 > > [64198.671993] pstate: 6045 (nZCv daif +PAN -UAO -TCO BTYPE=--) > > [64198.672016] pc : __ubsan_handle_cfi_check_fail+0x58/0x60 > > [64198.672036] lr : __ubsan_handle_cfi_check_fail+0x58/0x60 > > [64198.672054] sp : 800014ea3b50 > > [64198.672065] x29: 800014ea3b50 x28: 80001122da60 > > [64198.672095] x27: 80001122ad80 x26: 800011233088 > > [64198.672122] x25: 000801821a78 x24: 000820cda200 > > [64198.672148] x23: 89aa9f60 x22: 89a66000 > > [64198.672173] x21: 7dac81f92e1d85cf x20: 89abddd0 > > [64198.672198] x19: 89a69fd8 x18: > > [64198.672223] x17: x16: > > [64198.672250] x15: 0004 x14: 1fff > > [64198.672277] x13: 8000121412a8 x12: 0003 > > [64198.672303] x11: x10: 0027 > > [64198.672329] x9 : 4568e3af67e9f000 x8 : 4568e3af67e9f000 > > [64198.672356] x7 : 6e6170736566696c x6 : 8000124699c9 > > [64198.672381] x5 : x4 : 0001 > > [64198.672406] x3 : x2 : > > [64198.672431] x1 : 8000119b905d x0 : 003c > > [64198.672457] Call trace: > > [64198.672469] __ubsan_handle_cfi_check_fail+0x58/0x60 > > [64198.672489] __cfi_check_fail+0x3c/0x44 [ib_core] > > [64198.673362] __cfi_check+0x2e78/0x31b0 [ib_core] > > [64198.674230] port_attr_show+0x88/0x98 [ib_core] > > [64198.675098] sysfs_kf_seq_show+0xc4/0x160 > > [64198.675131] kernfs_seq_show+0x5c/0xa4 > > [64198.675157] seq_read_iter+0x178/0x60c > > [64198.675176] kernfs_fop_read_iter+0x78/0x1fc > > [64198.675202] vfs_read+0x2d0/0x34c > > [64198.675220] ksys_read+0x80/0xec > > [64198.675237] __arm64_sys_read+0x28/0x34 > > [64198.675253] el0_svc_common.llvm.13467398108545334879+0xbc/0x1f0 > > [64198.675277] do_el0_svc+0x30/0xa4 > > [64198.675293] el0_svc+0x30/0xb0 > > [64198.675314] el0_sync_handler+0x84/0xe4 > > [64198.675333] el0_sync+0x174/0x180 > > [64198.675351] ---[ end trace a253e31759778f5c ]--- > > [64216.024673] [ cut here ] > > [64216.024678] CFI failure (target: set_stats_lifespan+0x0/0x8 [ib_core]): > > [64216.024824] WARNING: CPU: 3 PID: 15816 at kernel/cfi.c:29 > > __ubsan_handle_cfi_check_fail+0x58/0x60 > > [64216.024832] Modules linked in: binfmt_misc nls_iso8859_1 dm_multipath > > scsi_dh_rdac scsi_dh_emc scsi_dh_alua ast drm_vram_helper drm_ttm_helper > > ttm aes_ce_blk crypto_simd drm_kms_helper cryptd cec rc_core > > aes_ce_cipher crct10dif_ce sysimgblt ghash_ce syscopyarea sysfillrect > > acpi_ipmi sha2_ce fb_sys_fops ipmi_ssif sha256_arm64 ipmi_devintf > > sha1_ce drm efi_pstore sbsa_gwdt tcp_westwood evbug ipmi_msghandler > > cppc_cpufreq xgene_hwmon ib_iser rdma_cm iw_cm ib_cm iscsi_tcp > > libiscsi_tcp libiscsi scsi_transport_iscsi bonding ip_tables x_tables > > autofs4 raid10 raid456 libcrc32c async_raid6_recov async_pq raid6_pq > > async_xor xor xor_neon async_memcpy async_tx raid1 raid0 multipath > > linear mlx5_ib ib_uverbs ib_core mlx5_core mlxfw igb i2c_algo_bit
Re: CFI violation in drivers/infiniband/core/sysfs.c
On Fri, Apr 02, 2021 at 08:30:18PM -0300, Jason Gunthorpe wrote: > On Fri, Apr 02, 2021 at 04:03:30PM -0700, Kees Cook wrote: > > > > relevant. It seems to me that the hw_counters 'struct attribute_group' > > > should probably be its own kobj within both of these structures so they > > > can have their own sysfs ops (unless there is some other way to do this > > > that I am missing). > > Err, yes, every subclass of the attribute should be accompanied by a > distinct kobject type to relay the show methods with typesafety, this > is how this design pattern is intended to be used. > > If I understand your report properly the hw_stats_attribute is being > assigned to a 'port_type' kobject and it only works by pure luck because > the show/store happens to overlap between port and hsa attributes? "happens to" :) Yeah, they're all like this, unfortunately: https://lore.kernel.org/lkml/202006112217.2E6CE093@keescook/ This is the first that I've seen that crossed kobj_types in the same group, though. :) > > > I would appreciate someone else taking a look and seeing if I am off > > > base or if there is an easier way to solve this. > > > > So, it seems that the reason for a custom kobj_type here is to use the > > .release callback. > > Every kobject should be associated with a specific, fixed, attribute > type. The purpose of the wrappers is to inject type safety so the > attribute implementations know they are working on the right stuff. Right -- though it's not specifically required to be a fixed attribute. It can just be a "generic" kobject. This seems to happen a lot when something wants to show up a global or const value in /sys > The answer is that the setup_hw_stats_() for port and device must > be split up and the attribute implementations for each of them have to > subclass starting from the correct type. I'm not convinced that just backing everything off to kobject isn't simpler? > And then two show/set functions that bounce through the correct types > to the data. I'd like to make these things compile-time safe (there is not type associated with use the __ATTR() macro, for example). That I haven't really figured out how to do right. -- Kees Cook
Re: CFI violation in drivers/infiniband/core/sysfs.c
On Fri, Apr 02, 2021 at 04:03:30PM -0700, Kees Cook wrote:
> > relevant. It seems to me that the hw_counters 'struct attribute_group'
> > should probably be its own kobj within both of these structures so they
> > can have their own sysfs ops (unless there is some other way to do this
> > that I am missing).
Err, yes, every subclass of the attribute should be accompanied by a
distinct kobject type to relay the show methods with typesafety, this
is how this design pattern is intended to be used.
If I understand your report properly the hw_stats_attribute is being
assigned to a 'port_type' kobject and it only works by pure luck because
the show/store happens to overlap between port and hsa attributes?
> > I would appreciate someone else taking a look and seeing if I am off
> > base or if there is an easier way to solve this.
>
> So, it seems that the reason for a custom kobj_type here is to use the
> .release callback.
Every kobject should be associated with a specific, fixed, attribute
type. The purpose of the wrappers is to inject type safety so the
attribute implementations know they are working on the right stuff.
In turn, an attribute of a specific attribute type can only be
injected into a kobject that has the matching type.
This code is insane because it does this:
hsag->attrs[i] = alloc_hsa(i, port_num, stats->names[i]);
// This is port kobject
struct kobject *kobj = >kobj;
ret = sysfs_create_group(kobj, hsag);
[..]
// This is a struct device kobject
struct kobject *kobj = >dev.kobj;
ret = sysfs_create_group(kobj, hsag);
Which is absolutely not allowed, you can't have a generic attribute
handler and stuff it into two different types! Things MUST use the
proper attribute subclass for what they are being attached to.
The answer is that the setup_hw_stats_() for port and device must
be split up and the attribute implementations for each of them have to
subclass starting from the correct type.
So we'd end up with two attributes for hw_stats
struct port_hw_stats {
struct port_attr attr;
struct hw_stats_data data;
};
struct device_hw_stats {
struct device_attr attr;
struct hw_stats_data data;
};
And then two show/set functions that bounce through the correct types
to the data.
And so on.
Jason
Re: CFI violation in drivers/infiniband/core/sysfs.c
On Fri, Apr 02, 2021 at 12:52:41PM -0700, Nathan Chancellor wrote: > Hi all, > > I am testing the Clang Control Flow Integrity series that is being > worked on right now [1] and I encounter a violation in the Infiniband > sysfs core (drivers/infiniband/core/sysfs.c) on an arm64 server with mlx5: > > $ cat /sys/class/infiniband/mlx5_bond_0/ports/1/hw_counters/lifespan > 12 > > $ echo "10" | sudo tee > /sys/class/infiniband/mlx5_bond_0/ports/1/hw_counters/lifespan > 10 > > $ sudo dmesg > [64198.670342] [ cut here ] > [64198.670362] CFI failure (target: show_stats_lifespan+0x0/0x8 [ib_core]): > [64198.671291] WARNING: CPU: 20 PID: 15786 at kernel/cfi.c:29 > __ubsan_handle_cfi_check_fail+0x58/0x60 > [64198.671336] Modules linked in: binfmt_misc nls_iso8859_1 dm_multipath > scsi_dh_rdac scsi_dh_emc scsi_dh_alua ast drm_vram_helper drm_ttm_helper > ttm aes_ce_blk crypto_simd drm_kms_helper cryptd cec rc_core > aes_ce_cipher crct10dif_ce sysimgblt ghash_ce syscopyarea sysfillrect > acpi_ipmi sha2_ce fb_sys_fops ipmi_ssif sha256_arm64 ipmi_devintf > sha1_ce drm efi_pstore sbsa_gwdt tcp_westwood evbug ipmi_msghandler > cppc_cpufreq xgene_hwmon ib_iser rdma_cm iw_cm ib_cm iscsi_tcp > libiscsi_tcp libiscsi scsi_transport_iscsi bonding ip_tables x_tables > autofs4 raid10 raid456 libcrc32c async_raid6_recov async_pq raid6_pq > async_xor xor xor_neon async_memcpy async_tx raid1 raid0 multipath > linear mlx5_ib ib_uverbs ib_core mlx5_core mlxfw igb i2c_algo_bit tls > i2c_xgene_slimpro ahci_platform gpio_dwapb > [64198.671958] CPU: 20 PID: 15786 Comm: cat Tainted: GW > 5.12.0-rc5+ #5 > [64198.671980] Hardware name: Lenovo HR330A7X33CTO1WW/HR350A >, BIOS HVE104D-1.02 03/08/2019 > [64198.671993] pstate: 6045 (nZCv daif +PAN -UAO -TCO BTYPE=--) > [64198.672016] pc : __ubsan_handle_cfi_check_fail+0x58/0x60 > [64198.672036] lr : __ubsan_handle_cfi_check_fail+0x58/0x60 > [64198.672054] sp : 800014ea3b50 > [64198.672065] x29: 800014ea3b50 x28: 80001122da60 > [64198.672095] x27: 80001122ad80 x26: 800011233088 > [64198.672122] x25: 000801821a78 x24: 000820cda200 > [64198.672148] x23: 89aa9f60 x22: 89a66000 > [64198.672173] x21: 7dac81f92e1d85cf x20: 89abddd0 > [64198.672198] x19: 89a69fd8 x18: > [64198.672223] x17: x16: > [64198.672250] x15: 0004 x14: 1fff > [64198.672277] x13: 8000121412a8 x12: 0003 > [64198.672303] x11: x10: 0027 > [64198.672329] x9 : 4568e3af67e9f000 x8 : 4568e3af67e9f000 > [64198.672356] x7 : 6e6170736566696c x6 : 8000124699c9 > [64198.672381] x5 : x4 : 0001 > [64198.672406] x3 : x2 : > [64198.672431] x1 : 8000119b905d x0 : 003c > [64198.672457] Call trace: > [64198.672469] __ubsan_handle_cfi_check_fail+0x58/0x60 > [64198.672489] __cfi_check_fail+0x3c/0x44 [ib_core] > [64198.673362] __cfi_check+0x2e78/0x31b0 [ib_core] > [64198.674230] port_attr_show+0x88/0x98 [ib_core] > [64198.675098] sysfs_kf_seq_show+0xc4/0x160 > [64198.675131] kernfs_seq_show+0x5c/0xa4 > [64198.675157] seq_read_iter+0x178/0x60c > [64198.675176] kernfs_fop_read_iter+0x78/0x1fc > [64198.675202] vfs_read+0x2d0/0x34c > [64198.675220] ksys_read+0x80/0xec > [64198.675237] __arm64_sys_read+0x28/0x34 > [64198.675253] el0_svc_common.llvm.13467398108545334879+0xbc/0x1f0 > [64198.675277] do_el0_svc+0x30/0xa4 > [64198.675293] el0_svc+0x30/0xb0 > [64198.675314] el0_sync_handler+0x84/0xe4 > [64198.675333] el0_sync+0x174/0x180 > [64198.675351] ---[ end trace a253e31759778f5c ]--- > [64216.024673] [ cut here ] > [64216.024678] CFI failure (target: set_stats_lifespan+0x0/0x8 [ib_core]): > [64216.024824] WARNING: CPU: 3 PID: 15816 at kernel/cfi.c:29 > __ubsan_handle_cfi_check_fail+0x58/0x60 > [64216.024832] Modules linked in: binfmt_misc nls_iso8859_1 dm_multipath > scsi_dh_rdac scsi_dh_emc scsi_dh_alua ast drm_vram_helper drm_ttm_helper > ttm aes_ce_blk crypto_simd drm_kms_helper cryptd cec rc_core > aes_ce_cipher crct10dif_ce sysimgblt ghash_ce syscopyarea sysfillrect > acpi_ipmi sha2_ce fb_sys_fops ipmi_ssif sha256_arm64 ipmi_devintf > sha1_ce drm efi_pstore sbsa_gwdt tcp_westwood evbug ipmi_msghandler > cppc_cpufreq xgene_hwmon ib_iser rdma_cm iw_cm ib_cm iscsi_tcp > libiscsi_tcp libiscsi scsi_transport_iscsi bonding ip_tables x_tables > autofs4 raid10 raid456 libcrc32c async_raid6_recov async_pq raid6_pq > async_xor xor xor_neon async_memcpy async_tx raid1 raid0 multipath > linear mlx5_ib ib_uverbs ib_core mlx5_core mlxfw igb i2c_algo_bit tls > i2c_xgene_slimpro ahci_platform gpio_dwapb > [64216.024922] CPU: 3 PID: 15816 Comm: tee Tainted: GW > 5.12.0-rc5+ #5 > [64216.024925] Hardware name: Lenovo HR330A7X33CTO1WW/HR350A >, BIOS
CFI violation in drivers/infiniband/core/sysfs.c
Hi all, I am testing the Clang Control Flow Integrity series that is being worked on right now [1] and I encounter a violation in the Infiniband sysfs core (drivers/infiniband/core/sysfs.c) on an arm64 server with mlx5: $ cat /sys/class/infiniband/mlx5_bond_0/ports/1/hw_counters/lifespan 12 $ echo "10" | sudo tee /sys/class/infiniband/mlx5_bond_0/ports/1/hw_counters/lifespan 10 $ sudo dmesg [64198.670342] [ cut here ] [64198.670362] CFI failure (target: show_stats_lifespan+0x0/0x8 [ib_core]): [64198.671291] WARNING: CPU: 20 PID: 15786 at kernel/cfi.c:29 __ubsan_handle_cfi_check_fail+0x58/0x60 [64198.671336] Modules linked in: binfmt_misc nls_iso8859_1 dm_multipath scsi_dh_rdac scsi_dh_emc scsi_dh_alua ast drm_vram_helper drm_ttm_helper ttm aes_ce_blk crypto_simd drm_kms_helper cryptd cec rc_core aes_ce_cipher crct10dif_ce sysimgblt ghash_ce syscopyarea sysfillrect acpi_ipmi sha2_ce fb_sys_fops ipmi_ssif sha256_arm64 ipmi_devintf sha1_ce drm efi_pstore sbsa_gwdt tcp_westwood evbug ipmi_msghandler cppc_cpufreq xgene_hwmon ib_iser rdma_cm iw_cm ib_cm iscsi_tcp libiscsi_tcp libiscsi scsi_transport_iscsi bonding ip_tables x_tables autofs4 raid10 raid456 libcrc32c async_raid6_recov async_pq raid6_pq async_xor xor xor_neon async_memcpy async_tx raid1 raid0 multipath linear mlx5_ib ib_uverbs ib_core mlx5_core mlxfw igb i2c_algo_bit tls i2c_xgene_slimpro ahci_platform gpio_dwapb [64198.671958] CPU: 20 PID: 15786 Comm: cat Tainted: GW 5.12.0-rc5+ #5 [64198.671980] Hardware name: Lenovo HR330A7X33CTO1WW/HR350A , BIOS HVE104D-1.02 03/08/2019 [64198.671993] pstate: 6045 (nZCv daif +PAN -UAO -TCO BTYPE=--) [64198.672016] pc : __ubsan_handle_cfi_check_fail+0x58/0x60 [64198.672036] lr : __ubsan_handle_cfi_check_fail+0x58/0x60 [64198.672054] sp : 800014ea3b50 [64198.672065] x29: 800014ea3b50 x28: 80001122da60 [64198.672095] x27: 80001122ad80 x26: 800011233088 [64198.672122] x25: 000801821a78 x24: 000820cda200 [64198.672148] x23: 89aa9f60 x22: 89a66000 [64198.672173] x21: 7dac81f92e1d85cf x20: 89abddd0 [64198.672198] x19: 89a69fd8 x18: [64198.672223] x17: x16: [64198.672250] x15: 0004 x14: 1fff [64198.672277] x13: 8000121412a8 x12: 0003 [64198.672303] x11: x10: 0027 [64198.672329] x9 : 4568e3af67e9f000 x8 : 4568e3af67e9f000 [64198.672356] x7 : 6e6170736566696c x6 : 8000124699c9 [64198.672381] x5 : x4 : 0001 [64198.672406] x3 : x2 : [64198.672431] x1 : 8000119b905d x0 : 003c [64198.672457] Call trace: [64198.672469] __ubsan_handle_cfi_check_fail+0x58/0x60 [64198.672489] __cfi_check_fail+0x3c/0x44 [ib_core] [64198.673362] __cfi_check+0x2e78/0x31b0 [ib_core] [64198.674230] port_attr_show+0x88/0x98 [ib_core] [64198.675098] sysfs_kf_seq_show+0xc4/0x160 [64198.675131] kernfs_seq_show+0x5c/0xa4 [64198.675157] seq_read_iter+0x178/0x60c [64198.675176] kernfs_fop_read_iter+0x78/0x1fc [64198.675202] vfs_read+0x2d0/0x34c [64198.675220] ksys_read+0x80/0xec [64198.675237] __arm64_sys_read+0x28/0x34 [64198.675253] el0_svc_common.llvm.13467398108545334879+0xbc/0x1f0 [64198.675277] do_el0_svc+0x30/0xa4 [64198.675293] el0_svc+0x30/0xb0 [64198.675314] el0_sync_handler+0x84/0xe4 [64198.675333] el0_sync+0x174/0x180 [64198.675351] ---[ end trace a253e31759778f5c ]--- [64216.024673] [ cut here ] [64216.024678] CFI failure (target: set_stats_lifespan+0x0/0x8 [ib_core]): [64216.024824] WARNING: CPU: 3 PID: 15816 at kernel/cfi.c:29 __ubsan_handle_cfi_check_fail+0x58/0x60 [64216.024832] Modules linked in: binfmt_misc nls_iso8859_1 dm_multipath scsi_dh_rdac scsi_dh_emc scsi_dh_alua ast drm_vram_helper drm_ttm_helper ttm aes_ce_blk crypto_simd drm_kms_helper cryptd cec rc_core aes_ce_cipher crct10dif_ce sysimgblt ghash_ce syscopyarea sysfillrect acpi_ipmi sha2_ce fb_sys_fops ipmi_ssif sha256_arm64 ipmi_devintf sha1_ce drm efi_pstore sbsa_gwdt tcp_westwood evbug ipmi_msghandler cppc_cpufreq xgene_hwmon ib_iser rdma_cm iw_cm ib_cm iscsi_tcp libiscsi_tcp libiscsi scsi_transport_iscsi bonding ip_tables x_tables autofs4 raid10 raid456 libcrc32c async_raid6_recov async_pq raid6_pq async_xor xor xor_neon async_memcpy async_tx raid1 raid0 multipath linear mlx5_ib ib_uverbs ib_core mlx5_core mlxfw igb i2c_algo_bit tls i2c_xgene_slimpro ahci_platform gpio_dwapb [64216.024922] CPU: 3 PID: 15816 Comm: tee Tainted: GW 5.12.0-rc5+ #5 [64216.024925] Hardware name: Lenovo HR330A7X33CTO1WW/HR350A , BIOS HVE104D-1.02 03/08/2019 [64216.024927] pstate: 6045 (nZCv daif +PAN -UAO -TCO BTYPE=--) [64216.024931] pc : __ubsan_handle_cfi_check_fail+0x58/0x60 [64216.024933] lr : __ubsan_handle_cfi_check_fail+0x58/0x60 [64216.024936] sp : 800015433bf0
