* syzkaller test panic: Linux 5.4.y
@ 2021-10-18 21:29 john.p.donnelly
2021-10-19 15:24 ` mleitner
0 siblings, 1 reply; 6+ messages in thread
From: john.p.donnelly @ 2021-10-18 21:29 UTC (permalink / raw)
To: linux-sctp
Hello,
I like to report a syzkaller test failure that introduces a panic with
the Linux-5.4.y kernel:
strace shows this activity ;
#strace ./test-scpt
socket(AF_INET6, SOCK_STREAM, IPPROTO_SCTP) = 3
setsockopt(3, SOL_SCTP, 0x76 /* SCTP_??? */, "\0\0\0\0\7\0\0\0", 8) = 0
setsockopt(3, SOL_SCTP, 0x64 /* SCTP_??? */,
"\n\0N#\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\1\0\0\0\0", 28) = 0
setsockopt(3, SOL_SCTP, 0x75 /* SCTP_??? */, "\0\0\0\0\0\0\4\20", 8) = 0
connect(3, {sa_family=AF_INET6, sin6_port=htons(20003),
inet_pton(AF_INET6, "::1", &sin6_addr), sin6_flowinfo=0,
sin6_scope_id=0}, 28) = 0
setsockopt(3, SOL_SCTP, 0x77 /* SCTP_??? */,
"\0\0\0\0;\0)\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 734
CPU: 0 PID: 1358 Comm: skbuff-panic Not tainted
5.4.17-2136.301.0.el7uek.x86_64 #2
task: ffff880078bb5a00 task.stack: ffffc900006d8000
RIP: 0010:skb_panic+0x66/0x68
RSP: 0018:ffffc900006dbcf8 EFLAGS: 00010246
RAX: 0000000000000086 RBX: 0000000000000000 RCX: 0000000000000000
RDX: 0000000000000000 RSI: ffff88007e816938 RDI: ffff88007e816938
[ RBP: ffffc900006dbd18 R08: 00000000fffffffe R09: 00000000000001f6
R10: 0000000000000005 R11: 00000000000001f5 R12: ffff880078512d00
R13: 0000000000000052 R14: ffff88007827fc00 R15: 0000000000000070
FS: 00007f80be10a740(0000) GS:ffff88007e800000(0000)
knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00000000208c0000 CR3: 000000007937c000 CR4: 00000000000006f0
Call Trace:
skb_put+0x4c/0x4c
sctp_addto_chunk+0x59/0xb0 [sctp]
sctp_make_strreset_req+0x166/0x180 [sctp]
sctp_send_reset_streams+0x14d/0x300 [sctp]
sctp_setsockopt.part.21+0x101f/0x1720 [sctp]
sctp_setsockopt+0x99/0xb0 [sctp]
sock_common_setsockopt+0x1a/0x1c
SyS_setsockopt+0x86/0xe6
+0x79/0x1ae
entry_SYSCALL_64_after_hwframe+0x151/0x0
RIP: 0033:0x7f80bdc21be9
I am not familar with any of the sctp subsystem. It was found running
the syzkaller fuzzing test suite.
If there is a more appropriate place to report this I can do that too.
This test fails on just about every 4.x and 5.x kernel. It is not
unique to 5.4.
Thank you.
John.
===
// gcc -o test-sctp 317ef02b0d5cbd19d445294fed91453c7f970fc3.c
// autogenerated by syzkaller (https://github.com/google/syzkaller)
// 317ef02b0d5cbd19d445294fed91453c7f970fc3.c
#define _GNU_SOURCE
#include <arpa/inet.h>
#include <endian.h>
#include <fcntl.h>
#include <net/if.h>
#include <netinet/in.h>
#include <stdbool.h>
#include <stdint.h>
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <sys/socket.h>
#include <sys/syscall.h>
#include <sys/types.h>
#include <unistd.h>
#include <sched.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>
struct nlmsg {
char* pos;
int nesting;
struct nlattr* nested[8];
char buf[1024];
};
static struct nlmsg nlmsg;
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;
memcpy(attr + 1, data, size);
nlmsg->pos += NLMSG_ALIGN(attr->nla_len);
}
static int netlink_send_ext(struct nlmsg* nlmsg, int sock, uint16_t
reply_type,
int* reply_len)
{
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;
printf ("sending : %d\n", hdr->nlmsg_len);
unsigned n = sendto(sock, nlmsg->buf, hdr->nlmsg_len, 0,
(struct sockaddr*)&addr, sizeof(addr));
if (n != hdr->nlmsg_len)
exit(1);
n = recv(sock, nlmsg->buf, sizeof(nlmsg->buf), 0);
if (hdr->nlmsg_type == NLMSG_DONE) {
*reply_len = 0;
return 0;
}
if (n < sizeof(struct nlmsghdr))
exit(1);
if (reply_len && hdr->nlmsg_type == reply_type) {
*reply_len = n;
return 0;
}
if (n < sizeof(struct nlmsghdr) + sizeof(struct nlmsgerr))
exit(1);
if (hdr->nlmsg_type != NLMSG_ERROR)
exit(1);
return -((struct nlmsgerr*)(hdr + 1))->error;
}
static int netlink_send(struct nlmsg* nlmsg, int sock)
{
return netlink_send_ext(nlmsg, sock, 0, NULL);
}
static int netlink_next_msg(struct nlmsg* nlmsg, unsigned int offset,
unsigned int total_len)
{
struct nlmsghdr* hdr = (struct nlmsghdr*)(nlmsg->buf + offset);
if (offset == total_len || offset + hdr->nlmsg_len > total_len)
return -1;
return hdr->nlmsg_len;
}
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);
(void)err;
}
const int kInitNetNsFd = 239;
#define DEVLINK_FAMILY_NAME "devlink"
#define DEVLINK_CMD_PORT_GET 5
#define DEVLINK_CMD_RELOAD 37
#define DEVLINK_ATTR_BUS_NAME 1
#define DEVLINK_ATTR_DEV_NAME 2
#define DEVLINK_ATTR_NETDEV_NAME 7
#define DEVLINK_ATTR_NETNS_FD 138
static int netlink_devlink_id_get(struct nlmsg* nlmsg, int sock)
{
struct genlmsghdr genlhdr;
struct nlattr* attr;
int err, n;
uint16_t id = 0;
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, DEVLINK_FAMILY_NAME,
strlen(DEVLINK_FAMILY_NAME) + 1);
err = netlink_send_ext(nlmsg, sock, GENL_ID_CTRL, &n);
if (err) {
return -1;
}
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) {
return -1;
}
recv(sock, nlmsg->buf, sizeof(nlmsg->buf), 0); /* recv ack */
return id;
}
static void netlink_devlink_netns_move(const char* bus_name,
const char* dev_name, int netns_fd)
{
struct genlmsghdr genlhdr;
int sock;
int id, err;
sock = socket(AF_NETLINK, SOCK_RAW, NETLINK_GENERIC);
if (sock == -1)
exit(1);
id = netlink_devlink_id_get(&nlmsg, sock);
if (id == -1)
goto error;
memset(&genlhdr, 0, sizeof(genlhdr));
genlhdr.cmd = DEVLINK_CMD_RELOAD;
netlink_init(&nlmsg, id, 0, &genlhdr, sizeof(genlhdr));
netlink_attr(&nlmsg, DEVLINK_ATTR_BUS_NAME, bus_name,
strlen(bus_name) + 1);
netlink_attr(&nlmsg, DEVLINK_ATTR_DEV_NAME, dev_name,
strlen(dev_name) + 1);
netlink_attr(&nlmsg, DEVLINK_ATTR_NETNS_FD, &netns_fd, sizeof(netns_fd));
err = netlink_send(&nlmsg, sock);
if (err) {
}
error:
close(sock);
}
static struct nlmsg nlmsg2;
static void initialize_devlink_ports(const char* bus_name, const char*
dev_name,
const char* netdev_prefix)
{
struct genlmsghdr genlhdr;
int len, total_len, id, err, offset;
uint16_t netdev_index;
int sock = socket(AF_NETLINK, SOCK_RAW, NETLINK_GENERIC);
if (sock == -1)
exit(1);
int rtsock = socket(AF_NETLINK, SOCK_RAW, NETLINK_ROUTE);
if (rtsock == -1)
exit(1);
id = netlink_devlink_id_get(&nlmsg, sock);
if (id == -1)
goto error;
memset(&genlhdr, 0, sizeof(genlhdr));
genlhdr.cmd = DEVLINK_CMD_PORT_GET;
netlink_init(&nlmsg, id, NLM_F_DUMP, &genlhdr, sizeof(genlhdr));
netlink_attr(&nlmsg, DEVLINK_ATTR_BUS_NAME, bus_name,
strlen(bus_name) + 1);
netlink_attr(&nlmsg, DEVLINK_ATTR_DEV_NAME, dev_name,
strlen(dev_name) + 1);
err = netlink_send_ext(&nlmsg, sock, id, &total_len);
if (err) {
goto error;
}
offset = 0;
netdev_index = 0;
while ((len = netlink_next_msg(&nlmsg, offset, total_len)) != -1) {
struct nlattr* attr = (struct nlattr*)(nlmsg.buf + offset +
NLMSG_HDRLEN +
NLMSG_ALIGN(sizeof(genlhdr)));
for (; (char*)attr < nlmsg.buf + offset + len;
attr = (struct nlattr*)((char*)attr +
NLMSG_ALIGN(attr->nla_len))) {
if (attr->nla_type == DEVLINK_ATTR_NETDEV_NAME) {
char* port_name;
char netdev_name[IFNAMSIZ];
port_name = (char*)(attr + 1);
snprintf(netdev_name, sizeof(netdev_name), "%s%d", netdev_prefix,
netdev_index);
netlink_device_change(&nlmsg2, rtsock, port_name, true, 0, 0, 0,
netdev_name);
break;
}
}
offset += len;
netdev_index++;
}
error:
close(rtsock);
close(sock);
}
static void initialize_devlink_pci(void)
{
int netns = open("/proc/self/ns/net", O_RDONLY);
if (netns == -1)
exit(1);
int ret = setns(kInitNetNsFd, 0);
if (ret == -1)
exit(1);
netlink_devlink_netns_move("pci", "0000:00:10.0", netns);
ret = setns(netns, 0);
if (ret == -1)
exit(1);
close(netns);
initialize_devlink_ports("pci", "0000:00:10.0", "netpci");
}
uint64_t r[1] = {0xffffffffffffffff};
int main(void)
{
syscall(__NR_mmap, 0x20000000ul, 0x1000000ul, 3ul, 0x32ul, -1, 0);
intptr_t res = 0;
res = syscall(__NR_socket, 0xaul, 0x80000000000001ul, 0x84ul);
if (res != -1)
r[0] = res;
*(uint32_t*)0x20444ff8 = 0;
*(uint32_t*)0x20444ffc = 7;
syscall(__NR_setsockopt, r[0], 0x84ul, 0x76ul, 0x20444ff8ul, 8ul);
*(uint16_t*)0x20cf6fe4 = 0xa;
*(uint16_t*)0x20cf6fe6 = htobe16(0x4e23);
*(uint32_t*)0x20cf6fe8 = htobe32(0);
*(uint64_t*)0x20cf6fec = htobe64(0);
*(uint64_t*)0x20cf6ff4 = htobe64(1);
*(uint32_t*)0x20cf6ffc = 0;
syscall(__NR_setsockopt, r[0], 0x84ul, 0x64ul, 0x20cf6fe4ul, 0x1cul);
*(uint32_t*)0x20107ff8 = 0;
*(uint32_t*)0x20107ffc = 0x10040000;
syscall(__NR_setsockopt, r[0], 0x84ul, 0x75ul, 0x20107ff8ul, 8ul);
*(uint16_t*)0x208c0000 = 0xa;
*(uint16_t*)0x208c0002 = htobe16(0x4e23);
*(uint32_t*)0x208c0004 = htobe32(0);
*(uint64_t*)0x208c0008 = htobe64(0);
*(uint64_t*)0x208c0010 = htobe64(1);
*(uint32_t*)0x208c0018 = 0;
syscall(__NR_connect, r[0], 0x208c0000ul, 0x1cul);
*(uint32_t*)0x2081e000 = 0;
*(uint16_t*)0x2081e004 = 0x3b;
*(uint16_t*)0x2081e006 = 0x29;
*(uint16_t*)0x2081e008 = 0;
syscall(__NR_setsockopt, r[0], 0x84ul, 0x77ul, 0x2081e000ul, 0x2deul);
return 0;
}
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: syzkaller test panic: Linux 5.4.y
2021-10-18 21:29 syzkaller test panic: Linux 5.4.y john.p.donnelly
@ 2021-10-19 15:24 ` mleitner
2021-10-19 20:05 ` john.p.donnelly
0 siblings, 1 reply; 6+ messages in thread
From: mleitner @ 2021-10-19 15:24 UTC (permalink / raw)
To: john.p.donnelly; +Cc: linux-sctp
Hi John,
On Mon, Oct 18, 2021 at 04:29:58PM -0500, john.p.donnelly@oracle.com wrote:
> Call Trace:
> skb_put+0x4c/0x4c
> sctp_addto_chunk+0x59/0xb0 [sctp]
> sctp_make_strreset_req+0x166/0x180 [sctp]
> sctp_send_reset_streams+0x14d/0x300 [sctp]
> sctp_setsockopt.part.21+0x101f/0x1720 [sctp]
> sctp_setsockopt+0x99/0xb0 [sctp]
> sock_common_setsockopt+0x1a/0x1c
> SyS_setsockopt+0x86/0xe6
> +0x79/0x1ae
> entry_SYSCALL_64_after_hwframe+0x151/0x0
> RIP: 0033:0x7f80bdc21be9
>
>
> I am not familar with any of the sctp subsystem. It was found running the
> syzkaller fuzzing test suite.
>
> If there is a more appropriate place to report this I can do that too. This
Here is fine :)
> test fails on just about every 4.x and 5.x kernel. It is not
> unique to 5.4.
Did the test kernels include commit "sctp: account stream padding
length for reconf chunk"? It is a recent fix right on this topic. It
should be fixed by it, actually.
Marcelo
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: syzkaller test panic: Linux 5.4.y
2021-10-19 15:24 ` mleitner
@ 2021-10-19 20:05 ` john.p.donnelly
2021-10-19 21:35 ` Marcelo Ricardo Leitner
0 siblings, 1 reply; 6+ messages in thread
From: john.p.donnelly @ 2021-10-19 20:05 UTC (permalink / raw)
To: mleitner; +Cc: linux-sctp
On 10/19/21 10:24 AM, mleitner@redhat.com wrote:
> Hi John,
>
> On Mon, Oct 18, 2021 at 04:29:58PM -0500, john.p.donnelly@oracle.com wrote:
>> Call Trace:
>> skb_put+0x4c/0x4c
>> sctp_addto_chunk+0x59/0xb0 [sctp]
>> sctp_make_strreset_req+0x166/0x180 [sctp]
>> sctp_send_reset_streams+0x14d/0x300 [sctp]
>> sctp_setsockopt.part.21+0x101f/0x1720 [sctp]
>> sctp_setsockopt+0x99/0xb0 [sctp]
>> sock_common_setsockopt+0x1a/0x1c
>> SyS_setsockopt+0x86/0xe6
>> +0x79/0x1ae
>> entry_SYSCALL_64_after_hwframe+0x151/0x0
>> RIP: 0033:0x7f80bdc21be9
>>
>>
>> I am not familar with any of the sctp subsystem. It was found running the
>> syzkaller fuzzing test suite.
>>
>> If there is a more appropriate place to report this I can do that too. This
>
> Here is fine :)
>
>> test fails on just about every 4.x and 5.x kernel. It is not
>> unique to 5.4.
>
> Did the test kernels include commit "sctp: account stream padding
> length for reconf chunk"? It is a recent fix right on this topic. It
> should be fixed by it, actually.
>
> Marcelo
>
Hi Marcelo
I can confirm
commit a2d859e3fc97e79d907761550dbc03ff1b36479c
Author: Eiichi Tsukata <eiichi.tsukata@nutanix.com>
Date: Wed Oct 13 17:27:29 2021 -0300
sctp: account stream padding length for reconf chunk
resolves my panic for 5.4.LTS wrt to
// autogenerated by syzkaller (https://github.com/google/syzkaller)
// 317ef02b0d5cbd19d445294fed91453c7f970fc3.c
Should be an easy enough fix to apply to older 4.x kernels too.
There is suppose to be a format to cc the syz-kaller bot to mark
317ef02b0d5cbd19d445294fed91453c7f970fc3 fixed with commit
a2d859e3fc97e79d907761550dbc03ff1b36479c.
Perhaps mentioning it here will be enough ;-) .
Thanks for the quick follow up !
--
JD
Oracle Linux Team.
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: syzkaller test panic: Linux 5.4.y
2021-10-19 20:05 ` john.p.donnelly
@ 2021-10-19 21:35 ` Marcelo Ricardo Leitner
2021-10-19 21:41 ` john.p.donnelly
2021-10-20 15:12 ` john.p.donnelly
0 siblings, 2 replies; 6+ messages in thread
From: Marcelo Ricardo Leitner @ 2021-10-19 21:35 UTC (permalink / raw)
To: john.p.donnelly; +Cc: linux-sctp, Eiichi Tsukata
On Tue, Oct 19, 2021 at 03:05:24PM -0500, john.p.donnelly@oracle.com wrote:
> On 10/19/21 10:24 AM, mleitner@redhat.com wrote:
> > Hi John,
> >
> > On Mon, Oct 18, 2021 at 04:29:58PM -0500, john.p.donnelly@oracle.com wrote:
> > > Call Trace:
> > > skb_put+0x4c/0x4c
> > > sctp_addto_chunk+0x59/0xb0 [sctp]
> > > sctp_make_strreset_req+0x166/0x180 [sctp]
> > > sctp_send_reset_streams+0x14d/0x300 [sctp]
> > > sctp_setsockopt.part.21+0x101f/0x1720 [sctp]
> > > sctp_setsockopt+0x99/0xb0 [sctp]
> > > sock_common_setsockopt+0x1a/0x1c
> > > SyS_setsockopt+0x86/0xe6
> > > +0x79/0x1ae
> > > entry_SYSCALL_64_after_hwframe+0x151/0x0
> > > RIP: 0033:0x7f80bdc21be9
> > >
> > >
> > > I am not familar with any of the sctp subsystem. It was found running the
> > > syzkaller fuzzing test suite.
> > >
> > > If there is a more appropriate place to report this I can do that too. This
> >
> > Here is fine :)
> >
> > > test fails on just about every 4.x and 5.x kernel. It is not
> > > unique to 5.4.
> >
> > Did the test kernels include commit "sctp: account stream padding
> > length for reconf chunk"? It is a recent fix right on this topic. It
> > should be fixed by it, actually.
> >
> > Marcelo
> >
>
>
> Hi Marcelo
>
> I can confirm
>
>
> commit a2d859e3fc97e79d907761550dbc03ff1b36479c
> Author: Eiichi Tsukata <eiichi.tsukata@nutanix.com>
> Date: Wed Oct 13 17:27:29 2021 -0300
>
> sctp: account stream padding length for reconf chunk
>
> resolves my panic for 5.4.LTS wrt to
>
> // autogenerated by syzkaller (https://github.com/google/syzkaller)
> // 317ef02b0d5cbd19d445294fed91453c7f970fc3.c
>
Sweet!
>
>
> Should be an easy enough fix to apply to older 4.x kernels too.
Right. It's currently scheduled for:
812 C out 18 Greg Kroah-Hart (1,7K) [PATCH 4.14 26/39] sctp:
account stream padding length for re
813 C out 18 Greg Kroah-Hart (1,7K) [PATCH 4.19 33/50] sctp:
account stream padding length for re
814 C out 18 Greg Kroah-Hart (1,7K) [PATCH 5.4 45/69] sctp: account
stream padding length for rec
815 C out 18 Greg Kroah-Hart (1,7K) [PATCH 5.10 068/103] sctp:
account stream padding length for
817 C out 18 Greg Kroah-Hart (1,7K) [PATCH 5.14 098/151] sctp:
account stream padding length for
>
> There is suppose to be a format to cc the syz-kaller bot to mark
> 317ef02b0d5cbd19d445294fed91453c7f970fc3 fixed with commit
> a2d859e3fc97e79d907761550dbc03ff1b36479c.
>
> Perhaps mentioning it here will be enough ;-) .
Almost :-)
The report I previously had for this issue didn't come from syzkaller.
I'm not sure if 317ef02 above refers to the Google's instance of what.
Anyway, would mind marking it as fixed then?
Thanks!
Marcelo
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: syzkaller test panic: Linux 5.4.y
2021-10-19 21:35 ` Marcelo Ricardo Leitner
@ 2021-10-19 21:41 ` john.p.donnelly
2021-10-20 15:12 ` john.p.donnelly
1 sibling, 0 replies; 6+ messages in thread
From: john.p.donnelly @ 2021-10-19 21:41 UTC (permalink / raw)
To: Marcelo Ricardo Leitner; +Cc: linux-sctp, Eiichi Tsukata
>> There is suppose to be a format to cc the syz-kaller bot to mark
>> 317ef02b0d5cbd19d445294fed91453c7f970fc3 fixed with commit
>> a2d859e3fc97e79d907761550dbc03ff1b36479c.
>>
>> Perhaps mentioning it here will be enough ;-) .
>
> Almost :-)
>
> The report I previously had for this issue didn't come from syzkaller.
> I'm not sure if 317ef02 above refers to the Google's instance of what.
> Anyway, would mind marking it as fixed then?
>
>
317ef02b0d5cbd19d445294fed91453c7f970fc3 ".c " is the test identifier.
It is the 1st thing people search for in a syzkaller bug-fix hunt ;-)
==
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: syzkaller test panic: Linux 5.4.y
2021-10-19 21:35 ` Marcelo Ricardo Leitner
2021-10-19 21:41 ` john.p.donnelly
@ 2021-10-20 15:12 ` john.p.donnelly
1 sibling, 0 replies; 6+ messages in thread
From: john.p.donnelly @ 2021-10-20 15:12 UTC (permalink / raw)
To: Marcelo Ricardo Leitner; +Cc: linux-sctp, Eiichi Tsukata
On 10/19/21 4:35 PM, Marcelo Ricardo Leitner wrote:
> On Tue, Oct 19, 2021 at 03:05:24PM -0500, john.p.donnelly@oracle.com wrote:
>> On 10/19/21 10:24 AM, mleitner@redhat.com wrote:
>>> Hi John,
>>>
>>> On Mon, Oct 18, 2021 at 04:29:58PM -0500, john.p.donnelly@oracle.com wrote:
>>>> Call Trace:
>>>> skb_put+0x4c/0x4c
>>>> sctp_addto_chunk+0x59/0xb0 [sctp]
>>>> sctp_make_strreset_req+0x166/0x180 [sctp]
>>>> sctp_send_reset_streams+0x14d/0x300 [sctp]
>>>> sctp_setsockopt.part.21+0x101f/0x1720 [sctp]
>>>> sctp_setsockopt+0x99/0xb0 [sctp]
>>>> sock_common_setsockopt+0x1a/0x1c
>>>> SyS_setsockopt+0x86/0xe6
>>>> +0x79/0x1ae
>>>> entry_SYSCALL_64_after_hwframe+0x151/0x0
>>>> RIP: 0033:0x7f80bdc21be9
>>>>
>>>>
>>>> I am not familar with any of the sctp subsystem. It was found running the
>>>> syzkaller fuzzing test suite.
>>>>
>>>> If there is a more appropriate place to report this I can do that too. This
>>>
>>> Here is fine :)
>>>
>>>> test fails on just about every 4.x and 5.x kernel. It is not
>>>> unique to 5.4.
>>>
>>> Did the test kernels include commit "sctp: account stream padding
>>> length for reconf chunk"? It is a recent fix right on this topic. It
>>> should be fixed by it, actually.
>>>
>>> Marcelo
>>>
>>
>>
>> Hi Marcelo
>>
>> I can confirm
>>
>>
>> commit a2d859e3fc97e79d907761550dbc03ff1b36479c
>> Author: Eiichi Tsukata <eiichi.tsukata@nutanix.com>
>> Date: Wed Oct 13 17:27:29 2021 -0300
>>
>> sctp: account stream padding length for reconf chunk
>>
>> resolves my panic for 5.4.LTS wrt to
>>
>> // autogenerated by syzkaller (https://urldefense.com/v3/__https://github.com/google/syzkaller__;!!ACWV5N9M2RV99hQ!bYZk3duFK90mfRvslAzHqUwzeJ2ngHYB0GMAZN3BITINKgzfZfAd5w8W5_OXRmoc_wDB$ )
>> // 317ef02b0d5cbd19d445294fed91453c7f970fc3.c
>>
>
> Sweet!
>
>>
>>
>> Should be an easy enough fix to apply to older 4.x kernels too.
>
> Right. It's currently scheduled for:
> 812 C out 18 Greg Kroah-Hart (1,7K) [PATCH 4.14 26/39] sctp:
> account stream padding length for re
> 813 C out 18 Greg Kroah-Hart (1,7K) [PATCH 4.19 33/50] sctp:
> account stream padding length for re
> 814 C out 18 Greg Kroah-Hart (1,7K) [PATCH 5.4 45/69] sctp: account
> stream padding length for rec
> 815 C out 18 Greg Kroah-Hart (1,7K) [PATCH 5.10 068/103] sctp:
> account stream padding length for
> 817 C out 18 Greg Kroah-Hart (1,7K) [PATCH 5.14 098/151] sctp:
> account stream padding length for
>
>>
>> There is suppose to be a format to cc the syz-kaller bot to mark
>> 317ef02b0d5cbd19d445294fed91453c7f970fc3 fixed with commit
>> a2d859e3fc97e79d907761550dbc03ff1b36479c.
>>
>> Perhaps mentioning it here will be enough ;-) .
>
> Almost :-)
>
> The report I previously had for this issue didn't come from syzkaller.
> I'm not sure if 317ef02 above refers to the Google's instance of what.
> Anyway, would mind marking it as fixed then?
>
> Thanks!
> Marcelo
>
Hi Marcelo,
I posted this fix to syzkaller google group list :
https://groups.google.com/g/syzkaller-bugs/c/8fwxxnZxy4s
Since you fixing it in so many LTS threads I suspect it is covered for
the most part.
Thank you && all the best !
JD
...
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2021-10-20 15:13 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2021-10-18 21:29 syzkaller test panic: Linux 5.4.y john.p.donnelly
2021-10-19 15:24 ` mleitner
2021-10-19 20:05 ` john.p.donnelly
2021-10-19 21:35 ` Marcelo Ricardo Leitner
2021-10-19 21:41 ` john.p.donnelly
2021-10-20 15:12 ` john.p.donnelly
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).