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
[ 808.064160] __arm64_sys_mount+0x70/0x88
[ 808.068087] el0_svc_handler+0xd4/0x198
[ 808.071928] el0_svc+0x8/0xc
[ 808.074810] irq event stamp: 347872
[ 808.078305] hardirqs last enabled at (347871): [<ffff2000082080e8>]
vprintk_emit+0x2b0/0x5c0
[ 808.086833] hardirqs last disabled at (347872): [<ffff200008081490>]
do_debug_exception+0xd8/0x190
[ 808.095795] softirqs last enabled at (347844): [<ffff200008082210>]
__do_softirq+0x7c8/0x9c8
[ 808.104325] softirqs last disabled at (347837): [<ffff20000812dbe4>]
irq_exit+0x25c/0x2f0
[ 808.112502] ---[ end trace 598902d30712b79e ]---
On Tue, Nov 13, 2018 at 5:57 PM Qian Cai <[email protected]> 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.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- [email protected]
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
On Tue, Nov 13, 2018 at 11:55:32AM -0500, Qian Cai wrote:
+Cc Rasmus
> 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
It seems like someone uses -EAGAIN as a parameter to printf().
Or rather this line
if (!fs && (request_module("fs-%.*s", len, name) == 0)) {
...
}
Care to print the len and name parameters before this line?
> [??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
> [??808.064160]??__arm64_sys_mount+0x70/0x88
> [??808.068087]??el0_svc_handler+0xd4/0x198
> [??808.071928]??el0_svc+0x8/0xc
> [??808.074810] irq event stamp: 347872
> [??808.078305] hardirqs last??enabled at (347871): [<ffff2000082080e8>]
> vprintk_emit+0x2b0/0x5c0
> [??808.086833] hardirqs last disabled at (347872): [<ffff200008081490>]
> do_debug_exception+0xd8/0x190
> [??808.095795] softirqs last??enabled at (347844): [<ffff200008082210>]
> __do_softirq+0x7c8/0x9c8
> [??808.104325] softirqs last disabled at (347837): [<ffff20000812dbe4>]
> irq_exit+0x25c/0x2f0
> [??808.112502] ---[ end trace 598902d30712b79e ]---
--
With Best Regards,
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 <[email protected]> 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
On Tue, 2018-11-13 at 19:29 +0200, Andy Shevchenko wrote:
> On Tue, Nov 13, 2018 at 11:55:32AM -0500, Qian Cai wrote:
>
> +Cc Rasmus
>
> > 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
>
> It seems like someone uses -EAGAIN as a parameter to printf().
>
> Or rather this line
>
> if (!fs && (request_module("fs-%.*s", len, name) == 0)) {
> ...
> }
>
> Care to print the len and name parameters before this line?
len = 60612; name =
%d%d%d%d%d%d%s%s%s%d%s%d%d%d%s%s%s%s%s%d%s%d%s%s%s%d%s%d%d%s%s%d%s%s%d%d%s%s%s%s
%s%d%s%d%d%s%s%s%d%d%d%d%d%s%s%s%s%d%s%s%s%s%d%d%d%d%d%d%d%s%s%s%s%d%s%d%s%d%s%d
%s%s%d%s%d%s%s%s%s%d%s%d%s%s%d%d%s%s%d%s%d%s%s%d%s%d%d%s%s%s%s%d%s%s%s%s%d%d%s%s
%s%d%s%d%s%s%d%d%d%d%d%s%s%s%s%s%s%s%d%d%d%s%d%s%d%d%s%d%d%d%s%s%d%d%d%s%s%d%s%d
%s%s%s%d%d%d%s%d%s%s%d%s%d%s%s%d%s%d%d%s%d%s%s%d%s%s%s%s%s%d%s%d%d%d%s%d%d%d%d%s
%d%s%d%d%d%s%s%s%s%s%d%s%s%s%s%d%d%d%s%d%s%d%d%s%d%s%s%d%d%d%s%d%s%d%d%s%s%s%d%s
%s%d%d%d%d%d%d%d%d%d%d%s%d%s%d%s%d%d%s%d%d%s%d%s%s%s%d%d%d%d%s%s%d%d%s%d%d%d%s%d
%d%s%d%d%d%d%s%s%d%s%s%d%d%d%s%s%s%s%s%s%s%s%s%d%s%d%d%s%d%s%s%d%s%s%s%s%d%d%d%d
%s%d%s%s%d%d%d%s%d%d%d%s%s%s%s%d%d%d%s%d%s%d%s%d%d%d%d%d%d%d%d%d%d%s%s%d%d%d%s%d
%d%d%s%s%s%s%s%s%s%d%d%d%d%s%s%d%s%s%d%s%s%s%s%d%d%s%d%d%s%d%d%s%d%d%d%s%s%s%s%d
%s%s%d%s%d%s%d%s%d%d%d%d%s%d%d%d%s%d%d%d%d%s%s%d%s%s%d%d%d%s%d%s%d%d%d%d%d%d%s%d
%s%s%d%d%s%d%d%d%s%s%d%s%d%s%d%s%d%d%s%d%s%s%s%s%s%d%s%s%d%d%d%s%s%d%d%s%s%d%s%d
%s%d%s%s%s%
[ 833.044728] ------------[ cut here ]------------
[ 833.137184] precision 60612 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
> > [ 808.064160] __arm64_sys_mount+0x70/0x88
> > [ 808.068087] el0_svc_handler+0xd4/0x198
> > [ 808.071928] el0_svc+0x8/0xc
> > [ 808.074810] irq event stamp: 347872
> > [ 808.078305] hardirqs last enabled at (347871): [<ffff2000082080e8>]
> > vprintk_emit+0x2b0/0x5c0
> > [ 808.086833] hardirqs last disabled at (347872): [<ffff200008081490>]
> > do_debug_exception+0xd8/0x190
> > [ 808.095795] softirqs last enabled at (347844): [<ffff200008082210>]
> > __do_softirq+0x7c8/0x9c8
> > [ 808.104325] softirqs last disabled at (347837): [<ffff20000812dbe4>]
> > irq_exit+0x25c/0x2f0
> > [ 808.112502] ---[ end trace 598902d30712b79e ]---
>
>
On Tue, 13 Nov 2018 13:58:18 -0500
Qian Cai <[email protected]> wrote:
> > Care to print the len and name parameters before this line?
> len = 60612; name =
How big are pages on arm64? Because we shouldn't get to this path if
the string is bigger than PAGE_SIZE. But I know that on PPC64,
PAGE_SIZE can be 64K, and 60612 is less than that. Thus, if we get
there, the test is against signed int:16 (16 bit signed integer) that
can go up to most 32768. If the string size is bigger than that, you
would get this error.
I would just say to ignore it. The only thing that can happen if
someone does this is to trigger the warning. Unless if it is considered
a form of DOS, where userspace just bombards the console by triggering
this waring. But I don't see a problem with the actual design. There's
no reason we should be processing string variables bigger than 32768 in
vsprintf.
-- Steve
> %d%d%d%d%d%d%s%s%s%d%s%d%d%d%s%s%s%s%s%d%s%d%s%s%s%d%s%d%d%s%s%d%s%s%d%d%s%s%s%s
> %s%d%s%d%d%s%s%s%d%d%d%d%d%s%s%s%s%d%s%s%s%s%d%d%d%d%d%d%d%s%s%s%s%d%s%d%s%d%s%d
> %s%s%d%s%d%s%s%s%s%d%s%d%s%s%d%d%s%s%d%s%d%s%s%d%s%d%d%s%s%s%s%d%s%s%s%s%d%d%s%s
> %s%d%s%d%s%s%d%d%d%d%d%s%s%s%s%s%s%s%d%d%d%s%d%s%d%d%s%d%d%d%s%s%d%d%d%s%s%d%s%d
> %s%s%s%d%d%d%s%d%s%s%d%s%d%s%s%d%s%d%d%s%d%s%s%d%s%s%s%s%s%d%s%d%d%d%s%d%d%d%d%s
> %d%s%d%d%d%s%s%s%s%s%d%s%s%s%s%d%d%d%s%d%s%d%d%s%d%s%s%d%d%d%s%d%s%d%d%s%s%s%d%s
> %s%d%d%d%d%d%d%d%d%d%d%s%d%s%d%s%d%d%s%d%d%s%d%s%s%s%d%d%d%d%s%s%d%d%s%d%d%d%s%d
> %d%s%d%d%d%d%s%s%d%s%s%d%d%d%s%s%s%s%s%s%s%s%s%d%s%d%d%s%d%s%s%d%s%s%s%s%d%d%d%d
> %s%d%s%s%d%d%d%s%d%d%d%s%s%s%s%d%d%d%s%d%s%d%s%d%d%d%d%d%d%d%d%d%d%s%s%d%d%d%s%d
> %d%d%s%s%s%s%s%s%s%d%d%d%d%s%s%d%s%s%d%s%s%s%s%d%d%s%d%d%s%d%d%s%d%d%d%s%s%s%s%d
> %s%s%d%s%d%s%d%s%d%d%d%d%s%d%d%d%s%d%d%d%d%s%s%d%s%s%d%d%d%s%d%s%d%d%d%d%d%d%s%d
> %s%s%d%d%s%d%d%d%s%s%d%s%d%s%d%s%d%d%s%d%s%s%s%s%s%d%s%s%d%d%d%s%s%d%d%s%s%d%s%d
> %s%d%s%s%s%
> [ 833.044728] ------------[ cut here ]------------
> [ 833.137184] precision 60612 too large
> >
On Tue 2018-11-13 14:23:17, Steven Rostedt wrote:
> On Tue, 13 Nov 2018 13:58:18 -0500
> Qian Cai <[email protected]> wrote:
>
> > > Care to print the len and name parameters before this line?
> > len = 60612; name =
>
> How big are pages on arm64? Because we shouldn't get to this path if
> the string is bigger than PAGE_SIZE. But I know that on PPC64,
> PAGE_SIZE can be 64K, and 60612 is less than that. Thus, if we get
> there, the test is against signed int:16 (16 bit signed integer) that
> can go up to most 32768. If the string size is bigger than that, you
> would get this error.
>
> I would just say to ignore it.
I tend to agree.
> The only thing that can happen if
> someone does this is to trigger the warning. Unless if it is considered
> a form of DOS, where userspace just bombards the console by triggering
> this waring.
We are actually on the safe side because it is WARN_ONCE().
> But I don't see a problem with the actual design. There's
> no reason we should be processing string variables bigger than 32768 in
> vsprintf.
It is not even needed in this case. The string is limited also by
MODULE_NAME_LEN.
Best Regards,
Petr
On Wed, Nov 14, 2018 at 12:05:12AM +0100, Petr Mladek wrote:
> On Tue 2018-11-13 14:23:17, Steven Rostedt wrote:
> > On Tue, 13 Nov 2018 13:58:18 -0500
> > Qian Cai <[email protected]> wrote:
> >
> > > > Care to print the len and name parameters before this line?
> > > len = 60612; name =
> >
> > How big are pages on arm64? Because we shouldn't get to this path if
> > the string is bigger than PAGE_SIZE. But I know that on PPC64,
> > PAGE_SIZE can be 64K, and 60612 is less than that. Thus, if we get
> > there, the test is against signed int:16 (16 bit signed integer) that
> > can go up to most 32768. If the string size is bigger than that, you
> > would get this error.
> >
> > I would just say to ignore it.
>
> I tend to agree.
>
> > The only thing that can happen if
> > someone does this is to trigger the warning. Unless if it is considered
> > a form of DOS, where userspace just bombards the console by triggering
> > this waring.
>
> We are actually on the safe side because it is WARN_ONCE().
>
> > But I don't see a problem with the actual design. There's
> > no reason we should be processing string variables bigger than 32768 in
> > vsprintf.
>
> It is not even needed in this case. The string is limited also by
> MODULE_NAME_LEN.
At least not in this code.
Are you proposing to replace strlen(name) with strnlen(name, MODULE_NAME_LEN)?
--
With Best Regards,
Andy Shevchenko
On Wed 2018-11-14 11:38:19, Andy Shevchenko wrote:
> On Wed, Nov 14, 2018 at 12:05:12AM +0100, Petr Mladek wrote:
> > On Tue 2018-11-13 14:23:17, Steven Rostedt wrote:
> > > On Tue, 13 Nov 2018 13:58:18 -0500
> > > Qian Cai <[email protected]> wrote:
> > >
> > > > > Care to print the len and name parameters before this line?
> > > > len = 60612; name =
> > >
> > > How big are pages on arm64? Because we shouldn't get to this path if
> > > the string is bigger than PAGE_SIZE. But I know that on PPC64,
> > > PAGE_SIZE can be 64K, and 60612 is less than that. Thus, if we get
> > > there, the test is against signed int:16 (16 bit signed integer) that
> > > can go up to most 32768. If the string size is bigger than that, you
> > > would get this error.
> > >
> > > I would just say to ignore it.
> >
> > I tend to agree.
> >
> > > The only thing that can happen if
> > > someone does this is to trigger the warning. Unless if it is considered
> > > a form of DOS, where userspace just bombards the console by triggering
> > > this waring.
> >
> > We are actually on the safe side because it is WARN_ONCE().
> >
> > > But I don't see a problem with the actual design. There's
> > > no reason we should be processing string variables bigger than 32768 in
> > > vsprintf.
> >
> > It is not even needed in this case. The string is limited also by
> > MODULE_NAME_LEN.
>
> At least not in this code.
>
> Are you proposing to replace strlen(name) with strnlen(name, MODULE_NAME_LEN)?
It might be a solution. Well, it looks like a wrong design when we
would need to use MODULE_NAME_LEN outside module loader code. Also
it does not handle other request_module() users that might be
affected.
On the other hand, I am not sure how a proper solution would look
like. request_module() should not limit printk format before
the arguments are substituted.
The most clean solution probably would be on the vsprintf-level.
I mean to limit the precision by the overall string length
limit. But it looks a bit weird as well.
I still tend to ignore it. The code is safe from the security point of
view. The warning would trigger only when completely misused.
Best Regards,
Petr
On Tue, 2018-11-13 at 14:23 -0500, Steven Rostedt wrote:
> On Tue, 13 Nov 2018 13:58:18 -0500
> Qian Cai <[email protected]> wrote:
>
> > > Care to print the len and name parameters before this line?
> >
> > len = 60612; name =
>
> How big are pages on arm64? Because we shouldn't get to this path if
# getconf PAGESIZE
65536
> the string is bigger than PAGE_SIZE. But I know that on PPC64,
> PAGE_SIZE can be 64K, and 60612 is less than that. Thus, if we get
> there, the test is against signed int:16 (16 bit signed integer) that
> can go up to most 32768. If the string size is bigger than that, you
> would get this error.
>
> I would just say to ignore it. The only thing that can happen if
> someone does this is to trigger the warning. Unless if it is considered
> a form of DOS, where userspace just bombards the console by triggering
> this waring. But I don't see a problem with the actual design. There's
> no reason we should be processing string variables bigger than 32768 in
> vsprintf.
>
> -- Steve
>
>
> > %d%d%d%d%d%d%s%s%s%d%s%d%d%d%s%s%s%s%s%d%s%d%s%s%s%d%s%d%d%s%s%d%s%s%d%d%s%s
> > %s%s
> > %s%d%s%d%d%s%s%s%d%d%d%d%d%s%s%s%s%d%s%s%s%s%d%d%d%d%d%d%d%s%s%s%s%d%s%d%s%d
> > %s%d
> > %s%s%d%s%d%s%s%s%s%d%s%d%s%s%d%d%s%s%d%s%d%s%s%d%s%d%d%s%s%s%s%d%s%s%s%s%d%d
> > %s%s
> > %s%d%s%d%s%s%d%d%d%d%d%s%s%s%s%s%s%s%d%d%d%s%d%s%d%d%s%d%d%d%s%s%d%d%d%s%s%d
> > %s%d
> > %s%s%s%d%d%d%s%d%s%s%d%s%d%s%s%d%s%d%d%s%d%s%s%d%s%s%s%s%s%d%s%d%d%d%s%d%d%d
> > %d%s
> > %d%s%d%d%d%s%s%s%s%s%d%s%s%s%s%d%d%d%s%d%s%d%d%s%d%s%s%d%d%d%s%d%s%d%d%s%s%s
> > %d%s
> > %s%d%d%d%d%d%d%d%d%d%d%s%d%s%d%s%d%d%s%d%d%s%d%s%s%s%d%d%d%d%s%s%d%d%s%d%d%d
> > %s%d
> > %d%s%d%d%d%d%s%s%d%s%s%d%d%d%s%s%s%s%s%s%s%s%s%d%s%d%d%s%d%s%s%d%s%s%s%s%d%d
> > %d%d
> > %s%d%s%s%d%d%d%s%d%d%d%s%s%s%s%d%d%d%s%d%s%d%s%d%d%d%d%d%d%d%d%d%d%s%s%d%d%d
> > %s%d
> > %d%d%s%s%s%s%s%s%s%d%d%d%d%s%s%d%s%s%d%s%s%s%s%d%d%s%d%d%s%d%d%s%d%d%d%s%s%s
> > %s%d
> > %s%s%d%s%d%s%d%s%d%d%d%d%s%d%d%d%s%d%d%d%d%s%s%d%s%s%d%d%d%s%d%s%d%d%d%d%d%d
> > %s%d
> > %s%s%d%d%s%d%d%d%s%s%d%s%d%s%d%s%d%d%s%d%s%s%s%s%s%d%s%s%d%d%d%s%s%d%d%s%s%d
> > %s%d
> > %s%d%s%s%s%
> > [ 833.044728] ------------[ cut here ]------------
> > [ 833.137184] precision 60612 too large
> > >