Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> apparmor: fix reference count leak in aa_pivotroot()<br /> <br /> The aa_pivotroot() function has a reference counting bug in a specific<br /> path. When aa_replace_current_label() returns on success, the function<br /> forgets to decrement the reference count of “target”, which is<br /> increased earlier by build_pivotroot(), causing a reference leak.<br /> <br /> Fix it by decreasing the refcount of “target” in that path.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> cifs: Fix memory leak on the deferred close<br /> <br /> xfstests on smb21 report kmemleak as below:<br /> <br /> unreferenced object 0xffff8881767d6200 (size 64):<br /> comm "xfs_io", pid 1284, jiffies 4294777434 (age 20.789s)<br /> hex dump (first 32 bytes):<br /> 80 5a d0 11 81 88 ff ff 78 8a aa 63 81 88 ff ff .Z......x..c....<br /> 00 71 99 76 81 88 ff ff 00 00 00 00 00 00 00 00 .q.v............<br /> backtrace:<br /> [] cifs_close+0x92/0x2c0<br /> [] __fput+0xff/0x3f0<br /> [] task_work_run+0x85/0xc0<br /> [] do_exit+0x5e5/0x1240<br /> [] do_group_exit+0x58/0xe0<br /> [] __x64_sys_exit_group+0x28/0x30<br /> [] do_syscall_64+0x35/0x80<br /> [] entry_SYSCALL_64_after_hwframe+0x46/0xb0<br /> <br /> When cancel the deferred close work, we should also cleanup the struct<br /> cifs_deferred_close.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> tracing/eprobes: Have event probes be consistent with kprobes and uprobes<br /> <br /> Currently, if a symbol "@" is attempted to be used with an event probe<br /> (eprobes), it will cause a NULL pointer dereference crash.<br /> <br /> Both kprobes and uprobes can reference data other than the main registers.<br /> Such as immediate address, symbols and the current task name. Have eprobes<br /> do the same thing.<br /> <br /> For "comm", if "comm" is used and the event being attached to does not<br /> have the "comm" field, then make it the "$comm" that kprobes has. This is<br /> consistent to the way histograms and filters work.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> apparmor: Fix memleak in aa_simple_write_to_buffer()<br /> <br /> When copy_from_user failed, the memory is freed by kvfree. however the<br /> management struct and data blob are allocated independently, so only<br /> kvfree(data) cause a memleak issue here. Use aa_put_loaddata(data) to<br /> fix this issue.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> tee: add overflow check in register_shm_helper()<br /> <br /> With special lengths supplied by user space, register_shm_helper() has<br /> an integer overflow when calculating the number of pages covered by a<br /> supplied user space memory region.<br /> <br /> This causes internal_get_user_pages_fast() a helper function of<br /> pin_user_pages_fast() to do a NULL pointer dereference:<br /> <br /> Unable to handle kernel NULL pointer dereference at virtual address 0000000000000010<br /> Modules linked in:<br /> CPU: 1 PID: 173 Comm: optee_example_a Not tainted 5.19.0 #11<br /> Hardware name: QEMU QEMU Virtual Machine, BIOS 0.0.0 02/06/2015<br /> pc : internal_get_user_pages_fast+0x474/0xa80<br /> Call trace:<br /> internal_get_user_pages_fast+0x474/0xa80<br /> pin_user_pages_fast+0x24/0x4c<br /> register_shm_helper+0x194/0x330<br /> tee_shm_register_user_buf+0x78/0x120<br /> tee_ioctl+0xd0/0x11a0<br /> __arm64_sys_ioctl+0xa8/0xec<br /> invoke_syscall+0x48/0x114<br /> <br /> Fix this by adding an an explicit call to access_ok() in<br /> tee_shm_register_user_buf() to catch an invalid user space address<br /> early.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: dsa: felix: suppress non-changes to the tagging protocol<br /> <br /> The way in which dsa_tree_change_tag_proto() works is that when<br /> dsa_tree_notify() fails, it doesn&amp;#39;t know whether the operation failed<br /> mid way in a multi-switch tree, or it failed for a single-switch tree.<br /> So even though drivers need to fail cleanly in<br /> ds-&gt;ops-&gt;change_tag_protocol(), DSA will still call dsa_tree_notify()<br /> again, to restore the old tag protocol for potential switches in the<br /> tree where the change did succeeed (before failing for others).<br /> <br /> This means for the felix driver that if we report an error in<br /> felix_change_tag_protocol(), we&amp;#39;ll get another call where proto_ops ==<br /> old_proto_ops. If we proceed to act upon that, we may do unexpected<br /> things. For example, we will call dsa_tag_8021q_register() twice in a<br /> row, without any dsa_tag_8021q_unregister() in between. Then we will<br /> actually call dsa_tag_8021q_unregister() via old_proto_ops-&gt;teardown,<br /> which (if it manages to run at all, after walking through corrupted data<br /> structures) will leave the ports inoperational anyway.<br /> <br /> The bug can be readily reproduced if we force an error while in<br /> tag_8021q mode; this crashes the kernel.<br /> <br /> echo ocelot-8021q &gt; /sys/class/net/eno2/dsa/tagging<br /> echo edsa &gt; /sys/class/net/eno2/dsa/tagging # -EPROTONOSUPPORT<br /> <br /> Unable to handle kernel NULL pointer dereference at virtual address 0000000000000014<br /> Call trace:<br /> vcap_entry_get+0x24/0x124<br /> ocelot_vcap_filter_del+0x198/0x270<br /> felix_tag_8021q_vlan_del+0xd4/0x21c<br /> dsa_switch_tag_8021q_vlan_del+0x168/0x2cc<br /> dsa_switch_event+0x68/0x1170<br /> dsa_tree_notify+0x14/0x34<br /> dsa_port_tag_8021q_vlan_del+0x84/0x110<br /> dsa_tag_8021q_unregister+0x15c/0x1c0<br /> felix_tag_8021q_teardown+0x16c/0x180<br /> felix_change_tag_protocol+0x1bc/0x230<br /> dsa_switch_event+0x14c/0x1170<br /> dsa_tree_change_tag_proto+0x118/0x1c0

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> virtio-blk: Avoid use-after-free on suspend/resume<br /> <br /> hctx-&gt;user_data is set to vq in virtblk_init_hctx(). However, vq is<br /> freed on suspend and reallocated on resume. So, hctx-&gt;user_data is<br /> invalid after resume, and it will cause use-after-free accessing which<br /> will result in the kernel crash something like below:<br /> <br /> [ 22.428391] Call Trace:<br /> [ 22.428899] <br /> [ 22.429339] virtqueue_add_split+0x3eb/0x620<br /> [ 22.430035] ? __blk_mq_alloc_requests+0x17f/0x2d0<br /> [ 22.430789] ? kvm_clock_get_cycles+0x14/0x30<br /> [ 22.431496] virtqueue_add_sgs+0xad/0xd0<br /> [ 22.432108] virtblk_add_req+0xe8/0x150<br /> [ 22.432692] virtio_queue_rqs+0xeb/0x210<br /> [ 22.433330] blk_mq_flush_plug_list+0x1b8/0x280<br /> [ 22.434059] __blk_flush_plug+0xe1/0x140<br /> [ 22.434853] blk_finish_plug+0x20/0x40<br /> [ 22.435512] read_pages+0x20a/0x2e0<br /> [ 22.436063] ? folio_add_lru+0x62/0xa0<br /> [ 22.436652] page_cache_ra_unbounded+0x112/0x160<br /> [ 22.437365] filemap_get_pages+0xe1/0x5b0<br /> [ 22.437964] ? context_to_sid+0x70/0x100<br /> [ 22.438580] ? sidtab_context_to_sid+0x32/0x400<br /> [ 22.439979] filemap_read+0xcd/0x3d0<br /> [ 22.440917] xfs_file_buffered_read+0x4a/0xc0<br /> [ 22.441984] xfs_file_read_iter+0x65/0xd0<br /> [ 22.442970] __kernel_read+0x160/0x2e0<br /> [ 22.443921] bprm_execve+0x21b/0x640<br /> [ 22.444809] do_execveat_common.isra.0+0x1a8/0x220<br /> [ 22.446008] __x64_sys_execve+0x2d/0x40<br /> [ 22.446920] do_syscall_64+0x37/0x90<br /> [ 22.447773] entry_SYSCALL_64_after_hwframe+0x63/0xcd<br /> <br /> This patch fixes this issue by getting vq from vblk, and removes<br /> virtblk_init_hctx().

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mptcp: move subflow cleanup in mptcp_destroy_common()<br /> <br /> If the mptcp socket creation fails due to a CGROUP_INET_SOCK_CREATE<br /> eBPF program, the MPTCP protocol ends-up leaking all the subflows:<br /> the related cleanup happens in __mptcp_destroy_sock() that is not<br /> invoked in such code path.<br /> <br /> Address the issue moving the subflow sockets cleanup in the<br /> mptcp_destroy_common() helper, which is invoked in every msk cleanup<br /> path.<br /> <br /> Additionally get rid of the intermediate list_splice_init step, which<br /> is an unneeded relic from the past.<br /> <br /> The issue is present since before the reported root cause commit, but<br /> any attempt to backport the fix before that hash will require a complete<br /> rewrite.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mptcp: do not queue data on closed subflows<br /> <br /> Dipanjan reported a syzbot splat at close time:<br /> <br /> WARNING: CPU: 1 PID: 10818 at net/ipv4/af_inet.c:153<br /> inet_sock_destruct+0x6d0/0x8e0 net/ipv4/af_inet.c:153<br /> Modules linked in: uio_ivshmem(OE) uio(E)<br /> CPU: 1 PID: 10818 Comm: kworker/1:16 Tainted: G OE<br /> 5.19.0-rc6-g2eae0556bb9d #2<br /> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS<br /> 1.13.0-1ubuntu1.1 04/01/2014<br /> Workqueue: events mptcp_worker<br /> RIP: 0010:inet_sock_destruct+0x6d0/0x8e0 net/ipv4/af_inet.c:153<br /> Code: 21 02 00 00 41 8b 9c 24 28 02 00 00 e9 07 ff ff ff e8 34 4d 91<br /> f9 89 ee 4c 89 e7 e8 4a 47 60 ff e9 a6 fc ff ff e8 20 4d 91 f9 0b<br /> e9 84 fe ff ff e8 14 4d 91 f9 0f 0b e9 d4 fd ff ff e8 08 4d<br /> RSP: 0018:ffffc9001b35fa78 EFLAGS: 00010246<br /> RAX: 0000000000000000 RBX: 00000000002879d0 RCX: ffff8881326f3b00<br /> RDX: 0000000000000000 RSI: ffff8881326f3b00 RDI: 0000000000000002<br /> RBP: ffff888179662674 R08: ffffffff87e983a0 R09: 0000000000000000<br /> R10: 0000000000000005 R11: 00000000000004ea R12: ffff888179662400<br /> R13: ffff888179662428 R14: 0000000000000001 R15: ffff88817e38e258<br /> FS: 0000000000000000(0000) GS:ffff8881f5f00000(0000) knlGS:0000000000000000<br /> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> CR2: 0000000020007bc0 CR3: 0000000179592000 CR4: 0000000000150ee0<br /> Call Trace:<br /> <br /> __sk_destruct+0x4f/0x8e0 net/core/sock.c:2067<br /> sk_destruct+0xbd/0xe0 net/core/sock.c:2112<br /> __sk_free+0xef/0x3d0 net/core/sock.c:2123<br /> sk_free+0x78/0xa0 net/core/sock.c:2134<br /> sock_put include/net/sock.h:1927 [inline]<br /> __mptcp_close_ssk+0x50f/0x780 net/mptcp/protocol.c:2351<br /> __mptcp_destroy_sock+0x332/0x760 net/mptcp/protocol.c:2828<br /> mptcp_worker+0x5d2/0xc90 net/mptcp/protocol.c:2586<br /> process_one_work+0x9cc/0x1650 kernel/workqueue.c:2289<br /> worker_thread+0x623/0x1070 kernel/workqueue.c:2436<br /> kthread+0x2e9/0x3a0 kernel/kthread.c:376<br /> ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:302<br /> <br /> <br /> The root cause of the problem is that an mptcp-level (re)transmit can<br /> race with mptcp_close() and the packet scheduler checks the subflow<br /> state before acquiring the socket lock: we can try to (re)transmit on<br /> an already closed ssk.<br /> <br /> Fix the issue checking again the subflow socket status under the<br /> subflow socket lock protection. Additionally add the missing check<br /> for the fallback-to-tcp case.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> BPF: Fix potential bad pointer dereference in bpf_sys_bpf()<br /> <br /> The bpf_sys_bpf() helper function allows an eBPF program to load another<br /> eBPF program from within the kernel. In this case the argument union<br /> bpf_attr pointer (as well as the insns and license pointers inside) is a<br /> kernel address instead of a userspace address (which is the case of a<br /> usual bpf() syscall). To make the memory copying process in the syscall<br /> work in both cases, bpfptr_t was introduced to wrap around the pointer<br /> and distinguish its origin. Specifically, when copying memory contents<br /> from a bpfptr_t, a copy_from_user() is performed in case of a userspace<br /> address and a memcpy() is performed for a kernel address.<br /> <br /> This can lead to problems because the in-kernel pointer is never checked<br /> for validity. The problem happens when an eBPF syscall program tries to<br /> call bpf_sys_bpf() to load a program but provides a bad insns pointer --<br /> say 0xdeadbeef -- in the bpf_attr union. The helper calls __sys_bpf()<br /> which would then call bpf_prog_load() to load the program.<br /> bpf_prog_load() is responsible for copying the eBPF instructions to the<br /> newly allocated memory for the program; it creates a kernel bpfptr_t for<br /> insns and invokes copy_from_bpfptr(). Internally, all bpfptr_t<br /> operations are backed by the corresponding sockptr_t operations, which<br /> performs direct memcpy() on kernel pointers for copy_from/strncpy_from<br /> operations. Therefore, the code is always happy to dereference the bad<br /> pointer to trigger a un-handle-able page fault and in turn an oops.<br /> However, this is not supposed to happen because at that point the eBPF<br /> program is already verified and should not cause a memory error.<br /> <br /> Sample KASAN trace:<br /> <br /> [ 25.685056][ T228] ==================================================================<br /> [ 25.685680][ T228] BUG: KASAN: user-memory-access in copy_from_bpfptr+0x21/0x30<br /> [ 25.686210][ T228] Read of size 80 at addr 00000000deadbeef by task poc/228<br /> [ 25.686732][ T228]<br /> [ 25.686893][ T228] CPU: 3 PID: 228 Comm: poc Not tainted 5.19.0-rc7 #7<br /> [ 25.687375][ T228] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS d55cb5a 04/01/2014<br /> [ 25.687991][ T228] Call Trace:<br /> [ 25.688223][ T228] <br /> [ 25.688429][ T228] dump_stack_lvl+0x73/0x9e<br /> [ 25.688747][ T228] print_report+0xea/0x200<br /> [ 25.689061][ T228] ? copy_from_bpfptr+0x21/0x30<br /> [ 25.689401][ T228] ? _printk+0x54/0x6e<br /> [ 25.689693][ T228] ? _raw_spin_lock_irqsave+0x70/0xd0<br /> [ 25.690071][ T228] ? copy_from_bpfptr+0x21/0x30<br /> [ 25.690412][ T228] kasan_report+0xb5/0xe0<br /> [ 25.690716][ T228] ? copy_from_bpfptr+0x21/0x30<br /> [ 25.691059][ T228] kasan_check_range+0x2bd/0x2e0<br /> [ 25.691405][ T228] ? copy_from_bpfptr+0x21/0x30<br /> [ 25.691734][ T228] memcpy+0x25/0x60<br /> [ 25.692000][ T228] copy_from_bpfptr+0x21/0x30<br /> [ 25.692328][ T228] bpf_prog_load+0x604/0x9e0<br /> [ 25.692653][ T228] ? cap_capable+0xb4/0xe0<br /> [ 25.692956][ T228] ? security_capable+0x4f/0x70<br /> [ 25.693324][ T228] __sys_bpf+0x3af/0x580<br /> [ 25.693635][ T228] bpf_sys_bpf+0x45/0x240<br /> [ 25.693937][ T228] bpf_prog_f0ec79a5a3caca46_bpf_func1+0xa2/0xbd<br /> [ 25.694394][ T228] bpf_prog_run_pin_on_cpu+0x2f/0xb0<br /> [ 25.694756][ T228] bpf_prog_test_run_syscall+0x146/0x1c0<br /> [ 25.695144][ T228] bpf_prog_test_run+0x172/0x190<br /> [ 25.695487][ T228] __sys_bpf+0x2c5/0x580<br /> [ 25.695776][ T228] __x64_sys_bpf+0x3a/0x50<br /> [ 25.696084][ T228] do_syscall_64+0x60/0x90<br /> [ 25.696393][ T228] ? fpregs_assert_state_consistent+0x50/0x60<br /> [ 25.696815][ T228] ? exit_to_user_mode_prepare+0x36/0xa0<br /> [ 25.697202][ T228] ? syscall_exit_to_user_mode+0x20/0x40<br /> [ 25.697586][ T228] ? do_syscall_64+0x6e/0x90<br /> [ 25.697899][ T228] entry_SYSCALL_64_after_hwframe+0x63/0xcd<br /> [ 25.698312][ T228] RIP: 0033:0x7f6d543fb759<br /> [ 25.698624][ T228] Code: 08 5b 89 e8 5d c3 66 2e 0f 1f 84 00 00 00 00 00 90 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d <br /> ---truncated---

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/ttm: Fix dummy res NULL ptr deref bug<br /> <br /> Check the bo-&gt;resource value before accessing the resource<br /> mem_type.<br /> <br /> v2: Fix commit description unwrapped warning<br /> <br /> <br /> [ 40.191227][ T184] general protection fault, probably for non-canonical address 0xdffffc0000000002: 0000 [#1] SMP KASAN PTI<br /> [ 40.192995][ T184] KASAN: null-ptr-deref in range [0x0000000000000010-0x0000000000000017]<br /> [ 40.194411][ T184] CPU: 1 PID: 184 Comm: systemd-udevd Not tainted 5.19.0-rc4-00721-gb297c22b7070 #1<br /> [ 40.196063][ T184] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.0-debian-1.16.0-4 04/01/2014<br /> [ 40.199605][ T184] RIP: 0010:ttm_bo_validate+0x1b3/0x240 [ttm]<br /> [ 40.200754][ T184] Code: e8 72 c5 ff ff 83 f8 b8 74 d4 85 c0 75 54 49 8b 9e 58 01 00 00 48 b8 00 00 00 00 00 fc ff df 48 8d 7b 10 48 89 fa 48 c1 ea 03 b6 04 02 84 c0 74 04 3c 03 7e 44 8b 53 10 31 c0 85 d2 0f 85 58<br /> [ 40.203685][ T184] RSP: 0018:ffffc900006df0c8 EFLAGS: 00010202<br /> [ 40.204630][ T184] RAX: dffffc0000000000 RBX: 0000000000000000 RCX: 1ffff1102f4bb71b<br /> [ 40.205864][ T184] RDX: 0000000000000002 RSI: ffffc900006df208 RDI: 0000000000000010<br /> [ 40.207102][ T184] RBP: 1ffff920000dbe1a R08: ffffc900006df208 R09: 0000000000000000<br /> [ 40.208394][ T184] R10: ffff88817a5f0000 R11: 0000000000000001 R12: ffffc900006df110<br /> [ 40.209692][ T184] R13: ffffc900006df0f0 R14: ffff88817a5db800 R15: ffffc900006df208<br /> [ 40.210862][ T184] FS: 00007f6b1d16e8c0(0000) GS:ffff88839d700000(0000) knlGS:0000000000000000<br /> [ 40.212250][ T184] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> [ 40.213275][ T184] CR2: 000055a1001d4ff0 CR3: 00000001700f4000 CR4: 00000000000006e0<br /> [ 40.214469][ T184] Call Trace:<br /> [ 40.214974][ T184] <br /> [ 40.215438][ T184] ? ttm_bo_bounce_temp_buffer+0x140/0x140 [ttm]<br /> [ 40.216572][ T184] ? mutex_spin_on_owner+0x240/0x240<br /> [ 40.217456][ T184] ? drm_vma_offset_add+0xaa/0x100 [drm]<br /> [ 40.218457][ T184] ttm_bo_init_reserved+0x3d6/0x540 [ttm]<br /> [ 40.219410][ T184] ? shmem_get_inode+0x744/0x980<br /> [ 40.220231][ T184] ttm_bo_init_validate+0xb1/0x200 [ttm]<br /> [ 40.221172][ T184] ? bo_driver_evict_flags+0x340/0x340 [drm_vram_helper]<br /> [ 40.222530][ T184] ? ttm_bo_init_reserved+0x540/0x540 [ttm]<br /> [ 40.223643][ T184] ? __do_sys_finit_module+0x11a/0x1c0<br /> [ 40.224654][ T184] ? __shmem_file_setup+0x102/0x280<br /> [ 40.234764][ T184] drm_gem_vram_create+0x305/0x480 [drm_vram_helper]<br /> [ 40.235766][ T184] ? bo_driver_evict_flags+0x340/0x340 [drm_vram_helper]<br /> [ 40.236846][ T184] ? __kasan_slab_free+0x108/0x180<br /> [ 40.237650][ T184] drm_gem_vram_fill_create_dumb+0x134/0x340 [drm_vram_helper]<br /> [ 40.238864][ T184] ? local_pci_probe+0xdf/0x180<br /> [ 40.239674][ T184] ? drmm_vram_helper_init+0x400/0x400 [drm_vram_helper]<br /> [ 40.240826][ T184] drm_client_framebuffer_create+0x19c/0x400 [drm]<br /> [ 40.241955][ T184] ? drm_client_buffer_delete+0x200/0x200 [drm]<br /> [ 40.243001][ T184] ? drm_client_pick_crtcs+0x554/0xb80 [drm]<br /> [ 40.244030][ T184] drm_fb_helper_generic_probe+0x23f/0x940 [drm_kms_helper]<br /> [ 40.245226][ T184] ? __cond_resched+0x1c/0xc0<br /> [ 40.245987][ T184] ? drm_fb_helper_memory_range_to_clip+0x180/0x180 [drm_kms_helper]<br /> [ 40.247316][ T184] ? mutex_unlock+0x80/0x100<br /> [ 40.248005][ T184] ? __mutex_unlock_slowpath+0x2c0/0x2c0<br /> [ 40.249083][ T184] drm_fb_helper_single_fb_probe+0x907/0xf00 [drm_kms_helper]<br /> [ 40.250314][ T184] ? drm_fb_helper_check_var+0x1180/0x1180 [drm_kms_helper]<br /> [ 40.251540][ T184] ? __cond_resched+0x1c/0xc0<br /> [ 40.252321][ T184] ? mutex_lock+0x9f/0x100<br /> [ 40.253062][ T184] __drm_fb_helper_initial_config_and_unlock+0xb9/0x2c0 [drm_kms_helper]<br /> [ 40.254394][ T184] drm_fbdev_client_hotplug+0x56f/0x840 [drm_kms_helper]<br /> [ 40.255477][ T184] drm_fbdev_generic_setup+0x165/0x3c0 [drm_kms_helper]<br /> [ 40.256607][ T184] bochs_pci_probe+0x6b7/0x900 [bochs]<br /> [ <br /> ---truncated---

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> btrfs: unset reloc control if transaction commit fails in prepare_to_relocate()<br /> <br /> In btrfs_relocate_block_group(), the rc is allocated. Then<br /> btrfs_relocate_block_group() calls<br /> <br /> relocate_block_group()<br /> prepare_to_relocate()<br /> set_reloc_control()<br /> <br /> that assigns rc to the variable fs_info-&gt;reloc_ctl. When<br /> prepare_to_relocate() returns, it calls<br /> <br /> btrfs_commit_transaction()<br /> btrfs_start_dirty_block_groups()<br /> btrfs_alloc_path()<br /> kmem_cache_zalloc()<br /> <br /> which may fail for example (or other errors could happen). When the<br /> failure occurs, btrfs_relocate_block_group() detects the error and frees<br /> rc and doesn&amp;#39;t set fs_info-&gt;reloc_ctl to NULL. After that, in<br /> btrfs_init_reloc_root(), rc is retrieved from fs_info-&gt;reloc_ctl and<br /> then used, which may cause a use-after-free bug.<br /> <br /> This possible bug can be triggered by calling btrfs_ioctl_balance()<br /> before calling btrfs_ioctl_defrag().<br /> <br /> To fix this possible bug, in prepare_to_relocate(), check if<br /> btrfs_commit_transaction() fails. If the failure occurs,<br /> unset_reloc_control() is called to set fs_info-&gt;reloc_ctl to NULL.<br /> <br /> The error log in our fault-injection testing is shown as follows:<br /> <br /> [ 58.751070] BUG: KASAN: use-after-free in btrfs_init_reloc_root+0x7ca/0x920 [btrfs]<br /> ...<br /> [ 58.753577] Call Trace:<br /> ...<br /> [ 58.755800] kasan_report+0x45/0x60<br /> [ 58.756066] btrfs_init_reloc_root+0x7ca/0x920 [btrfs]<br /> [ 58.757304] record_root_in_trans+0x792/0xa10 [btrfs]<br /> [ 58.757748] btrfs_record_root_in_trans+0x463/0x4f0 [btrfs]<br /> [ 58.758231] start_transaction+0x896/0x2950 [btrfs]<br /> [ 58.758661] btrfs_defrag_root+0x250/0xc00 [btrfs]<br /> [ 58.759083] btrfs_ioctl_defrag+0x467/0xa00 [btrfs]<br /> [ 58.759513] btrfs_ioctl+0x3c95/0x114e0 [btrfs]<br /> ...<br /> [ 58.768510] Allocated by task 23683:<br /> [ 58.768777] ____kasan_kmalloc+0xb5/0xf0<br /> [ 58.769069] __kmalloc+0x227/0x3d0<br /> [ 58.769325] alloc_reloc_control+0x10a/0x3d0 [btrfs]<br /> [ 58.769755] btrfs_relocate_block_group+0x7aa/0x1e20 [btrfs]<br /> [ 58.770228] btrfs_relocate_chunk+0xf1/0x760 [btrfs]<br /> [ 58.770655] __btrfs_balance+0x1326/0x1f10 [btrfs]<br /> [ 58.771071] btrfs_balance+0x3150/0x3d30 [btrfs]<br /> [ 58.771472] btrfs_ioctl_balance+0xd84/0x1410 [btrfs]<br /> [ 58.771902] btrfs_ioctl+0x4caa/0x114e0 [btrfs]<br /> ...<br /> [ 58.773337] Freed by task 23683:<br /> ...<br /> [ 58.774815] kfree+0xda/0x2b0<br /> [ 58.775038] free_reloc_control+0x1d6/0x220 [btrfs]<br /> [ 58.775465] btrfs_relocate_block_group+0x115c/0x1e20 [btrfs]<br /> [ 58.775944] btrfs_relocate_chunk+0xf1/0x760 [btrfs]<br /> [ 58.776369] __btrfs_balance+0x1326/0x1f10 [btrfs]<br /> [ 58.776784] btrfs_balance+0x3150/0x3d30 [btrfs]<br /> [ 58.777185] btrfs_ioctl_balance+0xd84/0x1410 [btrfs]<br /> [ 58.777621] btrfs_ioctl+0x4caa/0x114e0 [btrfs]<br /> ...