"value":"In the Linux kernel, the following vulnerability has been resolved:\n\npid: take a reference when initializing `cad_pid`\n\nDuring boot, kernel_init_freeable() initializes `cad_pid` to the init\ntask's struct pid. Later on, we may change `cad_pid` via a sysctl, and\nwhen this happens proc_do_cad_pid() will increment the refcount on the\nnew pid via get_pid(), and will decrement the refcount on the old pid\nvia put_pid(). As we never called get_pid() when we initialized\n`cad_pid`, we decrement a reference we never incremented, can therefore\nfree the init task's struct pid early. As there can be dangling\nreferences to the struct pid, we can later encounter a use-after-free\n(e.g. when delivering signals).\n\nThis was spotted when fuzzing v5.13-rc3 with Syzkaller, but seems to\nhave been around since the conversion of `cad_pid` to struct pid in\ncommit 9ec52099e4b8 (\"[PATCH] replace cad_pid by a struct pid\")fromthe\npre-KASANstoneageofv2.6.19.\n\nFixthisbygettingareferencetotheinittask'sstructpidwhenwe\nassignitto`cad_pid`.\n\nFullKASANsplatbelow.\n\n==================================================================\nBUG:KASAN:use-after-freeinns_of_pidinclude/linux/pid.h:153[inline]\nBUG:KASAN:use-after-freeintask_active_pid_ns+0xc0/0xc8kernel/pid.c:509\nReadofsize4ataddrffff23794dda0004bytasksyz-executor.0/273\n\nCPU:1PID:273Comm:syz-executor.0Nottainted5.12.0-00001-g9aef892b2d15#1\nHardwarename:linux,dummy-virt(DT)\nCalltrace:\nns_of_pidinclude/linux/pid.h:153[inline]\ntask_active_pid_ns+0xc0/0xc8kernel/pid.c:509\ndo_notify_parent+0x308/0xe60kernel/signal.c:1950\nexit_notifykernel/exit.c:682[inline]\ndo_exit+0x2334/0x2bd0kernel/exit.c:845\ndo_group_exit+0x108/0x2c8kernel/exit.c:922\nget_signal+0x4e4/0x2a88kernel/signal.c:2781\ndo_signalarch/arm64/kernel/signal.c:882[inline]\ndo_notify_resume+0x300/0x970arch/arm64/kernel/signal.c:936\nwork_pending+0xc/0x2dc\n\nAllocatedbytask0:\nslab_post_alloc_hook+0x50/0x5c0mm/slab.h:516\nslab_alloc_nodemm/slub.c:2907[inline]\nslab_allocmm/slub.c:2915[inline]\nkmem_cache_alloc+0x1f4/0x4c0mm/slub.c:2920\nalloc_pid+0xdc/0xc00kernel/pid.c:180\ncopy_process+0x2794/0x5e18kernel/fork.c:2129\nkernel_clone+0x194/0x13c8kernel/fork.c:2500\nkernel_thread+0xd4/0x110kernel/fork.c:2552\nrest_init+0x44/0x4a0init/main.c:687\narch_call_rest_init+0x1c/0x28\nstart_kernel+0x520/0x554init/main.c:1064\n0x0\n\nFreedbytask270:\nslab_free_hookmm/slub.c:1562[inline]\nslab_free_freelist_hook+0x98/0x260mm/slub.c:1600\nslab_freemm/slub.c:3161[inline]\nkmem_cache_free+0x224/0x8e0mm/slub.c:3177\nput_pid.part.4+0xe0/0x1a8kernel/pid.c:114\nput_pid+0x30/0x48kernel/pid.c:109\nproc_do_cad_pid+0x190/0x1b0kernel/sysctl.c:1401\nproc_sys_call_handler+0x338/0x4b0fs/proc/proc_sysctl.c:591\nproc_sys_write+0x34/0x48fs/proc/proc_sysctl.c:617\ncall_write_iterinclude/linux/fs.h:1977[inline]\nnew_sync_write+0x3ac/0x510fs/read_write.c:518\nvfs_writefs/read_write.c:605[inline]\nvfs_write+0x9c4/0x1018fs/read_write.c:585\nksys_write+0x124/0x240fs/read_write.c:658\n__do_sys_writefs/read_write.c:670[inline]\n__se_sys_writefs/read_write.c:667[inline]\n__arm64_sys_write+0x78/0xb0fs/read_write.c:667\n__invoke_syscallarch/arm64/kernel/syscall.c:37[inline]\ninvoke_syscallarch/arm64/kernel/syscall.c:49[inline]\nel0_svc_common.constprop.1+0x16c/0x388arch/arm64/kernel/syscall.c:129\ndo_el0_svc+0xf8/0x150arch/arm64/kernel/syscall.c:168\nel0_svc+0x28/0x38arch/arm64/kernel/entry-common.c:416\nel0_sync_handler+0x134/0x180arch/arm64/kernel/entry-common.c:432\nel0_sync+0x154/0x180arch/arm64/kernel/entry.S:701\n\nThebuggyaddressbelongstotheobjectatffff23794dda0000\nwhichbelongstothecachepidofsize224\nThebuggyaddressislocated4bytesinsideof\n224-byteregion[ff\n---trun