loop: Fix NULL pointer dereference by synchronizing lo_release and loop_queue_rq#816
loop: Fix NULL pointer dereference by synchronizing lo_release and loop_queue_rq#816blktests-ci[bot] wants to merge 1 commit into
Conversation
|
Upstream branch: aa54b1d |
|
Upstream branch: aa54b1d |
0496512 to
57c5032
Compare
b1870f6 to
ca57796
Compare
|
Upstream branch: 70eda68 |
57c5032 to
2de7efb
Compare
ca57796 to
c1feb59
Compare
|
Upstream branch: 8bc67e4 |
2de7efb to
43bd3eb
Compare
c1feb59 to
ea833a1
Compare
|
Upstream branch: 6779b50 |
43bd3eb to
14d5595
Compare
ea833a1 to
7af85d1
Compare
|
Upstream branch: 79bd2dd |
14d5595 to
0c0ff88
Compare
7af85d1 to
de94ac7
Compare
|
Upstream branch: eed108e |
0c0ff88 to
0043504
Compare
de94ac7 to
86d8d37
Compare
|
Upstream branch: e8c2f9f |
0043504 to
8ae013b
Compare
86d8d37 to
9805659
Compare
|
Upstream branch: eb3f4b7 |
8ae013b to
2236345
Compare
9805659 to
3f4a345
Compare
|
Upstream branch: 8fde5d1 |
2236345 to
63c9db2
Compare
3f4a345 to
c6dc343
Compare
|
Upstream branch: e43ffb6 |
63c9db2 to
802627a
Compare
c6dc343 to
fc36596
Compare
|
Upstream branch: ba3e43a |
…op_queue_rq The loop driver relies on lo_release() to automatically clear the loop device via __loop_clr_fd() when the last file descriptor is closed (LO_FLAGS_AUTOCLEAR). Although the backing file structure itself remains allocated in memory thanks to proper file reference counting (f_count is not zero), a severe race condition exists regarding the visibility of the lo->lo_backing_file pointer. This race window was exposed by commit 65565ca ("block: unify the synchronous bi_end_io callbacks"). By unifying and optimizing the synchronous I/O completion path, the timing and scheduling behavior of the block layer altered significantly. As a result, a highly-concurrent execution pipeline emerged where lo_release() can progress to __loop_clr_fd() and nullify lo->lo_backing_file while an already-scheduled asynchronous I/O work (lo_rw_aio) is just about to be executed by a kworker thread. Since the kworker enters lo_rw_aio() after lo->lo_backing_file has been cleared, it attempts to dereference the now-NULL pointer when initializing the kiocb, leading to the reported NULL pointer dereference bug. To close this race safely without introducing heavy fast-path checks, we must ensure that any running or scheduled dispatch threads have completed before we nullify the pointer. Since loop_queue_rq() operates within the block layer's RCU read-side critical section, invoke synchronize_rcu() and drain_workqueue() in __loop_clr_fd() prior to clearing lo->lo_backing_file. Reported-by: syzbot+cd8a9a308e879a4e2c28@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=cd8a9a308e879a4e2c28 Reported-by: syzbot+bc273027d5643e48e5b3@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=bc273027d5643e48e5b3 Analyzed-by: AI Mode in Google Search (no mail address) Signed-off-by: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
802627a to
198ffc2
Compare
Pull request for series with
subject: loop: Fix NULL pointer dereference by synchronizing lo_release and loop_queue_rq
version: 1
url: https://patchwork.kernel.org/project/linux-block/list/?series=1092734