view READMEdir/README_os390.txt @ 34454:f8fed6c8bb60 v9.1.0143

patch 9.1.0143: [security]: autocmd causes use-after-free in set_curbuf() Commit: https://github.com/vim/vim/commit/55f8bba73be5f9c3a5a4d0d6c5f56e65f2c7d3fc Author: Christian Brabandt <cb@256bit.org> Date: Wed Feb 28 23:32:00 2024 +0100 patch 9.1.0143: [security]: autocmd causes use-after-free in set_curbuf() 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>
author Christian Brabandt <cb@256bit.org>
date Wed, 28 Feb 2024 23:45:03 +0100
parents 4635e43f2c6f
children
line wrap: on
line source

README_os390.txt for version 9.1 of Vim: Vi IMproved.

This readme explains how to build Vim on z/OS.  Formerly called OS/390.
See "README.txt" for general information about Vim.

Most likely there are not many users out there using Vim on z/OS. So chances
are good, that some bugs are still undiscovered.

Getting the source to z/OS:
==========================

First get the source code in one big tar file and ftp it a binary to z/OS. If
the tar file is initially compressed with gzip (tar.gz) or bzip2 (tar.bz2)
uncompress it on your PC, as these tools are (most likely) not available on
the mainframe.

To reduce the size of the tar file you might compress it into a zip file. On
z/OS Unix you might have the command "jar" from java to uncompress a zip. Use:
        jar xvf <zip file name>

Unpack the tar file on z/OS with 
        pax -o from=ISO8859-1,to=IBM-1047 -rf vim.tar

Note: The Vim source contains a few bitmaps etc which will be destroyed by
this command, but these files are not needed on zOS (at least not for the
console version).


Compiling:
==========

Vim can be compiled with or without GUI support. For 7.4 only the compilation
without GUI was tested. Below is a section about compiling with X11 but this
is from an earlier version of Vim.

Console only:
-------------

If you build VIM without X11 support, compiling and building is nearly
straightforward. 

Change to the vim directory and do:

    # Don't use c89!
    # Allow intermixing of compiler options and files.

    $ export CC=cc
    $ export _CC_CCMODE=1
    $./configure --with-features=normal --without-x --enable-gui=no
    $ cd src
    $ make

      There may be warnings:
        - include files not found (libc, sys/param.h, ...)
        - Redeclaration of ... differs from ...
        -- just ignore them.

    $ make test

      This will produce lots of garbage on your screen (including error
      messages). Don't worry.

      If the test stops at one point in vim (might happen in test 11), just
      press :q!

      Expected test failures:
        11: If you don't have gzip installed
        24: test of backslash sequences in regexp are ASCII dependent
        42: Multibyte is not supported on z/OS
        55: ASCII<->EBCDIC sorting
        57: ASCII<->EBCDIC sorting
        58: Spell checking is not supported with EBCDIC
        71: Blowfish encryption doesn't work

    $ make install


With X11:
---------

WARNING: This instruction was not tested with Vim 7.4 or later.

There are two ways for building VIM with X11 support. The first way is simple
and results in a big executable (~13 Mb), the second needs a few additional
steps and results in a much smaller executable (~4.5 Mb). These examples
assume you want Motif.

  The easy way:
    $ export CC=cc
    $ export _CC_CCMODE=1
    $ ./configure --enable-max-features --enable-gui=motif
    $ cd src
    $ make

    With this VIM is linked statically with the X11 libraries.

  The smarter way:
    Make VIM as described above. Then create a file named 'link.sed' with the
    following content (see src/link.390):

	s/-lXext  *//g
	s/-lXmu  *//g
	s/-lXm	*/\/usr\/lib\/Xm.x /g
	s/-lX11  */\/usr\/lib\/X11.x /g
	s/-lXt	*//g
	s/-lSM	*/\/usr\/lib\/SM.x /g
	s/-lICE  */\/usr\/lib\/ICE.x /g

    Then do:
    $ rm vim
    $ make

    Now Vim is linked with the X11-DLLs.

    See the Makefile and the file link.sh on how link.sed is used.