patch 9.1.1361: [security]: possible use-after-free when closing a buffer
Problem: [security]: Possible to open more windows into a closing
buffer without splitting, bypassing existing "b_locked_split"
checks and triggering use-after-free
Solution: Disallow switching to a closing buffer. Editing a closing
buffer (via ":edit", etc.) was fixed in v9.1.0764, but add an
error message and check just "b_locked_split", as "b_locked"
is necessary only when the buffer shouldn't be wiped, and may
be set for buffers that are in-use but not actually closing.
(Sean Dewar)
closes: #17246
Signed-off-by: Sean Dewar <6256228+seandewar@users.noreply.github.com>
Signed-off-by: Christian Brabandt <cb@256bit.org>
diff --git a/src/ex_cmds.c b/src/ex_cmds.c
index e1e6c4e..4eb67e3 100644
--- a/src/ex_cmds.c
+++ b/src/ex_cmds.c
@@ -2743,9 +2743,9 @@
}
if (buf == NULL)
goto theend;
- // autocommands try to edit a file that is going to be removed,
- // abort
- if (buf_locked(buf))
+ // autocommands try to edit a closing buffer, which like splitting, can
+ // result in more windows displaying it; abort
+ if (buf->b_locked_split)
{
// window was split, but not editing the new buffer,
// reset b_nwindows again
@@ -2753,6 +2753,7 @@
&& curwin->w_buffer != NULL
&& curwin->w_buffer->b_nwindows > 1)
--curwin->w_buffer->b_nwindows;
+ emsg(_(e_cannot_switch_to_a_closing_buffer));
goto theend;
}
if (curwin->w_alt_fnum == buf->b_fnum && prev_alt_fnum != 0)