lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-ID: <e9e943910710301745u429b14fj6c5a66fcbf6b0efa@mail.gmail.com>
Date:	Wed, 31 Oct 2007 00:45:35 +0000
From:	"Duane Griffin" <duaneg@...da.com>
To:	"linux-kernel Mailing List" <linux-kernel@...r.kernel.org>
Cc:	"Nick Piggin" <npiggin@...e.de>
Subject: 2.6.23 regression: accessing invalid mmap'ed memory from gdb causes unkillable spinning

Accessing a memory mapped region past the last page containing a valid
file mapping produces a SIGBUS fault (as it should). Running a program
that does this under gdb, then accessing the invalid memory from gdb,
causes it to start consuming 100% CPU and become unkillable. Once in
that state, SysRq-T doesn't show a stack trace for gdb, although it is
shown as running and stack traces are dumped for other tasks.

2.6.22 does not have this bug (gdb just prints '\0' as the contents,
although arguably that is also a bug, and it should instead report the
SIGBUS).

Bisection indicates the problem was introduced by:

54cb8821de07f2ffcd28c380ce9b93d5784b40d7
"mm: merge populate and nopage into fault (fixes nonlinear)"

The following program demonstrates the issue:

#include <errno.h>
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <fcntl.h>
#include <unistd.h>
#include <sys/mman.h>
#include <sys/stat.h>

int main(int argc, char *argv[])
{
        int fd;
        struct stat buf;

        if (argc != 2) {
                fprintf(stderr, "usage: %s <filename>\n", argv[0]);
                exit(1);
        }

        fd = open(argv[1], O_RDONLY);
        fstat(fd, &buf);
        int count = buf.st_size + sysconf(_SC_PAGE_SIZE);
        char *file = (char *) mmap(NULL, count, PROT_READ, MAP_PRIVATE, fd, 0);
        if (file == MAP_FAILED) {
                fprintf(stderr, "mmap failed: %s\n", strerror(errno));
        } else {
                char ch;
                fprintf(stderr, "using offset %d\n", (count - 1));
                ch = file[count - 1];
                munmap(file, count);
        }
        close(fd);
        return 0;
}

To reproduce the bug, run it under gdb, go up a couple of frames to
the main function, then access invalid memory, for e.g. with: "print
file[4095]", or whatever offset was reported.

Cheers,
Duane.

-- 
"I never could learn to drink that blood and call it wine" - Bob Dylan
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists