[kfence] Use patterns to detect non-faulting OOB writes

[ramosian-glider]

Because not all OOB accesses to KFENCE objects result in page faults, we can use pattern initialization as a best-effort protection measure: initialize the whole page with a pattern when allocating an object and perform an integrity check of unused parts when freeing it.

[ramosian-glider]

Got the first results from a nightly syzkaller run:

==================================================================
BUG: KFENCE: memory corruption at address ffff88813b370f03 on object #183 
CPU: 0 PID: 5 Comm: kworker/0:0 Not tainted 5.8.0-rc1+ #381 
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.13.0-1 04/01/2014
Workqueue: events kfree_rcu_work
Call Trace:
 __dump_stack lib/dump_stack.c:77
 dump_stack+0xd4/0x13e lib/dump_stack.c:118
 kfence_report_corruption mm/kfence/core.c:467
 set_or_check_canary_byte.cold+0x73/0xa0 mm/kfence/core.c:268
 set_or_check_canaries+0xc2/0xe0 mm/kfence/core.c:282
 kfence_guarded_free+0x131/0x1d0 mm/kfence/core.c:356
 kfence_free+0xac/0x100 mm/kfence/core.c:377
 __slab_free+0x31/0x520 mm/slub.c:2927
 do_slab_free mm/slub.c:3082
 slab_free mm/slub.c:3095
 kmem_cache_free_bulk mm/slub.c:3219
 kmem_cache_free_bulk+0x3bb/0x460 mm/slub.c:3207
 kfree_bulk ./include/linux/slab.h:413
 kfree_rcu_work+0xf5/0x3e0 kernel/rcu/tree.c:3051
 process_one_work+0x38a/0x900 kernel/workqueue.c:2269
 worker_thread+0x56/0x5c0 kernel/workqueue.c:2415
 kthread+0x17b/0x1c0 kernel/kthread.c:291
 ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:293
Object #183: starts at ffff88813b370e00, size=259
allocated at:
 save_stack+0x33/0x70 mm/kfence/core.c:95
 kfence_guarded_alloc+0x28a/0x3e0 mm/kfence/core.c:327
 kfence_alloc_with_size mm/kfence/naive.c:26
 kfence_alloc_with_size+0xd2/0x100 mm/kfence/naive.c:11
 __kmalloc+0x41/0x320 mm/slub.c:3928
 kmalloc ./include/linux/slab.h:572
 kzalloc ./include/linux/slab.h:681
 new_dir fs/proc/proc_sysctl.c:956
 get_subdir fs/proc/proc_sysctl.c:1003
 __register_sysctl_table+0x4b8/0x690 fs/proc/proc_sysctl.c:1346
 __addrconf_sysctl_register+0xfc/0x200 net/ipv6/addrconf.c:6900
 addrconf_sysctl_register net/ipv6/addrconf.c:6947
 addrconf_sysctl_register+0xd6/0x110 net/ipv6/addrconf.c:6936
 ipv6_add_dev net/ipv6/addrconf.c:443
 ipv6_add_dev+0x3be/0x780 net/ipv6/addrconf.c:364
 addrconf_notify+0x6be/0x1470 net/ipv6/addrconf.c:3462
 notifier_call_chain+0x5d/0x120 kernel/notifier.c:83
 call_netdevice_notifiers_info net/core/dev.c:2027
 call_netdevice_notifiers_info+0x78/0xe0 net/core/dev.c:2012
 call_netdevice_notifiers_extack net/core/dev.c:2039
 call_netdevice_notifiers net/core/dev.c:2053
 register_netdevice+0x783/0x860 net/core/dev.c:9543
 tun_set_iff drivers/net/tun.c:2817
 __tun_chr_ioctl+0x1901/0x1fa0 drivers/net/tun.c:3054
 vfs_ioctl fs/ioctl.c:48
 ksys_ioctl+0xde/0x130 fs/ioctl.c:753
 __do_sys_ioctl fs/ioctl.c:762
 __se_sys_ioctl fs/ioctl.c:760
 __x64_sys_ioctl+0x1a/0x20 fs/ioctl.c:760
 do_syscall_64+0x50/0x90 arch/x86/entry/common.c:359
==================================================================

Repro: probe-syz.c.txt

There are two problems with this bug:

• KASAN doesn't detect it: could be a false positive (caused e.g. by writing a word instead of a byte)
• it's barely actionable: even with a repro it's hard to understand what's going on.

[ramosian-glider]

Closing as fixed. We'll figure out how to act on heap corruption reports when we find some.