Re: WARNING: CPU: 26 PID: 64391 at lib/vsprintf.c:2193 set_precision+0x84/0x90

[Andy Shevchenko]

On Tue, Nov 13, 2018 at 06:20:20PM +0100, Geert Uytterhoeven wrote:
> On Tue, Nov 13, 2018 at 5:57 PM Qian Cai <cai@xxxxxx> 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