We don't correctly check the full size of buffers printed with %m/%M. When the precision is dynamic, the entire range is checked, but with a fixed precision we are only checking that the first byte can be deref'ed. This poses an issue if the starting address is valid but then falls off a page: $ stap -ve 'probe process("./stap").function("main") { printf("%.1000000M\n", $argv) }' -c './stap -V' stap_24f99805b992175d160c5afb97a0ad20_1268: systemtap: 1.0/0.143, base: ffffffffa01ec000, memory: 54data/22text/0ctx/13net/19alloc kb, probes: 1 BUG: unable to handle kernel paging request at 00007fff76162000 IP: [<ffffffffa01ecee9>] _stp_vsnprintf+0x928/0xc10 [stap_24f99805b992175d160c5afb97a0ad20_1268] PGD 1dd6e067 PUD 5ffc067 PMD 1bc1d067 PTE 0 Oops: 0000 [#2] SMP last sysfs file: /sys/module/virtio_ring/sections/__verbose CPU 0 Modules linked in: stap_24f99805b992175d160c5afb97a0ad20_1268 stap_db7716791ff58e1f3d03381e38c1171e_1394 uprobes nfs lockd fscache nfs_acl auth_rpcgss autofs4 sunrpc ip6t_REJECT nf_conntrack_ipv6 ip6table_filter ip6_tables ipv6 i2c_piix4 i2c_core virtio_net virtio_balloon virtio_blk floppy virtio_pci virtio_ring virtio [last unloaded: stap_2161bcb8f5cec40bb660a1d6982e24da_1260] Pid: 6668, comm: stap Tainted: G D 2.6.31.6-166.fc12.x86_64 #1 RIP: 0010:[<ffffffffa01ecee9>] [<ffffffffa01ecee9>] _stp_vsnprintf+0x928/0xc10 [stap_24f99805b992175d160c5afb97a0ad20_1268] RSP: 0000:ffff880003d29b48 EFLAGS: 00010287 RAX: 00000000000f4240 RBX: ffffc9000020a3f4 RCX: 00007fff76162000 RDX: 00007fff76160fe8 RSI: 0000000000001018 RDI: ffff880003d29bb9 RBP: ffff880003d29bf8 R08: 00000000fffffffe R09: 00000000000f4240 R10: 0000000000002000 R11: 0000000000003608 R12: ffff880003d29c08 R13: ffffc9000020a3c3 R14: 0000000000000000 R15: ffffffffa01f2531 FS: 00007fafd5e2f720(0000) GS:ffff8800019b6000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007fff76162000 CR3: 0000000003698000 CR4: 00000000000006f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000ffff4ff0 DR7: 0000000000000400 Process stap (pid: 6668, threadinfo ffff880003d28000, task ffff88001d9a8000) Stack: ffff880003d2e630 ffff88001d9a8000 ffff880003d29be8 ffff880003d29ba8 <0> ffff88001d14f000 0000000000000000 0000000000002000 0000000000000000 <0> ffff880000000010 ffff880003d29c68 ffff880003d29c28 0000000000000000 Call Trace: [<ffffffffa01ed254>] _stp_printf+0x48/0x4a [stap_24f99805b992175d160c5afb97a0ad20_1268] [<ffffffff8101a406>] ? genregs_get+0x34/0x88 [<ffffffffa01f1524>] probe_1885+0x287/0x2ea [stap_24f99805b992175d160c5afb97a0ad20_1268] [<ffffffffa01ee950>] enter_uprobe_probe+0x173/0x2d4 [stap_24f99805b992175d160c5afb97a0ad20_1268] [<ffffffffa018e640>] uprobe_report_signal+0x532/0x9be [uprobes] [<ffffffff8105dc6b>] ? __dequeue_signal+0xed/0x122 [<ffffffff8105f8cb>] ? dequeue_signal+0xab/0x11d [<ffffffff8108dc31>] utrace_get_signal+0x33d/0x5bc [<ffffffff810c1523>] ? unlock_page+0x14/0x16 [<ffffffff810d6a5e>] ? __do_fault+0x38d/0x3c4 [<ffffffff8105fa29>] get_signal_to_deliver+0xec/0x36d [<ffffffff8101106f>] do_notify_resume+0x89/0x748 [<ffffffff811ff209>] ? __up_read+0x76/0x81 [<ffffffff8106af52>] ? up_read+0xe/0x10 [<ffffffff8141b3a2>] paranoid_userspace+0x46/0x50 Code: 41 8d 70 01 39 f1 7c ea 41 80 3f 4d 48 89 d9 75 60 48 8b bd 68 ff ff ff 48 c7 c6 1f 1c 1f a0 b9 11 00 00 00 f3 a4 48 89 d1 eb 29 <0f> be 31 48 c1 ee 04 83 e6 0f 40 8a 74 35 b0 40 88 33 48 0f be RIP [<ffffffffa01ecee9>] _stp_vsnprintf+0x928/0xc10 [stap_24f99805b992175d160c5afb97a0ad20_1268] RSP <ffff880003d29b48> CR2: 00007fff76162000 ---[ end trace a772de976987833d ]--- Task died at uprobe probepoint: pid/tgid = 6668/6668, probepoint = 0x40abf0 This leaves the stap task stuck in the kernel chewing full CPU, though the system is otherwise still usable.
commit 63db23d