On Tue, Nov 13, 2018 at 06:20:20PM +0100, Geert Uytterhoeven wrote:
> On Tue, Nov 13, 2018 at 5:57 PM Qian Cai <c...@gmx.us> wrote:
> > Running the trinity fuzzer with a non-root user on an aarch64 server with
> > the
> > latest mainline (rc2) generated this. Is it just a false alarm to ignore?
> >
> > [ 807.847370] precision 65525 too large
> > [ 807.847449] WARNING: CPU: 26 PID: 64391 at lib/vsprintf.c:2193
> > set_precision+0x84/0x90
> > [ 807.860161] Modules linked in: cast6_generic cast_common lrw bridge 8021q
> > garp mrp stp llc dlci tcp_diag inet_diag af_key pptp gre l2tp_ppp
> > l2tp_netlink
> > l2tp_core ip6_udp_tunnel udp_tunnel pppoe pppox ppp_generic slhc crypto_user
> > ib_core nfnetlink scsi_transport_iscsi atm sctp vfat fat ghash_ce sha2_ce
> > sha256_arm64 sha1_ce ses enclosure ipmi_ssif sg ipmi_si ipmi_devintf
> > sbsa_gwdt
> > ipmi_msghandler sch_fq_codel xfs libcrc32c marvell mpt3sas mlx5_core
> > raid_class
> > hibmc_drm drm_kms_helper syscopyarea sysfillrect sysimgblt fb_sys_fops ttm
> > drm
> > ixgbe hisi_sas_v2_hw igb hisi_sas_main libsas hns_dsaf mlxfw devlink
> > hns_enet_drv mdio i2c_designware_platform i2c_algo_bit i2c_designware_core
> > ehci_platform scsi_transport_sas hns_mdio hnae dm_mirror dm_region_hash
> > dm_log
> > dm_mod
> > [ 807.927838] CPU: 26 PID: 64391 Comm: trinity-c90 Kdump: loaded Tainted:
> > G W 4.20.0-rc2+ #16
> > [ 807.937494] Hardware name: Huawei TaiShan 2280 /BC11SPCD, BIOS 1.50
> > 06/01/2018
> > [ 807.944718] pstate: 60000005 (nZCv daif -PAN -UAO)
> > [ 807.949515] pc : set_precision+0x84/0x90
> > [ 807.953439] lr : set_precision+0x84/0x90
> > [ 807.957362] sp : ffff801e6430f6b0
> > [ 807.960677] x29: ffff801e6430f6b0 x28: ffff801e6430fb10
> > [ 807.965992] x27: 0000000000000003 x26: 00000000ffffffd8
> > [ 807.971307] x25: ffff801e6430fba0 x24: ffff801e6430fb48
> > [ 807.976622] x23: ffff2000093ddfa0 x22: ffff801e6430f770
> > [ 807.981937] x21: ffff2000090eb4a6 x20: ffff801e6430f770
> > [ 807.987252] x19: 000000000000fff5 x18: 0000000000000000
> > [ 807.992569] x17: 0000000000000000 x16: 0000000000000000
> > [ 807.997884] x15: 0000000000000000 x14: 3878302031343220
> > [ 808.003201] x13: 6265783020303939 x12: ffff04000172b49c
> > [ 808.008516] x11: 1fffe4000172b49b x10: ffff04000172b49b
> > [ 808.013832] x9 : 0000000000000000 x8 : 203532353536206e
> > [ 808.019148] x7 : 6f69736963657270 x6 : 0000000041b58ab3
> > [ 808.024463] x5 : dfff200000000000 x4 : dfff200000000000
> > [ 808.029779] x3 : dfff200000000000 x2 : 65a2459128144800
> > [ 808.035093] x1 : 65a2459128144800 x0 : 0000000000000000
> > [ 808.040408] Call trace:
> > [ 808.042861] set_precision+0x84/0x90
> > [ 808.046440] vsnprintf+0x23c/0x858
> > [ 808.049845] __request_module+0x1a0/0x8b8
> > [ 808.053860] get_fs_type+0xb0/0x138
> > [ 808.057351] do_mount+0x2c4/0x13c0
> > [ 808.060756] ksys_mount+0xf4/0x110
>
> Looks like someone is calling the mount syscall with a very long
> filesystemtype
> parameter.
>
> struct file_system_type *get_fs_type(const char *name)
> {
> struct file_system_type *fs;
> const char *dot = strchr(name, '.');
> int len = dot ? dot - name : strlen(name);
>
> fs = __get_fs_type(name, len);
> if (!fs && (request_module("fs-%.*s", len, name) == 0)) {
>
> set_precision() complains about any prevision that doesn't fit in signed
> 16-bits.
Or maybe \0 is missed and it found first one at that position.
--
With Best Regards,
Andy Shevchenko
