All of lore.kernel.org
 help / color / mirror / Atom feed
* KASAN: vmalloc-out-of-bounds Write in snd_pcm_hw_params
@ 2022-07-22 16:37 ` Dipanjan Das
  0 siblings, 0 replies; 18+ messages in thread
From: Dipanjan Das @ 2022-07-22 16:37 UTC (permalink / raw)
  To: perex, tiwai, gregkh, consult.awy, alsa-devel, linux-kernel
  Cc: syzkaller, fleischermarius, its.priyanka.bose

[-- Attachment #1: Type: text/plain, Size: 3455 bytes --]

Hi,

We would like to report the following bug which has been found by our
modified version of syzkaller.

======================================================
description: KASAN: vmalloc-out-of-bounds Write in snd_pcm_hw_params
affected file: sound/core/pcm_native.c
kernel version: 5.10.131
kernel commit: de62055f423f5dcb548f74cebd68f03c8903f73a
git tree: upstream
kernel config: https://syzkaller.appspot.com/x/.config?x=e49433cfed49b7d9
crash reproducer: attached
======================================================
Crash log:
======================================================
BUG: KASAN: vmalloc-out-of-bounds in memset include/linux/string.h:384 [inline]
BUG: KASAN: vmalloc-out-of-bounds in snd_pcm_hw_params+0x19b0/0x1db0
sound/core/pcm_native.c:799
Write of size 2097152 at addr ffffc900113b2000 by task syz-executor.5/14437

CPU: 1 PID: 14437 Comm: syz-executor.5 Tainted: G           OE     5.10.131+ #3
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS
1.13.0-1ubuntu1.1 04/01/2014
Call Trace:
 __dump_stack lib/dump_stack.c:77 [inline]
 dump_stack+0x107/0x163 lib/dump_stack.c:118
 print_address_description.constprop.0.cold+0x5/0x4f7 mm/kasan/report.c:385
 __kasan_report mm/kasan/report.c:545 [inline]
 kasan_report.cold+0x1f/0x37 mm/kasan/report.c:562
 check_memory_region_inline mm/kasan/generic.c:194 [inline]
 check_memory_region+0x187/0x1e0 mm/kasan/generic.c:200
 memset+0x20/0x40 mm/kasan/common.c:85
 memset include/linux/string.h:384 [inline]
 snd_pcm_hw_params+0x19b0/0x1db0 sound/core/pcm_native.c:799
 snd_pcm_kernel_ioctl+0xd1/0x240 sound/core/pcm_native.c:3401
 snd_pcm_oss_change_params_locked+0x17b6/0x3aa0 sound/core/oss/pcm_oss.c:965
 snd_pcm_oss_change_params+0x76/0xd0 sound/core/oss/pcm_oss.c:1107
 snd_pcm_oss_make_ready+0xb7/0x170 sound/core/oss/pcm_oss.c:1166
 snd_pcm_oss_set_trigger.isra.0+0x34f/0x770 sound/core/oss/pcm_oss.c:2074
 snd_pcm_oss_poll+0x679/0xb40 sound/core/oss/pcm_oss.c:2858
 vfs_poll include/linux/poll.h:90 [inline]
 do_pollfd fs/select.c:872 [inline]
 do_poll fs/select.c:920 [inline]
 do_sys_poll+0x63c/0xe40 fs/select.c:1014
 __do_sys_poll fs/select.c:1079 [inline]
 __se_sys_poll fs/select.c:1067 [inline]
 __x64_sys_poll+0x18c/0x490 fs/select.c:1067
 do_syscall_64+0x2d/0x70 arch/x86/entry/common.c:46
 entry_SYSCALL_64_after_hwframe+0x44/0xa9
RIP: 0033:0x7f095de4f4ed
Code: 02 b8 ff ff ff ff c3 66 0f 1f 44 00 00 f3 0f 1e fa 48 89 f8 48
89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d
01 f0 ff ff 73 01 c3 48 c7 c1 b8 ff ff ff f7 d8 64 89 01 48
RSP: 002b:00007f095bdffbe8 EFLAGS: 00000246 ORIG_RAX: 0000000000000007
RAX: ffffffffffffffda RBX: 00007f095df6df60 RCX: 00007f095de4f4ed
RDX: 0000000000000009 RSI: 0000000000000001 RDI: 00000000200000c0
RBP: 00007f095bdffc40 R08: 0000000000000000 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000246 R12: 000000000000001d
R13: 00007ffff286ceff R14: 00007f095df6df60 R15: 00007f095bdffd80


Memory state around the buggy address:
 ffffc900115b1d00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
 ffffc900115b1d80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
>ffffc900115b1e00: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8
                   ^
 ffffc900115b1e80: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8
 ffffc900115b1f00: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8
==================================================================

-- 
Thanks and Regards,

Dipanjan

[-- Attachment #2: repro.syz --]
[-- Type: application/octet-stream, Size: 123 bytes --]

r0 = openat$adsp1(0xffffffffffffff9c, &(0x7f0000000040), 0x0, 0x0)
poll(&(0x7f00000000c0)=[{r0}], 0x1, 0x9) (fail_nth: 11)

[-- Attachment #3: repro.c --]
[-- Type: text/x-csrc, Size: 8786 bytes --]

// autogenerated by syzkaller (https://github.com/google/syzkaller)

#define _GNU_SOURCE 

#include <arpa/inet.h>
#include <endian.h>
#include <errno.h>
#include <fcntl.h>
#include <net/if.h>
#include <netinet/in.h>
#include <stdarg.h>
#include <stdbool.h>
#include <stdint.h>
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <sys/socket.h>
#include <sys/stat.h>
#include <sys/syscall.h>
#include <sys/types.h>
#include <unistd.h>

#include <linux/genetlink.h>
#include <linux/if_addr.h>
#include <linux/if_link.h>
#include <linux/in6.h>
#include <linux/neighbour.h>
#include <linux/net.h>
#include <linux/netlink.h>
#include <linux/rtnetlink.h>
#include <linux/veth.h>

static void use_temporary_dir(void)
{
	char tmpdir_template[] = "./syzkaller.XXXXXX";
	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;
}

struct nlmsg {
	char* pos;
	int nesting;
	struct nlattr* nested[8];
	char buf[4096];
};

static void netlink_init(struct nlmsg* nlmsg, int typ, int flags,
			 const void* data, int size)
{
	memset(nlmsg, 0, sizeof(*nlmsg));
	struct nlmsghdr* hdr = (struct nlmsghdr*)nlmsg->buf;
	hdr->nlmsg_type = typ;
	hdr->nlmsg_flags = NLM_F_REQUEST | NLM_F_ACK | flags;
	memcpy(hdr + 1, data, size);
	nlmsg->pos = (char*)(hdr + 1) + NLMSG_ALIGN(size);
}

static void netlink_attr(struct nlmsg* nlmsg, int typ,
			 const void* data, int size)
{
	struct nlattr* attr = (struct nlattr*)nlmsg->pos;
	attr->nla_len = sizeof(*attr) + size;
	attr->nla_type = typ;
	if (size > 0)
		memcpy(attr + 1, data, size);
	nlmsg->pos += NLMSG_ALIGN(attr->nla_len);
}

static void netlink_nest(struct nlmsg* nlmsg, int typ)
{
	struct nlattr* attr = (struct nlattr*)nlmsg->pos;
	attr->nla_type = typ;
	nlmsg->pos += sizeof(*attr);
	nlmsg->nested[nlmsg->nesting++] = attr;
}

static void netlink_done(struct nlmsg* nlmsg)
{
	struct nlattr* attr = nlmsg->nested[--nlmsg->nesting];
	attr->nla_len = nlmsg->pos - (char*)attr;
}

static int netlink_send_ext(struct nlmsg* nlmsg, int sock,
			    uint16_t reply_type, int* reply_len, bool dofail)
{
	if (nlmsg->pos > nlmsg->buf + sizeof(nlmsg->buf) || nlmsg->nesting)
	exit(1);
	struct nlmsghdr* hdr = (struct nlmsghdr*)nlmsg->buf;
	hdr->nlmsg_len = nlmsg->pos - nlmsg->buf;
	struct sockaddr_nl addr;
	memset(&addr, 0, sizeof(addr));
	addr.nl_family = AF_NETLINK;
	ssize_t n = sendto(sock, nlmsg->buf, hdr->nlmsg_len, 0, (struct sockaddr*)&addr, sizeof(addr));
	if (n != (ssize_t)hdr->nlmsg_len) {
		if (dofail)
	exit(1);
		return -1;
	}
	n = recv(sock, nlmsg->buf, sizeof(nlmsg->buf), 0);
	if (reply_len)
		*reply_len = 0;
	if (n < 0) {
		if (dofail)
	exit(1);
		return -1;
	}
	if (n < (ssize_t)sizeof(struct nlmsghdr)) {
		errno = EINVAL;
		if (dofail)
	exit(1);
		return -1;
	}
	if (hdr->nlmsg_type == NLMSG_DONE)
		return 0;
	if (reply_len && hdr->nlmsg_type == reply_type) {
		*reply_len = n;
		return 0;
	}
	if (n < (ssize_t)(sizeof(struct nlmsghdr) + sizeof(struct nlmsgerr))) {
		errno = EINVAL;
		if (dofail)
	exit(1);
		return -1;
	}
	if (hdr->nlmsg_type != NLMSG_ERROR) {
		errno = EINVAL;
		if (dofail)
	exit(1);
		return -1;
	}
	errno = -((struct nlmsgerr*)(hdr + 1))->error;
	return -errno;
}

static int netlink_send(struct nlmsg* nlmsg, int sock)
{
	return netlink_send_ext(nlmsg, sock, 0, NULL, true);
}

static int netlink_query_family_id(struct nlmsg* nlmsg, int sock, const char* family_name, bool dofail)
{
	struct genlmsghdr genlhdr;
	memset(&genlhdr, 0, sizeof(genlhdr));
	genlhdr.cmd = CTRL_CMD_GETFAMILY;
	netlink_init(nlmsg, GENL_ID_CTRL, 0, &genlhdr, sizeof(genlhdr));
	netlink_attr(nlmsg, CTRL_ATTR_FAMILY_NAME, family_name, strnlen(family_name, GENL_NAMSIZ - 1) + 1);
	int n = 0;
	int err = netlink_send_ext(nlmsg, sock, GENL_ID_CTRL, &n, dofail);
	if (err < 0) {
		return -1;
	}
	uint16_t id = 0;
	struct nlattr* attr = (struct nlattr*)(nlmsg->buf + NLMSG_HDRLEN + NLMSG_ALIGN(sizeof(genlhdr)));
	for (; (char*)attr < nlmsg->buf + n; attr = (struct nlattr*)((char*)attr + NLMSG_ALIGN(attr->nla_len))) {
		if (attr->nla_type == CTRL_ATTR_FAMILY_ID) {
			id = *(uint16_t*)(attr + 1);
			break;
		}
	}
	if (!id) {
		errno = EINVAL;
		return -1;
	}
	recv(sock, nlmsg->buf, sizeof(nlmsg->buf), 0);
	return id;
}

static void netlink_add_device_impl(struct nlmsg* nlmsg, const char* type,
				    const char* name)
{
	struct ifinfomsg hdr;
	memset(&hdr, 0, sizeof(hdr));
	netlink_init(nlmsg, RTM_NEWLINK, NLM_F_EXCL | NLM_F_CREATE, &hdr, sizeof(hdr));
	if (name)
		netlink_attr(nlmsg, IFLA_IFNAME, name, strlen(name));
	netlink_nest(nlmsg, IFLA_LINKINFO);
	netlink_attr(nlmsg, IFLA_INFO_KIND, type, strlen(type));
}

static void netlink_device_change(struct nlmsg* nlmsg, int sock, const char* name, bool up,
				  const char* master, const void* mac, int macsize,
				  const char* new_name)
{
	struct ifinfomsg hdr;
	memset(&hdr, 0, sizeof(hdr));
	if (up)
		hdr.ifi_flags = hdr.ifi_change = IFF_UP;
	hdr.ifi_index = if_nametoindex(name);
	netlink_init(nlmsg, RTM_NEWLINK, 0, &hdr, sizeof(hdr));
	if (new_name)
		netlink_attr(nlmsg, IFLA_IFNAME, new_name, strlen(new_name));
	if (master) {
		int ifindex = if_nametoindex(master);
		netlink_attr(nlmsg, IFLA_MASTER, &ifindex, sizeof(ifindex));
	}
	if (macsize)
		netlink_attr(nlmsg, IFLA_ADDRESS, mac, macsize);
	int err = netlink_send(nlmsg, sock);
	if (err < 0) {
	}
}

static struct nlmsg nlmsg;

static int inject_fault(int nth)
{
	int fd;
	fd = open("/proc/thread-self/fail-nth", O_RDWR);
	if (fd == -1)
	exit(1);
	char buf[16];
	sprintf(buf, "%d", nth);
	if (write(fd, buf, strlen(buf)) != (ssize_t)strlen(buf))
	exit(1);
	return fd;
}

static void setup_fault()
{
	static struct {
		const char* file;
		const char* val;
		bool fatal;
	} files[] = {
	    {"/sys/kernel/debug/failslab/ignore-gfp-wait", "N", true},
	    {"/sys/kernel/debug/fail_futex/ignore-private", "N", false},
	    {"/sys/kernel/debug/fail_page_alloc/ignore-gfp-highmem", "N", false},
	    {"/sys/kernel/debug/fail_page_alloc/ignore-gfp-wait", "N", false},
	    {"/sys/kernel/debug/fail_page_alloc/min-order", "0", false},
	};
	unsigned i;
	for (i = 0; i < sizeof(files) / sizeof(files[0]); i++) {
		if (!write_file(files[i].file, files[i].val)) {
			if (files[i].fatal)
	exit(1);
		}
	}
}

#define NL802154_CMD_SET_SHORT_ADDR 11
#define NL802154_ATTR_IFINDEX 3
#define NL802154_ATTR_SHORT_ADDR 10

static void setup_802154()
{
	int sock_route = socket(AF_NETLINK, SOCK_RAW, NETLINK_ROUTE);
	if (sock_route == -1)
	exit(1);
	int sock_generic = socket(AF_NETLINK, SOCK_RAW, NETLINK_GENERIC);
	if (sock_generic < 0)
	exit(1);
	int nl802154_family_id = netlink_query_family_id(&nlmsg, sock_generic, "nl802154", true);
	for (int i = 0; i < 2; i++) {
		char devname[] = "wpan0";
		devname[strlen(devname) - 1] += i;
		uint64_t hwaddr = 0xaaaaaaaaaaaa0002 + (i << 8);
		uint16_t shortaddr = 0xaaa0 + i;
		int ifindex = if_nametoindex(devname);
		struct genlmsghdr genlhdr;
		memset(&genlhdr, 0, sizeof(genlhdr));
		genlhdr.cmd = NL802154_CMD_SET_SHORT_ADDR;
		netlink_init(&nlmsg, nl802154_family_id, 0, &genlhdr, sizeof(genlhdr));
		netlink_attr(&nlmsg, NL802154_ATTR_IFINDEX, &ifindex, sizeof(ifindex));
		netlink_attr(&nlmsg, NL802154_ATTR_SHORT_ADDR, &shortaddr, sizeof(shortaddr));
		int err = netlink_send(&nlmsg, sock_generic);
		if (err < 0) {
		}
		netlink_device_change(&nlmsg, sock_route, devname, true, 0, &hwaddr, sizeof(hwaddr), 0);
		if (i == 0) {
			netlink_add_device_impl(&nlmsg, "lowpan", "lowpan0");
			netlink_done(&nlmsg);
			netlink_attr(&nlmsg, IFLA_LINK, &ifindex, sizeof(ifindex));
			int err = netlink_send(&nlmsg, sock_route);
			if (err < 0) {
			}
		}
	}
	close(sock_route);
	close(sock_generic);
}

uint64_t r[1] = {0xffffffffffffffff};

int main(void)
{
		syscall(__NR_mmap, 0x1ffff000ul, 0x1000ul, 0ul, 0x32ul, -1, 0ul);
	syscall(__NR_mmap, 0x20000000ul, 0x1000000ul, 7ul, 0x32ul, -1, 0ul);
	syscall(__NR_mmap, 0x21000000ul, 0x1000ul, 0ul, 0x32ul, -1, 0ul);
	setup_fault();
	setup_802154();
			use_temporary_dir();
				intptr_t res = 0;
memcpy((void*)0x20000040, "/dev/adsp1\000", 11);
	res = syscall(__NR_openat, 0xffffffffffffff9cul, 0x20000040ul, 0ul, 0ul);
	if (res != -1)
		r[0] = res;
*(uint32_t*)0x200000c0 = r[0];
*(uint16_t*)0x200000c4 = 0;
*(uint16_t*)0x200000c6 = 0;
	inject_fault(11);
	syscall(__NR_poll, 0x200000c0ul, 1ul, 9);
	return 0;
}

^ permalink raw reply	[flat|nested] 18+ messages in thread

* KASAN: vmalloc-out-of-bounds Write in snd_pcm_hw_params
@ 2022-07-22 16:37 ` Dipanjan Das
  0 siblings, 0 replies; 18+ messages in thread
From: Dipanjan Das @ 2022-07-22 16:37 UTC (permalink / raw)
  To: perex, tiwai, gregkh, consult.awy, alsa-devel, linux-kernel
  Cc: fleischermarius, syzkaller, its.priyanka.bose

[-- Attachment #1: Type: text/plain, Size: 3455 bytes --]

Hi,

We would like to report the following bug which has been found by our
modified version of syzkaller.

======================================================
description: KASAN: vmalloc-out-of-bounds Write in snd_pcm_hw_params
affected file: sound/core/pcm_native.c
kernel version: 5.10.131
kernel commit: de62055f423f5dcb548f74cebd68f03c8903f73a
git tree: upstream
kernel config: https://syzkaller.appspot.com/x/.config?x=e49433cfed49b7d9
crash reproducer: attached
======================================================
Crash log:
======================================================
BUG: KASAN: vmalloc-out-of-bounds in memset include/linux/string.h:384 [inline]
BUG: KASAN: vmalloc-out-of-bounds in snd_pcm_hw_params+0x19b0/0x1db0
sound/core/pcm_native.c:799
Write of size 2097152 at addr ffffc900113b2000 by task syz-executor.5/14437

CPU: 1 PID: 14437 Comm: syz-executor.5 Tainted: G           OE     5.10.131+ #3
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS
1.13.0-1ubuntu1.1 04/01/2014
Call Trace:
 __dump_stack lib/dump_stack.c:77 [inline]
 dump_stack+0x107/0x163 lib/dump_stack.c:118
 print_address_description.constprop.0.cold+0x5/0x4f7 mm/kasan/report.c:385
 __kasan_report mm/kasan/report.c:545 [inline]
 kasan_report.cold+0x1f/0x37 mm/kasan/report.c:562
 check_memory_region_inline mm/kasan/generic.c:194 [inline]
 check_memory_region+0x187/0x1e0 mm/kasan/generic.c:200
 memset+0x20/0x40 mm/kasan/common.c:85
 memset include/linux/string.h:384 [inline]
 snd_pcm_hw_params+0x19b0/0x1db0 sound/core/pcm_native.c:799
 snd_pcm_kernel_ioctl+0xd1/0x240 sound/core/pcm_native.c:3401
 snd_pcm_oss_change_params_locked+0x17b6/0x3aa0 sound/core/oss/pcm_oss.c:965
 snd_pcm_oss_change_params+0x76/0xd0 sound/core/oss/pcm_oss.c:1107
 snd_pcm_oss_make_ready+0xb7/0x170 sound/core/oss/pcm_oss.c:1166
 snd_pcm_oss_set_trigger.isra.0+0x34f/0x770 sound/core/oss/pcm_oss.c:2074
 snd_pcm_oss_poll+0x679/0xb40 sound/core/oss/pcm_oss.c:2858
 vfs_poll include/linux/poll.h:90 [inline]
 do_pollfd fs/select.c:872 [inline]
 do_poll fs/select.c:920 [inline]
 do_sys_poll+0x63c/0xe40 fs/select.c:1014
 __do_sys_poll fs/select.c:1079 [inline]
 __se_sys_poll fs/select.c:1067 [inline]
 __x64_sys_poll+0x18c/0x490 fs/select.c:1067
 do_syscall_64+0x2d/0x70 arch/x86/entry/common.c:46
 entry_SYSCALL_64_after_hwframe+0x44/0xa9
RIP: 0033:0x7f095de4f4ed
Code: 02 b8 ff ff ff ff c3 66 0f 1f 44 00 00 f3 0f 1e fa 48 89 f8 48
89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d
01 f0 ff ff 73 01 c3 48 c7 c1 b8 ff ff ff f7 d8 64 89 01 48
RSP: 002b:00007f095bdffbe8 EFLAGS: 00000246 ORIG_RAX: 0000000000000007
RAX: ffffffffffffffda RBX: 00007f095df6df60 RCX: 00007f095de4f4ed
RDX: 0000000000000009 RSI: 0000000000000001 RDI: 00000000200000c0
RBP: 00007f095bdffc40 R08: 0000000000000000 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000246 R12: 000000000000001d
R13: 00007ffff286ceff R14: 00007f095df6df60 R15: 00007f095bdffd80


Memory state around the buggy address:
 ffffc900115b1d00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
 ffffc900115b1d80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
>ffffc900115b1e00: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8
                   ^
 ffffc900115b1e80: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8
 ffffc900115b1f00: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8
==================================================================

-- 
Thanks and Regards,

Dipanjan

[-- Attachment #2: repro.syz --]
[-- Type: application/octet-stream, Size: 123 bytes --]

r0 = openat$adsp1(0xffffffffffffff9c, &(0x7f0000000040), 0x0, 0x0)
poll(&(0x7f00000000c0)=[{r0}], 0x1, 0x9) (fail_nth: 11)

[-- Attachment #3: repro.c --]
[-- Type: text/x-csrc, Size: 8786 bytes --]

// autogenerated by syzkaller (https://github.com/google/syzkaller)

#define _GNU_SOURCE 

#include <arpa/inet.h>
#include <endian.h>
#include <errno.h>
#include <fcntl.h>
#include <net/if.h>
#include <netinet/in.h>
#include <stdarg.h>
#include <stdbool.h>
#include <stdint.h>
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <sys/socket.h>
#include <sys/stat.h>
#include <sys/syscall.h>
#include <sys/types.h>
#include <unistd.h>

#include <linux/genetlink.h>
#include <linux/if_addr.h>
#include <linux/if_link.h>
#include <linux/in6.h>
#include <linux/neighbour.h>
#include <linux/net.h>
#include <linux/netlink.h>
#include <linux/rtnetlink.h>
#include <linux/veth.h>

static void use_temporary_dir(void)
{
	char tmpdir_template[] = "./syzkaller.XXXXXX";
	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;
}

struct nlmsg {
	char* pos;
	int nesting;
	struct nlattr* nested[8];
	char buf[4096];
};

static void netlink_init(struct nlmsg* nlmsg, int typ, int flags,
			 const void* data, int size)
{
	memset(nlmsg, 0, sizeof(*nlmsg));
	struct nlmsghdr* hdr = (struct nlmsghdr*)nlmsg->buf;
	hdr->nlmsg_type = typ;
	hdr->nlmsg_flags = NLM_F_REQUEST | NLM_F_ACK | flags;
	memcpy(hdr + 1, data, size);
	nlmsg->pos = (char*)(hdr + 1) + NLMSG_ALIGN(size);
}

static void netlink_attr(struct nlmsg* nlmsg, int typ,
			 const void* data, int size)
{
	struct nlattr* attr = (struct nlattr*)nlmsg->pos;
	attr->nla_len = sizeof(*attr) + size;
	attr->nla_type = typ;
	if (size > 0)
		memcpy(attr + 1, data, size);
	nlmsg->pos += NLMSG_ALIGN(attr->nla_len);
}

static void netlink_nest(struct nlmsg* nlmsg, int typ)
{
	struct nlattr* attr = (struct nlattr*)nlmsg->pos;
	attr->nla_type = typ;
	nlmsg->pos += sizeof(*attr);
	nlmsg->nested[nlmsg->nesting++] = attr;
}

static void netlink_done(struct nlmsg* nlmsg)
{
	struct nlattr* attr = nlmsg->nested[--nlmsg->nesting];
	attr->nla_len = nlmsg->pos - (char*)attr;
}

static int netlink_send_ext(struct nlmsg* nlmsg, int sock,
			    uint16_t reply_type, int* reply_len, bool dofail)
{
	if (nlmsg->pos > nlmsg->buf + sizeof(nlmsg->buf) || nlmsg->nesting)
	exit(1);
	struct nlmsghdr* hdr = (struct nlmsghdr*)nlmsg->buf;
	hdr->nlmsg_len = nlmsg->pos - nlmsg->buf;
	struct sockaddr_nl addr;
	memset(&addr, 0, sizeof(addr));
	addr.nl_family = AF_NETLINK;
	ssize_t n = sendto(sock, nlmsg->buf, hdr->nlmsg_len, 0, (struct sockaddr*)&addr, sizeof(addr));
	if (n != (ssize_t)hdr->nlmsg_len) {
		if (dofail)
	exit(1);
		return -1;
	}
	n = recv(sock, nlmsg->buf, sizeof(nlmsg->buf), 0);
	if (reply_len)
		*reply_len = 0;
	if (n < 0) {
		if (dofail)
	exit(1);
		return -1;
	}
	if (n < (ssize_t)sizeof(struct nlmsghdr)) {
		errno = EINVAL;
		if (dofail)
	exit(1);
		return -1;
	}
	if (hdr->nlmsg_type == NLMSG_DONE)
		return 0;
	if (reply_len && hdr->nlmsg_type == reply_type) {
		*reply_len = n;
		return 0;
	}
	if (n < (ssize_t)(sizeof(struct nlmsghdr) + sizeof(struct nlmsgerr))) {
		errno = EINVAL;
		if (dofail)
	exit(1);
		return -1;
	}
	if (hdr->nlmsg_type != NLMSG_ERROR) {
		errno = EINVAL;
		if (dofail)
	exit(1);
		return -1;
	}
	errno = -((struct nlmsgerr*)(hdr + 1))->error;
	return -errno;
}

static int netlink_send(struct nlmsg* nlmsg, int sock)
{
	return netlink_send_ext(nlmsg, sock, 0, NULL, true);
}

static int netlink_query_family_id(struct nlmsg* nlmsg, int sock, const char* family_name, bool dofail)
{
	struct genlmsghdr genlhdr;
	memset(&genlhdr, 0, sizeof(genlhdr));
	genlhdr.cmd = CTRL_CMD_GETFAMILY;
	netlink_init(nlmsg, GENL_ID_CTRL, 0, &genlhdr, sizeof(genlhdr));
	netlink_attr(nlmsg, CTRL_ATTR_FAMILY_NAME, family_name, strnlen(family_name, GENL_NAMSIZ - 1) + 1);
	int n = 0;
	int err = netlink_send_ext(nlmsg, sock, GENL_ID_CTRL, &n, dofail);
	if (err < 0) {
		return -1;
	}
	uint16_t id = 0;
	struct nlattr* attr = (struct nlattr*)(nlmsg->buf + NLMSG_HDRLEN + NLMSG_ALIGN(sizeof(genlhdr)));
	for (; (char*)attr < nlmsg->buf + n; attr = (struct nlattr*)((char*)attr + NLMSG_ALIGN(attr->nla_len))) {
		if (attr->nla_type == CTRL_ATTR_FAMILY_ID) {
			id = *(uint16_t*)(attr + 1);
			break;
		}
	}
	if (!id) {
		errno = EINVAL;
		return -1;
	}
	recv(sock, nlmsg->buf, sizeof(nlmsg->buf), 0);
	return id;
}

static void netlink_add_device_impl(struct nlmsg* nlmsg, const char* type,
				    const char* name)
{
	struct ifinfomsg hdr;
	memset(&hdr, 0, sizeof(hdr));
	netlink_init(nlmsg, RTM_NEWLINK, NLM_F_EXCL | NLM_F_CREATE, &hdr, sizeof(hdr));
	if (name)
		netlink_attr(nlmsg, IFLA_IFNAME, name, strlen(name));
	netlink_nest(nlmsg, IFLA_LINKINFO);
	netlink_attr(nlmsg, IFLA_INFO_KIND, type, strlen(type));
}

static void netlink_device_change(struct nlmsg* nlmsg, int sock, const char* name, bool up,
				  const char* master, const void* mac, int macsize,
				  const char* new_name)
{
	struct ifinfomsg hdr;
	memset(&hdr, 0, sizeof(hdr));
	if (up)
		hdr.ifi_flags = hdr.ifi_change = IFF_UP;
	hdr.ifi_index = if_nametoindex(name);
	netlink_init(nlmsg, RTM_NEWLINK, 0, &hdr, sizeof(hdr));
	if (new_name)
		netlink_attr(nlmsg, IFLA_IFNAME, new_name, strlen(new_name));
	if (master) {
		int ifindex = if_nametoindex(master);
		netlink_attr(nlmsg, IFLA_MASTER, &ifindex, sizeof(ifindex));
	}
	if (macsize)
		netlink_attr(nlmsg, IFLA_ADDRESS, mac, macsize);
	int err = netlink_send(nlmsg, sock);
	if (err < 0) {
	}
}

static struct nlmsg nlmsg;

static int inject_fault(int nth)
{
	int fd;
	fd = open("/proc/thread-self/fail-nth", O_RDWR);
	if (fd == -1)
	exit(1);
	char buf[16];
	sprintf(buf, "%d", nth);
	if (write(fd, buf, strlen(buf)) != (ssize_t)strlen(buf))
	exit(1);
	return fd;
}

static void setup_fault()
{
	static struct {
		const char* file;
		const char* val;
		bool fatal;
	} files[] = {
	    {"/sys/kernel/debug/failslab/ignore-gfp-wait", "N", true},
	    {"/sys/kernel/debug/fail_futex/ignore-private", "N", false},
	    {"/sys/kernel/debug/fail_page_alloc/ignore-gfp-highmem", "N", false},
	    {"/sys/kernel/debug/fail_page_alloc/ignore-gfp-wait", "N", false},
	    {"/sys/kernel/debug/fail_page_alloc/min-order", "0", false},
	};
	unsigned i;
	for (i = 0; i < sizeof(files) / sizeof(files[0]); i++) {
		if (!write_file(files[i].file, files[i].val)) {
			if (files[i].fatal)
	exit(1);
		}
	}
}

#define NL802154_CMD_SET_SHORT_ADDR 11
#define NL802154_ATTR_IFINDEX 3
#define NL802154_ATTR_SHORT_ADDR 10

static void setup_802154()
{
	int sock_route = socket(AF_NETLINK, SOCK_RAW, NETLINK_ROUTE);
	if (sock_route == -1)
	exit(1);
	int sock_generic = socket(AF_NETLINK, SOCK_RAW, NETLINK_GENERIC);
	if (sock_generic < 0)
	exit(1);
	int nl802154_family_id = netlink_query_family_id(&nlmsg, sock_generic, "nl802154", true);
	for (int i = 0; i < 2; i++) {
		char devname[] = "wpan0";
		devname[strlen(devname) - 1] += i;
		uint64_t hwaddr = 0xaaaaaaaaaaaa0002 + (i << 8);
		uint16_t shortaddr = 0xaaa0 + i;
		int ifindex = if_nametoindex(devname);
		struct genlmsghdr genlhdr;
		memset(&genlhdr, 0, sizeof(genlhdr));
		genlhdr.cmd = NL802154_CMD_SET_SHORT_ADDR;
		netlink_init(&nlmsg, nl802154_family_id, 0, &genlhdr, sizeof(genlhdr));
		netlink_attr(&nlmsg, NL802154_ATTR_IFINDEX, &ifindex, sizeof(ifindex));
		netlink_attr(&nlmsg, NL802154_ATTR_SHORT_ADDR, &shortaddr, sizeof(shortaddr));
		int err = netlink_send(&nlmsg, sock_generic);
		if (err < 0) {
		}
		netlink_device_change(&nlmsg, sock_route, devname, true, 0, &hwaddr, sizeof(hwaddr), 0);
		if (i == 0) {
			netlink_add_device_impl(&nlmsg, "lowpan", "lowpan0");
			netlink_done(&nlmsg);
			netlink_attr(&nlmsg, IFLA_LINK, &ifindex, sizeof(ifindex));
			int err = netlink_send(&nlmsg, sock_route);
			if (err < 0) {
			}
		}
	}
	close(sock_route);
	close(sock_generic);
}

uint64_t r[1] = {0xffffffffffffffff};

int main(void)
{
		syscall(__NR_mmap, 0x1ffff000ul, 0x1000ul, 0ul, 0x32ul, -1, 0ul);
	syscall(__NR_mmap, 0x20000000ul, 0x1000000ul, 7ul, 0x32ul, -1, 0ul);
	syscall(__NR_mmap, 0x21000000ul, 0x1000ul, 0ul, 0x32ul, -1, 0ul);
	setup_fault();
	setup_802154();
			use_temporary_dir();
				intptr_t res = 0;
memcpy((void*)0x20000040, "/dev/adsp1\000", 11);
	res = syscall(__NR_openat, 0xffffffffffffff9cul, 0x20000040ul, 0ul, 0ul);
	if (res != -1)
		r[0] = res;
*(uint32_t*)0x200000c0 = r[0];
*(uint16_t*)0x200000c4 = 0;
*(uint16_t*)0x200000c6 = 0;
	inject_fault(11);
	syscall(__NR_poll, 0x200000c0ul, 1ul, 9);
	return 0;
}

^ permalink raw reply	[flat|nested] 18+ messages in thread

* Re: KASAN: vmalloc-out-of-bounds Write in snd_pcm_hw_params
  2022-07-22 16:37 ` Dipanjan Das
@ 2022-07-23  7:00   ` Greg KH
  -1 siblings, 0 replies; 18+ messages in thread
From: Greg KH @ 2022-07-23  7:00 UTC (permalink / raw)
  To: Dipanjan Das
  Cc: perex, tiwai, consult.awy, alsa-devel, linux-kernel, syzkaller,
	fleischermarius, its.priyanka.bose

On Fri, Jul 22, 2022 at 09:37:52AM -0700, Dipanjan Das wrote:
> Hi,
> 
> We would like to report the following bug which has been found by our
> modified version of syzkaller.
> 
> ======================================================
> description: KASAN: vmalloc-out-of-bounds Write in snd_pcm_hw_params
> affected file: sound/core/pcm_native.c
> kernel version: 5.10.131
> kernel commit: de62055f423f5dcb548f74cebd68f03c8903f73a
> git tree: upstream
> kernel config: https://syzkaller.appspot.com/x/.config?x=e49433cfed49b7d9
> crash reproducer: attached
> ======================================================
> Crash log:
> ======================================================
> BUG: KASAN: vmalloc-out-of-bounds in memset include/linux/string.h:384 [inline]
> BUG: KASAN: vmalloc-out-of-bounds in snd_pcm_hw_params+0x19b0/0x1db0
> sound/core/pcm_native.c:799
> Write of size 2097152 at addr ffffc900113b2000 by task syz-executor.5/14437
> 
> CPU: 1 PID: 14437 Comm: syz-executor.5 Tainted: G           OE     5.10.131+ #3
> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS
> 1.13.0-1ubuntu1.1 04/01/2014
> Call Trace:
>  __dump_stack lib/dump_stack.c:77 [inline]
>  dump_stack+0x107/0x163 lib/dump_stack.c:118
>  print_address_description.constprop.0.cold+0x5/0x4f7 mm/kasan/report.c:385
>  __kasan_report mm/kasan/report.c:545 [inline]
>  kasan_report.cold+0x1f/0x37 mm/kasan/report.c:562
>  check_memory_region_inline mm/kasan/generic.c:194 [inline]
>  check_memory_region+0x187/0x1e0 mm/kasan/generic.c:200
>  memset+0x20/0x40 mm/kasan/common.c:85
>  memset include/linux/string.h:384 [inline]
>  snd_pcm_hw_params+0x19b0/0x1db0 sound/core/pcm_native.c:799
>  snd_pcm_kernel_ioctl+0xd1/0x240 sound/core/pcm_native.c:3401
>  snd_pcm_oss_change_params_locked+0x17b6/0x3aa0 sound/core/oss/pcm_oss.c:965
>  snd_pcm_oss_change_params+0x76/0xd0 sound/core/oss/pcm_oss.c:1107
>  snd_pcm_oss_make_ready+0xb7/0x170 sound/core/oss/pcm_oss.c:1166
>  snd_pcm_oss_set_trigger.isra.0+0x34f/0x770 sound/core/oss/pcm_oss.c:2074
>  snd_pcm_oss_poll+0x679/0xb40 sound/core/oss/pcm_oss.c:2858
>  vfs_poll include/linux/poll.h:90 [inline]
>  do_pollfd fs/select.c:872 [inline]
>  do_poll fs/select.c:920 [inline]
>  do_sys_poll+0x63c/0xe40 fs/select.c:1014
>  __do_sys_poll fs/select.c:1079 [inline]
>  __se_sys_poll fs/select.c:1067 [inline]
>  __x64_sys_poll+0x18c/0x490 fs/select.c:1067
>  do_syscall_64+0x2d/0x70 arch/x86/entry/common.c:46
>  entry_SYSCALL_64_after_hwframe+0x44/0xa9
> RIP: 0033:0x7f095de4f4ed
> Code: 02 b8 ff ff ff ff c3 66 0f 1f 44 00 00 f3 0f 1e fa 48 89 f8 48
> 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d
> 01 f0 ff ff 73 01 c3 48 c7 c1 b8 ff ff ff f7 d8 64 89 01 48
> RSP: 002b:00007f095bdffbe8 EFLAGS: 00000246 ORIG_RAX: 0000000000000007
> RAX: ffffffffffffffda RBX: 00007f095df6df60 RCX: 00007f095de4f4ed
> RDX: 0000000000000009 RSI: 0000000000000001 RDI: 00000000200000c0
> RBP: 00007f095bdffc40 R08: 0000000000000000 R09: 0000000000000000
> R10: 0000000000000000 R11: 0000000000000246 R12: 000000000000001d
> R13: 00007ffff286ceff R14: 00007f095df6df60 R15: 00007f095bdffd80
> 
> 
> Memory state around the buggy address:
>  ffffc900115b1d00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
>  ffffc900115b1d80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> >ffffc900115b1e00: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8
>                    ^
>  ffffc900115b1e80: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8
>  ffffc900115b1f00: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8
> ==================================================================

Wondeful, do you have a fix for this that solves the reported problem
that you have tested with the reproducer?

thanks,

greg k-h

^ permalink raw reply	[flat|nested] 18+ messages in thread

* Re: KASAN: vmalloc-out-of-bounds Write in snd_pcm_hw_params
@ 2022-07-23  7:00   ` Greg KH
  0 siblings, 0 replies; 18+ messages in thread
From: Greg KH @ 2022-07-23  7:00 UTC (permalink / raw)
  To: Dipanjan Das
  Cc: alsa-devel, fleischermarius, tiwai, linux-kernel, consult.awy,
	syzkaller, its.priyanka.bose

On Fri, Jul 22, 2022 at 09:37:52AM -0700, Dipanjan Das wrote:
> Hi,
> 
> We would like to report the following bug which has been found by our
> modified version of syzkaller.
> 
> ======================================================
> description: KASAN: vmalloc-out-of-bounds Write in snd_pcm_hw_params
> affected file: sound/core/pcm_native.c
> kernel version: 5.10.131
> kernel commit: de62055f423f5dcb548f74cebd68f03c8903f73a
> git tree: upstream
> kernel config: https://syzkaller.appspot.com/x/.config?x=e49433cfed49b7d9
> crash reproducer: attached
> ======================================================
> Crash log:
> ======================================================
> BUG: KASAN: vmalloc-out-of-bounds in memset include/linux/string.h:384 [inline]
> BUG: KASAN: vmalloc-out-of-bounds in snd_pcm_hw_params+0x19b0/0x1db0
> sound/core/pcm_native.c:799
> Write of size 2097152 at addr ffffc900113b2000 by task syz-executor.5/14437
> 
> CPU: 1 PID: 14437 Comm: syz-executor.5 Tainted: G           OE     5.10.131+ #3
> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS
> 1.13.0-1ubuntu1.1 04/01/2014
> Call Trace:
>  __dump_stack lib/dump_stack.c:77 [inline]
>  dump_stack+0x107/0x163 lib/dump_stack.c:118
>  print_address_description.constprop.0.cold+0x5/0x4f7 mm/kasan/report.c:385
>  __kasan_report mm/kasan/report.c:545 [inline]
>  kasan_report.cold+0x1f/0x37 mm/kasan/report.c:562
>  check_memory_region_inline mm/kasan/generic.c:194 [inline]
>  check_memory_region+0x187/0x1e0 mm/kasan/generic.c:200
>  memset+0x20/0x40 mm/kasan/common.c:85
>  memset include/linux/string.h:384 [inline]
>  snd_pcm_hw_params+0x19b0/0x1db0 sound/core/pcm_native.c:799
>  snd_pcm_kernel_ioctl+0xd1/0x240 sound/core/pcm_native.c:3401
>  snd_pcm_oss_change_params_locked+0x17b6/0x3aa0 sound/core/oss/pcm_oss.c:965
>  snd_pcm_oss_change_params+0x76/0xd0 sound/core/oss/pcm_oss.c:1107
>  snd_pcm_oss_make_ready+0xb7/0x170 sound/core/oss/pcm_oss.c:1166
>  snd_pcm_oss_set_trigger.isra.0+0x34f/0x770 sound/core/oss/pcm_oss.c:2074
>  snd_pcm_oss_poll+0x679/0xb40 sound/core/oss/pcm_oss.c:2858
>  vfs_poll include/linux/poll.h:90 [inline]
>  do_pollfd fs/select.c:872 [inline]
>  do_poll fs/select.c:920 [inline]
>  do_sys_poll+0x63c/0xe40 fs/select.c:1014
>  __do_sys_poll fs/select.c:1079 [inline]
>  __se_sys_poll fs/select.c:1067 [inline]
>  __x64_sys_poll+0x18c/0x490 fs/select.c:1067
>  do_syscall_64+0x2d/0x70 arch/x86/entry/common.c:46
>  entry_SYSCALL_64_after_hwframe+0x44/0xa9
> RIP: 0033:0x7f095de4f4ed
> Code: 02 b8 ff ff ff ff c3 66 0f 1f 44 00 00 f3 0f 1e fa 48 89 f8 48
> 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d
> 01 f0 ff ff 73 01 c3 48 c7 c1 b8 ff ff ff f7 d8 64 89 01 48
> RSP: 002b:00007f095bdffbe8 EFLAGS: 00000246 ORIG_RAX: 0000000000000007
> RAX: ffffffffffffffda RBX: 00007f095df6df60 RCX: 00007f095de4f4ed
> RDX: 0000000000000009 RSI: 0000000000000001 RDI: 00000000200000c0
> RBP: 00007f095bdffc40 R08: 0000000000000000 R09: 0000000000000000
> R10: 0000000000000000 R11: 0000000000000246 R12: 000000000000001d
> R13: 00007ffff286ceff R14: 00007f095df6df60 R15: 00007f095bdffd80
> 
> 
> Memory state around the buggy address:
>  ffffc900115b1d00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
>  ffffc900115b1d80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> >ffffc900115b1e00: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8
>                    ^
>  ffffc900115b1e80: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8
>  ffffc900115b1f00: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8
> ==================================================================

Wondeful, do you have a fix for this that solves the reported problem
that you have tested with the reproducer?

thanks,

greg k-h

^ permalink raw reply	[flat|nested] 18+ messages in thread

* Re: KASAN: vmalloc-out-of-bounds Write in snd_pcm_hw_params
  2022-07-23  7:00   ` Greg KH
@ 2022-07-23 10:16     ` Takashi Iwai
  -1 siblings, 0 replies; 18+ messages in thread
From: Takashi Iwai @ 2022-07-23 10:16 UTC (permalink / raw)
  To: Dipanjan Das
  Cc: alsa-devel, fleischermarius, Greg KH, linux-kernel, tiwai,
	consult.awy, syzkaller, its.priyanka.bose

On Sat, 23 Jul 2022 09:00:08 +0200,
Greg KH wrote:
> 
> On Fri, Jul 22, 2022 at 09:37:52AM -0700, Dipanjan Das wrote:
> > Hi,
> > 
> > We would like to report the following bug which has been found by our
> > modified version of syzkaller.
> > 
> > ======================================================
> > description: KASAN: vmalloc-out-of-bounds Write in snd_pcm_hw_params
> > affected file: sound/core/pcm_native.c
> > kernel version: 5.10.131
> > kernel commit: de62055f423f5dcb548f74cebd68f03c8903f73a
> > git tree: upstream
> > kernel config: https://syzkaller.appspot.com/x/.config?x=e49433cfed49b7d9
> > crash reproducer: attached
> > ======================================================
> > Crash log:
> > ======================================================
> > BUG: KASAN: vmalloc-out-of-bounds in memset include/linux/string.h:384 [inline]
> > BUG: KASAN: vmalloc-out-of-bounds in snd_pcm_hw_params+0x19b0/0x1db0
> > sound/core/pcm_native.c:799
> > Write of size 2097152 at addr ffffc900113b2000 by task syz-executor.5/14437
> > 
> > CPU: 1 PID: 14437 Comm: syz-executor.5 Tainted: G           OE     5.10.131+ #3
> > Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS
> > 1.13.0-1ubuntu1.1 04/01/2014
> > Call Trace:
> >  __dump_stack lib/dump_stack.c:77 [inline]
> >  dump_stack+0x107/0x163 lib/dump_stack.c:118
> >  print_address_description.constprop.0.cold+0x5/0x4f7 mm/kasan/report.c:385
> >  __kasan_report mm/kasan/report.c:545 [inline]
> >  kasan_report.cold+0x1f/0x37 mm/kasan/report.c:562
> >  check_memory_region_inline mm/kasan/generic.c:194 [inline]
> >  check_memory_region+0x187/0x1e0 mm/kasan/generic.c:200
> >  memset+0x20/0x40 mm/kasan/common.c:85
> >  memset include/linux/string.h:384 [inline]
> >  snd_pcm_hw_params+0x19b0/0x1db0 sound/core/pcm_native.c:799
> >  snd_pcm_kernel_ioctl+0xd1/0x240 sound/core/pcm_native.c:3401
> >  snd_pcm_oss_change_params_locked+0x17b6/0x3aa0 sound/core/oss/pcm_oss.c:965
> >  snd_pcm_oss_change_params+0x76/0xd0 sound/core/oss/pcm_oss.c:1107
> >  snd_pcm_oss_make_ready+0xb7/0x170 sound/core/oss/pcm_oss.c:1166
> >  snd_pcm_oss_set_trigger.isra.0+0x34f/0x770 sound/core/oss/pcm_oss.c:2074
> >  snd_pcm_oss_poll+0x679/0xb40 sound/core/oss/pcm_oss.c:2858
> >  vfs_poll include/linux/poll.h:90 [inline]
> >  do_pollfd fs/select.c:872 [inline]
> >  do_poll fs/select.c:920 [inline]
> >  do_sys_poll+0x63c/0xe40 fs/select.c:1014
> >  __do_sys_poll fs/select.c:1079 [inline]
> >  __se_sys_poll fs/select.c:1067 [inline]
> >  __x64_sys_poll+0x18c/0x490 fs/select.c:1067
> >  do_syscall_64+0x2d/0x70 arch/x86/entry/common.c:46
> >  entry_SYSCALL_64_after_hwframe+0x44/0xa9
> > RIP: 0033:0x7f095de4f4ed
> > Code: 02 b8 ff ff ff ff c3 66 0f 1f 44 00 00 f3 0f 1e fa 48 89 f8 48
> > 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d
> > 01 f0 ff ff 73 01 c3 48 c7 c1 b8 ff ff ff f7 d8 64 89 01 48
> > RSP: 002b:00007f095bdffbe8 EFLAGS: 00000246 ORIG_RAX: 0000000000000007
> > RAX: ffffffffffffffda RBX: 00007f095df6df60 RCX: 00007f095de4f4ed
> > RDX: 0000000000000009 RSI: 0000000000000001 RDI: 00000000200000c0
> > RBP: 00007f095bdffc40 R08: 0000000000000000 R09: 0000000000000000
> > R10: 0000000000000000 R11: 0000000000000246 R12: 000000000000001d
> > R13: 00007ffff286ceff R14: 00007f095df6df60 R15: 00007f095bdffd80
> > 
> > 
> > Memory state around the buggy address:
> >  ffffc900115b1d00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> >  ffffc900115b1d80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> > >ffffc900115b1e00: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8
> >                    ^
> >  ffffc900115b1e80: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8
> >  ffffc900115b1f00: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8
> > ==================================================================
> 
> Wondeful, do you have a fix for this that solves the reported problem
> that you have tested with the reproducer?

... or at least more detailed information.

The given log snippet alone doesn't help for further analysis, as it
doesn't show which device / driver is involved.  The code is the
common helper and the condition for the trigger might be depending on
the driver side.  The full kernel log might show which driver (IIUC,
it's /dev/adsp1) is in place.

Last but not least, you should check whether it's specific to your
5.10.x kernel or it's also seen with the latest upstream, too.


thanks,

Takashi

^ permalink raw reply	[flat|nested] 18+ messages in thread

* Re: KASAN: vmalloc-out-of-bounds Write in snd_pcm_hw_params
@ 2022-07-23 10:16     ` Takashi Iwai
  0 siblings, 0 replies; 18+ messages in thread
From: Takashi Iwai @ 2022-07-23 10:16 UTC (permalink / raw)
  To: Dipanjan Das
  Cc: Greg KH, perex, tiwai, consult.awy, alsa-devel, linux-kernel,
	syzkaller, fleischermarius, its.priyanka.bose

On Sat, 23 Jul 2022 09:00:08 +0200,
Greg KH wrote:
> 
> On Fri, Jul 22, 2022 at 09:37:52AM -0700, Dipanjan Das wrote:
> > Hi,
> > 
> > We would like to report the following bug which has been found by our
> > modified version of syzkaller.
> > 
> > ======================================================
> > description: KASAN: vmalloc-out-of-bounds Write in snd_pcm_hw_params
> > affected file: sound/core/pcm_native.c
> > kernel version: 5.10.131
> > kernel commit: de62055f423f5dcb548f74cebd68f03c8903f73a
> > git tree: upstream
> > kernel config: https://syzkaller.appspot.com/x/.config?x=e49433cfed49b7d9
> > crash reproducer: attached
> > ======================================================
> > Crash log:
> > ======================================================
> > BUG: KASAN: vmalloc-out-of-bounds in memset include/linux/string.h:384 [inline]
> > BUG: KASAN: vmalloc-out-of-bounds in snd_pcm_hw_params+0x19b0/0x1db0
> > sound/core/pcm_native.c:799
> > Write of size 2097152 at addr ffffc900113b2000 by task syz-executor.5/14437
> > 
> > CPU: 1 PID: 14437 Comm: syz-executor.5 Tainted: G           OE     5.10.131+ #3
> > Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS
> > 1.13.0-1ubuntu1.1 04/01/2014
> > Call Trace:
> >  __dump_stack lib/dump_stack.c:77 [inline]
> >  dump_stack+0x107/0x163 lib/dump_stack.c:118
> >  print_address_description.constprop.0.cold+0x5/0x4f7 mm/kasan/report.c:385
> >  __kasan_report mm/kasan/report.c:545 [inline]
> >  kasan_report.cold+0x1f/0x37 mm/kasan/report.c:562
> >  check_memory_region_inline mm/kasan/generic.c:194 [inline]
> >  check_memory_region+0x187/0x1e0 mm/kasan/generic.c:200
> >  memset+0x20/0x40 mm/kasan/common.c:85
> >  memset include/linux/string.h:384 [inline]
> >  snd_pcm_hw_params+0x19b0/0x1db0 sound/core/pcm_native.c:799
> >  snd_pcm_kernel_ioctl+0xd1/0x240 sound/core/pcm_native.c:3401
> >  snd_pcm_oss_change_params_locked+0x17b6/0x3aa0 sound/core/oss/pcm_oss.c:965
> >  snd_pcm_oss_change_params+0x76/0xd0 sound/core/oss/pcm_oss.c:1107
> >  snd_pcm_oss_make_ready+0xb7/0x170 sound/core/oss/pcm_oss.c:1166
> >  snd_pcm_oss_set_trigger.isra.0+0x34f/0x770 sound/core/oss/pcm_oss.c:2074
> >  snd_pcm_oss_poll+0x679/0xb40 sound/core/oss/pcm_oss.c:2858
> >  vfs_poll include/linux/poll.h:90 [inline]
> >  do_pollfd fs/select.c:872 [inline]
> >  do_poll fs/select.c:920 [inline]
> >  do_sys_poll+0x63c/0xe40 fs/select.c:1014
> >  __do_sys_poll fs/select.c:1079 [inline]
> >  __se_sys_poll fs/select.c:1067 [inline]
> >  __x64_sys_poll+0x18c/0x490 fs/select.c:1067
> >  do_syscall_64+0x2d/0x70 arch/x86/entry/common.c:46
> >  entry_SYSCALL_64_after_hwframe+0x44/0xa9
> > RIP: 0033:0x7f095de4f4ed
> > Code: 02 b8 ff ff ff ff c3 66 0f 1f 44 00 00 f3 0f 1e fa 48 89 f8 48
> > 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d
> > 01 f0 ff ff 73 01 c3 48 c7 c1 b8 ff ff ff f7 d8 64 89 01 48
> > RSP: 002b:00007f095bdffbe8 EFLAGS: 00000246 ORIG_RAX: 0000000000000007
> > RAX: ffffffffffffffda RBX: 00007f095df6df60 RCX: 00007f095de4f4ed
> > RDX: 0000000000000009 RSI: 0000000000000001 RDI: 00000000200000c0
> > RBP: 00007f095bdffc40 R08: 0000000000000000 R09: 0000000000000000
> > R10: 0000000000000000 R11: 0000000000000246 R12: 000000000000001d
> > R13: 00007ffff286ceff R14: 00007f095df6df60 R15: 00007f095bdffd80
> > 
> > 
> > Memory state around the buggy address:
> >  ffffc900115b1d00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> >  ffffc900115b1d80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> > >ffffc900115b1e00: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8
> >                    ^
> >  ffffc900115b1e80: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8
> >  ffffc900115b1f00: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8
> > ==================================================================
> 
> Wondeful, do you have a fix for this that solves the reported problem
> that you have tested with the reproducer?

... or at least more detailed information.

The given log snippet alone doesn't help for further analysis, as it
doesn't show which device / driver is involved.  The code is the
common helper and the condition for the trigger might be depending on
the driver side.  The full kernel log might show which driver (IIUC,
it's /dev/adsp1) is in place.

Last but not least, you should check whether it's specific to your
5.10.x kernel or it's also seen with the latest upstream, too.


thanks,

Takashi

^ permalink raw reply	[flat|nested] 18+ messages in thread

* Re: KASAN: vmalloc-out-of-bounds Write in snd_pcm_hw_params
  2022-07-23 10:16     ` Takashi Iwai
@ 2022-07-26 21:40       ` Dipanjan Das
  -1 siblings, 0 replies; 18+ messages in thread
From: Dipanjan Das @ 2022-07-26 21:40 UTC (permalink / raw)
  To: Takashi Iwai
  Cc: Greg KH, perex, tiwai, consult.awy, alsa-devel, linux-kernel,
	syzkaller, fleischermarius, its.priyanka.bose

On Sat, Jul 23, 2022 at 3:17 AM Takashi Iwai <tiwai@suse.de> wrote:
>
> On Sat, 23 Jul 2022 09:00:08 +0200,
> Greg KH wrote:
> >
> > Wondeful, do you have a fix for this that solves the reported problem
> > that you have tested with the reproducer?
>
> ... or at least more detailed information.

Here is our analysis of the bug in the kernel v5.10.131.

During allocation, the `size` of the DMA buffer is not page-aligned:
https://elixir.bootlin.com/linux/v5.10.131/source/sound/core/memalloc.c#L149.
However, in sound/core/pcm_native.c:798
(https://elixir.bootlin.com/linux/v5.10.131/source/sound/core/pcm_native.c#L798),
the `size` variable is page-aligned before memset-ing the `dma_area`.
From the other BUG_ON assertions in other parts of the code, it looks
like the DMA area is not supposed to be equal to or greater than
0x200000 bytes. However, due to page-alignment, the `size` can indeed
get rounded up to 0x200000 which causes the out of bound access.

> Last but not least, you should check whether it's specific to your
> 5.10.x kernel or it's also seen with the latest upstream, too.

The bug is not reproducible on the latest mainline, because in
sound/core/memalloc.c:66
(https://github.com/torvalds/linux/blob/5de64d44968e4ae66ebdb0a2d08b443f189d3651/sound/core/memalloc.c#L66)
the allocation function `snd_dma_alloc_dir_pages()` now page-aligns
the `size` right before allocating the DMA buffer. Therefore, any
subsequent page-alignment, like the one in `snd_pcm_hw_params()` does
not cause an out of bound access.

-- 
Thanks and Regards,

Dipanjan

^ permalink raw reply	[flat|nested] 18+ messages in thread

* Re: KASAN: vmalloc-out-of-bounds Write in snd_pcm_hw_params
@ 2022-07-26 21:40       ` Dipanjan Das
  0 siblings, 0 replies; 18+ messages in thread
From: Dipanjan Das @ 2022-07-26 21:40 UTC (permalink / raw)
  To: Takashi Iwai
  Cc: alsa-devel, fleischermarius, Greg KH, linux-kernel, tiwai,
	consult.awy, syzkaller, its.priyanka.bose

On Sat, Jul 23, 2022 at 3:17 AM Takashi Iwai <tiwai@suse.de> wrote:
>
> On Sat, 23 Jul 2022 09:00:08 +0200,
> Greg KH wrote:
> >
> > Wondeful, do you have a fix for this that solves the reported problem
> > that you have tested with the reproducer?
>
> ... or at least more detailed information.

Here is our analysis of the bug in the kernel v5.10.131.

During allocation, the `size` of the DMA buffer is not page-aligned:
https://elixir.bootlin.com/linux/v5.10.131/source/sound/core/memalloc.c#L149.
However, in sound/core/pcm_native.c:798
(https://elixir.bootlin.com/linux/v5.10.131/source/sound/core/pcm_native.c#L798),
the `size` variable is page-aligned before memset-ing the `dma_area`.
From the other BUG_ON assertions in other parts of the code, it looks
like the DMA area is not supposed to be equal to or greater than
0x200000 bytes. However, due to page-alignment, the `size` can indeed
get rounded up to 0x200000 which causes the out of bound access.

> Last but not least, you should check whether it's specific to your
> 5.10.x kernel or it's also seen with the latest upstream, too.

The bug is not reproducible on the latest mainline, because in
sound/core/memalloc.c:66
(https://github.com/torvalds/linux/blob/5de64d44968e4ae66ebdb0a2d08b443f189d3651/sound/core/memalloc.c#L66)
the allocation function `snd_dma_alloc_dir_pages()` now page-aligns
the `size` right before allocating the DMA buffer. Therefore, any
subsequent page-alignment, like the one in `snd_pcm_hw_params()` does
not cause an out of bound access.

-- 
Thanks and Regards,

Dipanjan

^ permalink raw reply	[flat|nested] 18+ messages in thread

* Re: KASAN: vmalloc-out-of-bounds Write in snd_pcm_hw_params
  2022-07-26 21:40       ` Dipanjan Das
@ 2022-07-27  4:06         ` Lukas Bulwahn
  -1 siblings, 0 replies; 18+ messages in thread
From: Lukas Bulwahn @ 2022-07-27  4:06 UTC (permalink / raw)
  To: Dipanjan Das
  Cc: Takashi Iwai, Greg KH, Jaroslav Kysela, Takashi Iwai,
	consult.awy, alsa-devel, Linux Kernel Mailing List, syzkaller,
	fleischermarius, its.priyanka.bose

On Tue, Jul 26, 2022 at 11:41 PM Dipanjan Das
<mail.dipanjan.das@gmail.com> wrote:
>
> On Sat, Jul 23, 2022 at 3:17 AM Takashi Iwai <tiwai@suse.de> wrote:
> >
> > On Sat, 23 Jul 2022 09:00:08 +0200,
> > Greg KH wrote:
> > >
> > > Wondeful, do you have a fix for this that solves the reported problem
> > > that you have tested with the reproducer?
> >
> > ... or at least more detailed information.
>
> Here is our analysis of the bug in the kernel v5.10.131.
>
> During allocation, the `size` of the DMA buffer is not page-aligned:
> https://elixir.bootlin.com/linux/v5.10.131/source/sound/core/memalloc.c#L149.
> However, in sound/core/pcm_native.c:798
> (https://elixir.bootlin.com/linux/v5.10.131/source/sound/core/pcm_native.c#L798),
> the `size` variable is page-aligned before memset-ing the `dma_area`.
> From the other BUG_ON assertions in other parts of the code, it looks
> like the DMA area is not supposed to be equal to or greater than
> 0x200000 bytes. However, due to page-alignment, the `size` can indeed
> get rounded up to 0x200000 which causes the out of bound access.
>
> > Last but not least, you should check whether it's specific to your
> > 5.10.x kernel or it's also seen with the latest upstream, too.
>
> The bug is not reproducible on the latest mainline, because in
> sound/core/memalloc.c:66
> (https://github.com/torvalds/linux/blob/5de64d44968e4ae66ebdb0a2d08b443f189d3651/sound/core/memalloc.c#L66)
> the allocation function `snd_dma_alloc_dir_pages()` now page-aligns
> the `size` right before allocating the DMA buffer. Therefore, any
> subsequent page-alignment, like the one in `snd_pcm_hw_params()` does
> not cause an out of bound access.
>

Great analysis!

Now, you would just need to identify the specific commit in the
mainline repository, where 'function `snd_dma_alloc_dir_pages()` now
page-aligns the `size` right before allocating the DMA buffer.', and
then ask for applying that commit to the v5.10 stable branch,
following the guide from
https://www.kernel.org/doc/html/latest/process/stable-kernel-rules.html.
Greg KH and Sasha Levin are then going to let you know if that works
or needs rework to backport.


Lukas

^ permalink raw reply	[flat|nested] 18+ messages in thread

* Re: KASAN: vmalloc-out-of-bounds Write in snd_pcm_hw_params
@ 2022-07-27  4:06         ` Lukas Bulwahn
  0 siblings, 0 replies; 18+ messages in thread
From: Lukas Bulwahn @ 2022-07-27  4:06 UTC (permalink / raw)
  To: Dipanjan Das
  Cc: alsa-devel, fleischermarius, Takashi Iwai, Greg KH, Takashi Iwai,
	consult.awy, syzkaller, its.priyanka.bose,
	Linux Kernel Mailing List

On Tue, Jul 26, 2022 at 11:41 PM Dipanjan Das
<mail.dipanjan.das@gmail.com> wrote:
>
> On Sat, Jul 23, 2022 at 3:17 AM Takashi Iwai <tiwai@suse.de> wrote:
> >
> > On Sat, 23 Jul 2022 09:00:08 +0200,
> > Greg KH wrote:
> > >
> > > Wondeful, do you have a fix for this that solves the reported problem
> > > that you have tested with the reproducer?
> >
> > ... or at least more detailed information.
>
> Here is our analysis of the bug in the kernel v5.10.131.
>
> During allocation, the `size` of the DMA buffer is not page-aligned:
> https://elixir.bootlin.com/linux/v5.10.131/source/sound/core/memalloc.c#L149.
> However, in sound/core/pcm_native.c:798
> (https://elixir.bootlin.com/linux/v5.10.131/source/sound/core/pcm_native.c#L798),
> the `size` variable is page-aligned before memset-ing the `dma_area`.
> From the other BUG_ON assertions in other parts of the code, it looks
> like the DMA area is not supposed to be equal to or greater than
> 0x200000 bytes. However, due to page-alignment, the `size` can indeed
> get rounded up to 0x200000 which causes the out of bound access.
>
> > Last but not least, you should check whether it's specific to your
> > 5.10.x kernel or it's also seen with the latest upstream, too.
>
> The bug is not reproducible on the latest mainline, because in
> sound/core/memalloc.c:66
> (https://github.com/torvalds/linux/blob/5de64d44968e4ae66ebdb0a2d08b443f189d3651/sound/core/memalloc.c#L66)
> the allocation function `snd_dma_alloc_dir_pages()` now page-aligns
> the `size` right before allocating the DMA buffer. Therefore, any
> subsequent page-alignment, like the one in `snd_pcm_hw_params()` does
> not cause an out of bound access.
>

Great analysis!

Now, you would just need to identify the specific commit in the
mainline repository, where 'function `snd_dma_alloc_dir_pages()` now
page-aligns the `size` right before allocating the DMA buffer.', and
then ask for applying that commit to the v5.10 stable branch,
following the guide from
https://www.kernel.org/doc/html/latest/process/stable-kernel-rules.html.
Greg KH and Sasha Levin are then going to let you know if that works
or needs rework to backport.


Lukas

^ permalink raw reply	[flat|nested] 18+ messages in thread

* Re: KASAN: vmalloc-out-of-bounds Write in snd_pcm_hw_params
  2022-07-26 21:40       ` Dipanjan Das
@ 2022-07-27  5:25         ` Takashi Iwai
  -1 siblings, 0 replies; 18+ messages in thread
From: Takashi Iwai @ 2022-07-27  5:25 UTC (permalink / raw)
  To: Dipanjan Das
  Cc: Greg KH, perex, tiwai, consult.awy, alsa-devel, linux-kernel,
	syzkaller, fleischermarius, its.priyanka.bose

On Tue, 26 Jul 2022 23:40:48 +0200,
Dipanjan Das wrote:
> 
> On Sat, Jul 23, 2022 at 3:17 AM Takashi Iwai <tiwai@suse.de> wrote:
> >
> > On Sat, 23 Jul 2022 09:00:08 +0200,
> > Greg KH wrote:
> > >
> > > Wondeful, do you have a fix for this that solves the reported problem
> > > that you have tested with the reproducer?
> >
> > ... or at least more detailed information.
> 
> Here is our analysis of the bug in the kernel v5.10.131.
> 
> During allocation, the `size` of the DMA buffer is not page-aligned:
> https://elixir.bootlin.com/linux/v5.10.131/source/sound/core/memalloc.c#L149.
> However, in sound/core/pcm_native.c:798
> (https://elixir.bootlin.com/linux/v5.10.131/source/sound/core/pcm_native.c#L798),
> the `size` variable is page-aligned before memset-ing the `dma_area`.
> >From the other BUG_ON assertions in other parts of the code, it looks
> like the DMA area is not supposed to be equal to or greater than
> 0x200000 bytes. However, due to page-alignment, the `size` can indeed
> get rounded up to 0x200000 which causes the out of bound access.
> 
> > Last but not least, you should check whether it's specific to your
> > 5.10.x kernel or it's also seen with the latest upstream, too.
> 
> The bug is not reproducible on the latest mainline, because in
> sound/core/memalloc.c:66
> (https://github.com/torvalds/linux/blob/5de64d44968e4ae66ebdb0a2d08b443f189d3651/sound/core/memalloc.c#L66)
> the allocation function `snd_dma_alloc_dir_pages()` now page-aligns
> the `size` right before allocating the DMA buffer. Therefore, any
> subsequent page-alignment, like the one in `snd_pcm_hw_params()` does
> not cause an out of bound access.

Thanks for the analysis.  A good news is that, at least for the
vmalloc() case, it's a kind of false-positive; vmalloc() always takes
the full pages, so practically seen, the size is page-aligned.  It's
fooling the memory checker, though.

But the similar problem could be seen with genalloc calls, and this
was fixed by the upstream commit
5c1733e33c888a3cb7f576564d8ad543d5ad4a9e
    ALSA: memalloc: Align buffer allocations in page size

I suppose you can simply backport this commit to 5.10.y.  Could you
confirm that this fixes your problem?


thanks,

Takashi

^ permalink raw reply	[flat|nested] 18+ messages in thread

* Re: KASAN: vmalloc-out-of-bounds Write in snd_pcm_hw_params
@ 2022-07-27  5:25         ` Takashi Iwai
  0 siblings, 0 replies; 18+ messages in thread
From: Takashi Iwai @ 2022-07-27  5:25 UTC (permalink / raw)
  To: Dipanjan Das
  Cc: alsa-devel, fleischermarius, Greg KH, linux-kernel, tiwai,
	consult.awy, syzkaller, its.priyanka.bose

On Tue, 26 Jul 2022 23:40:48 +0200,
Dipanjan Das wrote:
> 
> On Sat, Jul 23, 2022 at 3:17 AM Takashi Iwai <tiwai@suse.de> wrote:
> >
> > On Sat, 23 Jul 2022 09:00:08 +0200,
> > Greg KH wrote:
> > >
> > > Wondeful, do you have a fix for this that solves the reported problem
> > > that you have tested with the reproducer?
> >
> > ... or at least more detailed information.
> 
> Here is our analysis of the bug in the kernel v5.10.131.
> 
> During allocation, the `size` of the DMA buffer is not page-aligned:
> https://elixir.bootlin.com/linux/v5.10.131/source/sound/core/memalloc.c#L149.
> However, in sound/core/pcm_native.c:798
> (https://elixir.bootlin.com/linux/v5.10.131/source/sound/core/pcm_native.c#L798),
> the `size` variable is page-aligned before memset-ing the `dma_area`.
> >From the other BUG_ON assertions in other parts of the code, it looks
> like the DMA area is not supposed to be equal to or greater than
> 0x200000 bytes. However, due to page-alignment, the `size` can indeed
> get rounded up to 0x200000 which causes the out of bound access.
> 
> > Last but not least, you should check whether it's specific to your
> > 5.10.x kernel or it's also seen with the latest upstream, too.
> 
> The bug is not reproducible on the latest mainline, because in
> sound/core/memalloc.c:66
> (https://github.com/torvalds/linux/blob/5de64d44968e4ae66ebdb0a2d08b443f189d3651/sound/core/memalloc.c#L66)
> the allocation function `snd_dma_alloc_dir_pages()` now page-aligns
> the `size` right before allocating the DMA buffer. Therefore, any
> subsequent page-alignment, like the one in `snd_pcm_hw_params()` does
> not cause an out of bound access.

Thanks for the analysis.  A good news is that, at least for the
vmalloc() case, it's a kind of false-positive; vmalloc() always takes
the full pages, so practically seen, the size is page-aligned.  It's
fooling the memory checker, though.

But the similar problem could be seen with genalloc calls, and this
was fixed by the upstream commit
5c1733e33c888a3cb7f576564d8ad543d5ad4a9e
    ALSA: memalloc: Align buffer allocations in page size

I suppose you can simply backport this commit to 5.10.y.  Could you
confirm that this fixes your problem?


thanks,

Takashi

^ permalink raw reply	[flat|nested] 18+ messages in thread

* Re: KASAN: vmalloc-out-of-bounds Write in snd_pcm_hw_params
  2022-07-27  5:25         ` Takashi Iwai
@ 2022-07-28 23:24           ` Dipanjan Das
  -1 siblings, 0 replies; 18+ messages in thread
From: Dipanjan Das @ 2022-07-28 23:24 UTC (permalink / raw)
  To: Takashi Iwai
  Cc: Greg KH, perex, tiwai, consult.awy, alsa-devel, linux-kernel,
	syzkaller, fleischermarius, its.priyanka.bose

On Tue, Jul 26, 2022 at 10:25 PM Takashi Iwai <tiwai@suse.de> wrote:
>
> Thanks for the analysis.  A good news is that, at least for the
> vmalloc() case, it's a kind of false-positive; vmalloc() always takes
> the full pages, so practically seen, the size is page-aligned.  It's
> fooling the memory checker, though.
>
> But the similar problem could be seen with genalloc calls, and this
> was fixed by the upstream commit
> 5c1733e33c888a3cb7f576564d8ad543d5ad4a9e
>     ALSA: memalloc: Align buffer allocations in page size
>
> I suppose you can simply backport this commit to 5.10.y.  Could you
> confirm that this fixes your problem?

We confirm that the patch you proposed fixes the problem (blocks the
reproducer). How do we proceed with getting the issue fixed? Do we
send a patch according to the steps detailed here:
https://www.kernel.org/doc/html/latest/process/stable-kernel-rules.html?

-- 
Thanks and Regards,

Dipanjan

^ permalink raw reply	[flat|nested] 18+ messages in thread

* Re: KASAN: vmalloc-out-of-bounds Write in snd_pcm_hw_params
@ 2022-07-28 23:24           ` Dipanjan Das
  0 siblings, 0 replies; 18+ messages in thread
From: Dipanjan Das @ 2022-07-28 23:24 UTC (permalink / raw)
  To: Takashi Iwai
  Cc: alsa-devel, fleischermarius, Greg KH, linux-kernel, tiwai,
	consult.awy, syzkaller, its.priyanka.bose

On Tue, Jul 26, 2022 at 10:25 PM Takashi Iwai <tiwai@suse.de> wrote:
>
> Thanks for the analysis.  A good news is that, at least for the
> vmalloc() case, it's a kind of false-positive; vmalloc() always takes
> the full pages, so practically seen, the size is page-aligned.  It's
> fooling the memory checker, though.
>
> But the similar problem could be seen with genalloc calls, and this
> was fixed by the upstream commit
> 5c1733e33c888a3cb7f576564d8ad543d5ad4a9e
>     ALSA: memalloc: Align buffer allocations in page size
>
> I suppose you can simply backport this commit to 5.10.y.  Could you
> confirm that this fixes your problem?

We confirm that the patch you proposed fixes the problem (blocks the
reproducer). How do we proceed with getting the issue fixed? Do we
send a patch according to the steps detailed here:
https://www.kernel.org/doc/html/latest/process/stable-kernel-rules.html?

-- 
Thanks and Regards,

Dipanjan

^ permalink raw reply	[flat|nested] 18+ messages in thread

* Re: KASAN: vmalloc-out-of-bounds Write in snd_pcm_hw_params
  2022-07-28 23:24           ` Dipanjan Das
@ 2022-07-29  6:07             ` Takashi Iwai
  -1 siblings, 0 replies; 18+ messages in thread
From: Takashi Iwai @ 2022-07-29  6:07 UTC (permalink / raw)
  To: Dipanjan Das
  Cc: Greg KH, perex, tiwai, consult.awy, alsa-devel, linux-kernel,
	syzkaller, fleischermarius, its.priyanka.bose

On Fri, 29 Jul 2022 01:24:12 +0200,
Dipanjan Das wrote:
> 
> On Tue, Jul 26, 2022 at 10:25 PM Takashi Iwai <tiwai@suse.de> wrote:
> >
> > Thanks for the analysis.  A good news is that, at least for the
> > vmalloc() case, it's a kind of false-positive; vmalloc() always takes
> > the full pages, so practically seen, the size is page-aligned.  It's
> > fooling the memory checker, though.
> >
> > But the similar problem could be seen with genalloc calls, and this
> > was fixed by the upstream commit
> > 5c1733e33c888a3cb7f576564d8ad543d5ad4a9e
> >     ALSA: memalloc: Align buffer allocations in page size
> >
> > I suppose you can simply backport this commit to 5.10.y.  Could you
> > confirm that this fixes your problem?
> 
> We confirm that the patch you proposed fixes the problem (blocks the
> reproducer). How do we proceed with getting the issue fixed? Do we
> send a patch according to the steps detailed here:
> https://www.kernel.org/doc/html/latest/process/stable-kernel-rules.html?

Don't worry, Greg already picked up the fix commit :)


thanks,

Takashi

^ permalink raw reply	[flat|nested] 18+ messages in thread

* Re: KASAN: vmalloc-out-of-bounds Write in snd_pcm_hw_params
@ 2022-07-29  6:07             ` Takashi Iwai
  0 siblings, 0 replies; 18+ messages in thread
From: Takashi Iwai @ 2022-07-29  6:07 UTC (permalink / raw)
  To: Dipanjan Das
  Cc: alsa-devel, fleischermarius, Greg KH, linux-kernel, tiwai,
	consult.awy, syzkaller, its.priyanka.bose

On Fri, 29 Jul 2022 01:24:12 +0200,
Dipanjan Das wrote:
> 
> On Tue, Jul 26, 2022 at 10:25 PM Takashi Iwai <tiwai@suse.de> wrote:
> >
> > Thanks for the analysis.  A good news is that, at least for the
> > vmalloc() case, it's a kind of false-positive; vmalloc() always takes
> > the full pages, so practically seen, the size is page-aligned.  It's
> > fooling the memory checker, though.
> >
> > But the similar problem could be seen with genalloc calls, and this
> > was fixed by the upstream commit
> > 5c1733e33c888a3cb7f576564d8ad543d5ad4a9e
> >     ALSA: memalloc: Align buffer allocations in page size
> >
> > I suppose you can simply backport this commit to 5.10.y.  Could you
> > confirm that this fixes your problem?
> 
> We confirm that the patch you proposed fixes the problem (blocks the
> reproducer). How do we proceed with getting the issue fixed? Do we
> send a patch according to the steps detailed here:
> https://www.kernel.org/doc/html/latest/process/stable-kernel-rules.html?

Don't worry, Greg already picked up the fix commit :)


thanks,

Takashi

^ permalink raw reply	[flat|nested] 18+ messages in thread

* Re: KASAN: vmalloc-out-of-bounds Write in snd_pcm_hw_params
  2022-07-28 23:24           ` Dipanjan Das
@ 2022-07-29  8:13             ` Greg KH
  -1 siblings, 0 replies; 18+ messages in thread
From: Greg KH @ 2022-07-29  8:13 UTC (permalink / raw)
  To: Dipanjan Das
  Cc: Takashi Iwai, perex, tiwai, consult.awy, alsa-devel,
	linux-kernel, syzkaller, fleischermarius, its.priyanka.bose

On Thu, Jul 28, 2022 at 04:24:12PM -0700, Dipanjan Das wrote:
> On Tue, Jul 26, 2022 at 10:25 PM Takashi Iwai <tiwai@suse.de> wrote:
> >
> > Thanks for the analysis.  A good news is that, at least for the
> > vmalloc() case, it's a kind of false-positive; vmalloc() always takes
> > the full pages, so practically seen, the size is page-aligned.  It's
> > fooling the memory checker, though.
> >
> > But the similar problem could be seen with genalloc calls, and this
> > was fixed by the upstream commit
> > 5c1733e33c888a3cb7f576564d8ad543d5ad4a9e
> >     ALSA: memalloc: Align buffer allocations in page size
> >
> > I suppose you can simply backport this commit to 5.10.y.  Could you
> > confirm that this fixes your problem?
> 
> We confirm that the patch you proposed fixes the problem (blocks the
> reproducer). How do we proceed with getting the issue fixed? Do we
> send a patch according to the steps detailed here:
> https://www.kernel.org/doc/html/latest/process/stable-kernel-rules.html?

Normally, yes, that is the correct process.  But as Takashi mentioned, I
already picked it up as I happened to see this thread.

thanks,

greg k-h

^ permalink raw reply	[flat|nested] 18+ messages in thread

* Re: KASAN: vmalloc-out-of-bounds Write in snd_pcm_hw_params
@ 2022-07-29  8:13             ` Greg KH
  0 siblings, 0 replies; 18+ messages in thread
From: Greg KH @ 2022-07-29  8:13 UTC (permalink / raw)
  To: Dipanjan Das
  Cc: alsa-devel, fleischermarius, Takashi Iwai, tiwai, linux-kernel,
	consult.awy, syzkaller, its.priyanka.bose

On Thu, Jul 28, 2022 at 04:24:12PM -0700, Dipanjan Das wrote:
> On Tue, Jul 26, 2022 at 10:25 PM Takashi Iwai <tiwai@suse.de> wrote:
> >
> > Thanks for the analysis.  A good news is that, at least for the
> > vmalloc() case, it's a kind of false-positive; vmalloc() always takes
> > the full pages, so practically seen, the size is page-aligned.  It's
> > fooling the memory checker, though.
> >
> > But the similar problem could be seen with genalloc calls, and this
> > was fixed by the upstream commit
> > 5c1733e33c888a3cb7f576564d8ad543d5ad4a9e
> >     ALSA: memalloc: Align buffer allocations in page size
> >
> > I suppose you can simply backport this commit to 5.10.y.  Could you
> > confirm that this fixes your problem?
> 
> We confirm that the patch you proposed fixes the problem (blocks the
> reproducer). How do we proceed with getting the issue fixed? Do we
> send a patch according to the steps detailed here:
> https://www.kernel.org/doc/html/latest/process/stable-kernel-rules.html?

Normally, yes, that is the correct process.  But as Takashi mentioned, I
already picked it up as I happened to see this thread.

thanks,

greg k-h

^ permalink raw reply	[flat|nested] 18+ messages in thread

end of thread, other threads:[~2022-07-29  8:14 UTC | newest]

Thread overview: 18+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2022-07-22 16:37 KASAN: vmalloc-out-of-bounds Write in snd_pcm_hw_params Dipanjan Das
2022-07-22 16:37 ` Dipanjan Das
2022-07-23  7:00 ` Greg KH
2022-07-23  7:00   ` Greg KH
2022-07-23 10:16   ` Takashi Iwai
2022-07-23 10:16     ` Takashi Iwai
2022-07-26 21:40     ` Dipanjan Das
2022-07-26 21:40       ` Dipanjan Das
2022-07-27  4:06       ` Lukas Bulwahn
2022-07-27  4:06         ` Lukas Bulwahn
2022-07-27  5:25       ` Takashi Iwai
2022-07-27  5:25         ` Takashi Iwai
2022-07-28 23:24         ` Dipanjan Das
2022-07-28 23:24           ` Dipanjan Das
2022-07-29  6:07           ` Takashi Iwai
2022-07-29  6:07             ` Takashi Iwai
2022-07-29  8:13           ` Greg KH
2022-07-29  8:13             ` Greg KH

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.