diff options
author | Christian Brabandt <cb@256bit.org> | 2024-02-28 23:32:00 +0100 |
---|---|---|
committer | Christian Brabandt <cb@256bit.org> | 2024-02-28 23:32:00 +0100 |
commit | 55f8bba73be5f9c3a5a4d0d6c5f56e65f2c7d3fc (patch) | |
tree | a793a9f5c73a9e252ec61a23a0671a281c128958 /src/proto | |
parent | 0fdd18596f504774bc5993d029d68eecea827439 (diff) |
patch 9.1.0143: [security]: autocmd causes use-after-free in set_curbuf()v9.1.0143
Problem: [security]: autocmd cause use-after-free in set_curbuf()
(kawarimidoll)
Solution: check side-effect of BufLeave autocommand, when the number
of windows changed, close windows containing buffers that will
be wiped, if curbuf changed unexpectedly make sure b_nwindows
is decremented otherwise it cannot be wiped
set_curbuf() already makes some efforts to ensure the BufLeave
autocommands do not cause issues. However there are still 2 issues
that are not taken care of:
1) If a BufLeave autocommand opens a new window containing the same
buffer as that is going got be closed in close_buffer() a bit later,
we suddenly have another window open, containing a free'd buffer. So we
must check if the number of windows changed and if it does (and the
current buffer is going to be wiped (according to the 'bufhidden'
setting), let's immediately close all windows containing the current
buffer using close_windows()
2) If a BufLeave autocommand changes our current buffer (displays it in
the current window), buf->b_nwindow will be incremented. As part of
set_curbuf() we will however enter another buffer soon, which means, the
newly created curbuf will have b_nwindows still have set, even so the
buffer is no longer displayed in a window. This causes later problems,
because it will no longer be possible to wipe such a buffer. So just
before entering the final buffer, check if the curbuf changed when
calling the BufLeave autocommand and if it does (and curbuf is still
valid), decrement curbuf->b_nwindows.
Both issues can be verified using the provided test (however the second
issue only because such an impacted buffer won't be wiped, causing
futher issues in later tests).
fixes: #13839
closes: #14104
Signed-off-by: Christian Brabandt <cb@256bit.org>
Diffstat (limited to 'src/proto')
-rw-r--r-- | src/proto/window.pro | 1 |
1 files changed, 1 insertions, 0 deletions
diff --git a/src/proto/window.pro b/src/proto/window.pro index a91a51190b..e5c03969fb 100644 --- a/src/proto/window.pro +++ b/src/proto/window.pro @@ -96,4 +96,5 @@ int win_hasvertsplit(void); int get_win_number(win_T *wp, win_T *first_win); int get_tab_number(tabpage_T *tp); char *check_colorcolumn(win_T *wp); +int get_last_winid(void); /* vim: set ft=c : */ |