CVE-2021-47189

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> btrfs: fix memory ordering between normal and ordered work functions<br /> <br /> Ordered work functions aren&amp;#39;t guaranteed to be handled by the same thread<br /> which executed the normal work functions. The only way execution between<br /> normal/ordered functions is synchronized is via the WORK_DONE_BIT,<br /> unfortunately the used bitops don&amp;#39;t guarantee any ordering whatsoever.<br /> <br /> This manifested as seemingly inexplicable crashes on ARM64, where<br /> async_chunk::inode is seen as non-null in async_cow_submit which causes<br /> submit_compressed_extents to be called and crash occurs because<br /> async_chunk::inode suddenly became NULL. The call trace was similar to:<br /> <br /> pc : submit_compressed_extents+0x38/0x3d0<br /> lr : async_cow_submit+0x50/0xd0<br /> sp : ffff800015d4bc20<br /> <br /> <br /> <br /> Call trace:<br /> submit_compressed_extents+0x38/0x3d0<br /> async_cow_submit+0x50/0xd0<br /> run_ordered_work+0xc8/0x280<br /> btrfs_work_helper+0x98/0x250<br /> process_one_work+0x1f0/0x4ac<br /> worker_thread+0x188/0x504<br /> kthread+0x110/0x114<br /> ret_from_fork+0x10/0x18<br /> <br /> Fix this by adding respective barrier calls which ensure that all<br /> accesses preceding setting of WORK_DONE_BIT are strictly ordered before<br /> setting the flag. At the same time add a read barrier after reading of<br /> WORK_DONE_BIT in run_ordered_work which ensures all subsequent loads<br /> would be strictly ordered after reading the bit. This in turn ensures<br /> are all accesses before WORK_DONE_BIT are going to be strictly ordered<br /> before any access that can occur in ordered_func.