Re: KASAN: use-after-free Read in cma_cancel_operation, rdma_listen
On Tue, Apr 13, 2021 at 10:19:25PM +0800, Hao Sun wrote: > Jason Gunthorpe 于2021年4月13日周二 下午9:45写道： > > > > On Tue, Apr 13, 2021 at 09:42:43PM +0800, Hao Sun wrote: > > > Jason Gunthorpe 于2021年4月13日周二 下午9:34写道： > > > > > > > > On Tue, Apr 13, 2021 at 11:36:41AM +0800, Hao Sun wrote: > > > > > Hi > > > > > > > > > > When using Healer(https://github.com/SunHao-0/healer/tree/dev) to fuzz > > > > > the Linux kernel, I found two use-after-free bugs which have been > > > > > reported a long time ago by Syzbot. > > > > > Although the corresponding patches have been merged into upstream, > > > > > these two bugs can still be triggered easily. > > > > > The original information about Syzbot report can be found here: > > > > > https://syzkaller.appspot.com/bug?id=8dc0bcd9dd6ec915ba10b3354740eb420884acaa > > > > > https://syzkaller.appspot.com/bug?id=95f89b8fb9fdc42e28ad586e657fea074e4e719b > > > > > > > > Then why hasn't syzbot seen this in a year's time? Seems strange > > > > > > > > > > Seems strange to me too, but the fact is that the reproduction program > > > in attachment can trigger these two bugs quickly. > > > > Do you have this in the C format? > > > > Just tried to use syz-prog2c to convert the repro-prog to C format. > The repro program of rdma_listen was successfully reproduced > (uploaded in attachment), the other one failed. it looks like > syz-prog2c may not be able to do the equivalent conversion. > You can use syz-execprog to execute the reprogram directly, this > method can reproduce both crashes, I have tried it. I tried this program and it reliably deadlocks my kernel :| So there is certainly something here Jason
Re: KASAN: use-after-free Read in cma_cancel_operation, rdma_listen
Jason Gunthorpe 于2021年4月13日周二 下午9:45写道：
>
> On Tue, Apr 13, 2021 at 09:42:43PM +0800, Hao Sun wrote:
> > Jason Gunthorpe 于2021年4月13日周二 下午9:34写道：
> > >
> > > On Tue, Apr 13, 2021 at 11:36:41AM +0800, Hao Sun wrote:
> > > > Hi
> > > >
> > > > When using Healer(https://github.com/SunHao-0/healer/tree/dev) to fuzz
> > > > the Linux kernel, I found two use-after-free bugs which have been
> > > > reported a long time ago by Syzbot.
> > > > Although the corresponding patches have been merged into upstream,
> > > > these two bugs can still be triggered easily.
> > > > The original information about Syzbot report can be found here:
> > > > https://syzkaller.appspot.com/bug?id=8dc0bcd9dd6ec915ba10b3354740eb420884acaa
> > > > https://syzkaller.appspot.com/bug?id=95f89b8fb9fdc42e28ad586e657fea074e4e719b
> > >
> > > Then why hasn't syzbot seen this in a year's time? Seems strange
> > >
> >
> > Seems strange to me too, but the fact is that the reproduction program
> > in attachment can trigger these two bugs quickly.
>
> Do you have this in the C format?
>
Just tried to use syz-prog2c to convert the repro-prog to C format.
The repro program of rdma_listen was successfully reproduced
(uploaded in attachment), the other one failed. it looks like
syz-prog2c may not be able to do the equivalent conversion.
You can use syz-execprog to execute the reprogram directly, this
method can reproduce both crashes, I have tried it.
For reproduction prog of cma_cancel_operation, using syz-execprog
can run this reproduction program directly:
./syz-execprog -threaded -repeat 0 -procs 2 -slowdown 1 -enable tun
-enable netdev -enable resetnet -enable cgroups -enable binfmt-misc
-enable close_fds -enable devlinkpci -enable usb -enable vhci -enable
wifi -enable ieee802154 -enable sysctl repro.prog
// autogenerated by syzkaller (https://github.com/google/syzkaller)
#define _GNU_SOURCE
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
static __thread int skip_segv;
static __thread jmp_buf segv_env;
static void segv_handler(int sig, siginfo_t* info, void* ctx)
{
uintptr_t addr = (uintptr_t)info->si_addr;
const uintptr_t prog_start = 1 << 20;
const uintptr_t prog_end = 100 << 20;
int skip = __atomic_load_n(_segv, __ATOMIC_RELAXED) != 0;
int valid = addr < prog_start || addr > prog_end;
if (skip && valid) {
_longjmp(segv_env, 1);
}
exit(sig);
}
static void install_segv_handler(void)
{
struct sigaction sa;
memset(, 0, sizeof(sa));
sa.sa_handler = SIG_IGN;
syscall(SYS_rt_sigaction, 0x20, , NULL, 8);
syscall(SYS_rt_sigaction, 0x21, , NULL, 8);
memset(, 0, sizeof(sa));
sa.sa_sigaction = segv_handler;
sa.sa_flags = SA_NODEFER | SA_SIGINFO;
sigaction(SIGSEGV, , NULL);
sigaction(SIGBUS, , NULL);
}
#define NONFAILING(...)\
({ \
int ok = 1;\
__atomic_fetch_add(_segv, 1, __ATOMIC_SEQ_CST); \
if (_setjmp(segv_env) == 0) { \
__VA_ARGS__; \
} else \
ok = 0; \
__atomic_fetch_sub(_segv, 1, __ATOMIC_SEQ_CST); \
ok;\
})
static void sleep_ms(uint64_t ms)
{
usleep(ms * 1000);
}
static uint64_t current_time_ms(void)
{
struct timespec ts;
if (clock_gettime(CLOCK_MONOTONIC, ))
exit(1);
return (uint64_t)ts.tv_sec * 1000 + (uint64_t)ts.tv_nsec / 100;
}
static void use_temporary_dir(void)
{
char tmpdir_template[] = "./syzkaller.XX";
char* tmpdir = mkdtemp(tmpdir_template);
if (!tmpdir)
exit(1);
if (chmod(tmpdir, 0777))
exit(1);
if (chdir(tmpdir))
exit(1);
}
static bool write_file(const char* file, const char* what, ...)
{
char buf[1024];
va_list args;
va_start(args, what);
vsnprintf(buf, sizeof(buf), what, args);
va_end(args);
buf[sizeof(buf) - 1] = 0;
int len = strlen(buf);
int fd = open(file, O_WRONLY | O_CLOEXEC);
if (fd == -1)
return false;
if (write(fd, buf, len) != len) {
int err = errno;
close(fd);
errno = err;
return false;
}
close(fd);
return true;
}
#define FS_IOC_SETFLAGS _IOW('f', 2, long)
static void remove_dir(const char* dir)
{
int iter = 0;
DIR* dp = 0;
retry:
while (umount2(dir, MNT_DETACH) == 0) {
}
dp = opendir(dir);
if (dp == NULL) {
if (errno == EMFILE) {
exit(1);
}
exit(1);
}
struct dirent* ep = 0;
while ((ep = readdir(dp))) {
if
Re: KASAN: use-after-free Read in cma_cancel_operation, rdma_listen
> On 13 Apr 2021, at 15:44, Jason Gunthorpe wrote: > > On Tue, Apr 13, 2021 at 09:42:43PM +0800, Hao Sun wrote: >> Jason Gunthorpe 于2021年4月13日周二 下午9:34写道： >>> >>> On Tue, Apr 13, 2021 at 11:36:41AM +0800, Hao Sun wrote: Hi When using Healer(https://github.com/SunHao-0/healer/tree/dev) to fuzz the Linux kernel, I found two use-after-free bugs which have been reported a long time ago by Syzbot. Although the corresponding patches have been merged into upstream, these two bugs can still be triggered easily. The original information about Syzbot report can be found here: https://syzkaller.appspot.com/bug?id=8dc0bcd9dd6ec915ba10b3354740eb420884acaa https://syzkaller.appspot.com/bug?id=95f89b8fb9fdc42e28ad586e657fea074e4e719b >>> >>> Then why hasn't syzbot seen this in a year's time? Seems strange >>> >> >> Seems strange to me too, but the fact is that the reproduction program >> in attachment can trigger these two bugs quickly. > > Do you have this in the C format? How can a commit changing arch m68k provoke a bug when running on x86_64? Håkon > > Jason
Re: KASAN: use-after-free Read in cma_cancel_operation, rdma_listen
On Tue, Apr 13, 2021 at 09:42:43PM +0800, Hao Sun wrote: > Jason Gunthorpe 于2021年4月13日周二 下午9:34写道： > > > > On Tue, Apr 13, 2021 at 11:36:41AM +0800, Hao Sun wrote: > > > Hi > > > > > > When using Healer(https://github.com/SunHao-0/healer/tree/dev) to fuzz > > > the Linux kernel, I found two use-after-free bugs which have been > > > reported a long time ago by Syzbot. > > > Although the corresponding patches have been merged into upstream, > > > these two bugs can still be triggered easily. > > > The original information about Syzbot report can be found here: > > > https://syzkaller.appspot.com/bug?id=8dc0bcd9dd6ec915ba10b3354740eb420884acaa > > > https://syzkaller.appspot.com/bug?id=95f89b8fb9fdc42e28ad586e657fea074e4e719b > > > > Then why hasn't syzbot seen this in a year's time? Seems strange > > > > Seems strange to me too, but the fact is that the reproduction program > in attachment can trigger these two bugs quickly. Do you have this in the C format? Jason
Re: KASAN: use-after-free Read in cma_cancel_operation, rdma_listen
Jason Gunthorpe 于2021年4月13日周二 下午9:34写道： > > On Tue, Apr 13, 2021 at 11:36:41AM +0800, Hao Sun wrote: > > Hi > > > > When using Healer(https://github.com/SunHao-0/healer/tree/dev) to fuzz > > the Linux kernel, I found two use-after-free bugs which have been > > reported a long time ago by Syzbot. > > Although the corresponding patches have been merged into upstream, > > these two bugs can still be triggered easily. > > The original information about Syzbot report can be found here: > > https://syzkaller.appspot.com/bug?id=8dc0bcd9dd6ec915ba10b3354740eb420884acaa > > https://syzkaller.appspot.com/bug?id=95f89b8fb9fdc42e28ad586e657fea074e4e719b > > Then why hasn't syzbot seen this in a year's time? Seems strange > Seems strange to me too, but the fact is that the reproduction program in attachment can trigger these two bugs quickly. > > Current report Information: > > commit: 89698becf06d341a700913c3d89ce2a914af69a2 > > What commit is this? The latest commit in the master branch, https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/
Re: KASAN: use-after-free Read in cma_cancel_operation, rdma_listen
On Tue, Apr 13, 2021 at 11:36:41AM +0800, Hao Sun wrote: > Hi > > When using Healer(https://github.com/SunHao-0/healer/tree/dev) to fuzz > the Linux kernel, I found two use-after-free bugs which have been > reported a long time ago by Syzbot. > Although the corresponding patches have been merged into upstream, > these two bugs can still be triggered easily. > The original information about Syzbot report can be found here: > https://syzkaller.appspot.com/bug?id=8dc0bcd9dd6ec915ba10b3354740eb420884acaa > https://syzkaller.appspot.com/bug?id=95f89b8fb9fdc42e28ad586e657fea074e4e719b Then why hasn't syzbot seen this in a year's time? Seems strange > Current report Information: > commit: 89698becf06d341a700913c3d89ce2a914af69a2 What commit is this? Jason
