* Re: [PATCH v4 net] af_packet: Block execution of tasks waiting for transmit to complete in AF_PACKET
From: David Miller @ 2019-06-27 2:38 UTC (permalink / raw)
To: nhorman; +Cc: netdev, mcroce, willemdebruijn.kernel
In-Reply-To: <20190625215749.22840-1-nhorman@tuxdriver.com>
From: Neil Horman <nhorman@tuxdriver.com>
Date: Tue, 25 Jun 2019 17:57:49 -0400
> When an application is run that:
> a) Sets its scheduler to be SCHED_FIFO
> and
> b) Opens a memory mapped AF_PACKET socket, and sends frames with the
> MSG_DONTWAIT flag cleared, its possible for the application to hang
> forever in the kernel. This occurs because when waiting, the code in
> tpacket_snd calls schedule, which under normal circumstances allows
> other tasks to run, including ksoftirqd, which in some cases is
> responsible for freeing the transmitted skb (which in AF_PACKET calls a
> destructor that flips the status bit of the transmitted frame back to
> available, allowing the transmitting task to complete).
>
> However, when the calling application is SCHED_FIFO, its priority is
> such that the schedule call immediately places the task back on the cpu,
> preventing ksoftirqd from freeing the skb, which in turn prevents the
> transmitting task from detecting that the transmission is complete.
>
> We can fix this by converting the schedule call to a completion
> mechanism. By using a completion queue, we force the calling task, when
> it detects there are no more frames to send, to schedule itself off the
> cpu until such time as the last transmitted skb is freed, allowing
> forward progress to be made.
>
> Tested by myself and the reporter, with good results
>
> Appies to the net tree
>
> Signed-off-by: Neil Horman <nhorman@tuxdriver.com>
> Reported-by: Matteo Croce <mcroce@redhat.com>
> CC: "David S. Miller" <davem@davemloft.net>
> CC: Willem de Bruijn <willemdebruijn.kernel@gmail.com>
...
Applied and queued up for -stable.
^ permalink raw reply
* Re: [PATCH bpf-next] virtio_net: add XDP meta data support in receive_small()
From: Jason Wang @ 2019-06-27 2:40 UTC (permalink / raw)
To: Yuya Kusakabe, davem
Cc: netdev, ast, daniel, jakub.kicinski, hawk, john.fastabend,
Michael S. Tsirkin
In-Reply-To: <20190627023332.8557-1-yuya.kusakabe@gmail.com>
On 2019/6/27 上午10:33, Yuya Kusakabe wrote:
> This adds XDP meta data support to the code path receive_small().
>
> mrg_rxbuf=off is required on qemu, because receive_mergeable() still
> doesn't support XDP meta data.
What's the reason for this?
>
> Fixes: de8f3a83b0a0 ("bpf: add meta pointer for direct access")
> Signed-off-by: Yuya Kusakabe <yuya.kusakabe@gmail.com>
Could you please cc virtio maintainer through get_maintainer.pl?
Thanks
> ---
> drivers/net/virtio_net.c | 10 ++++++++--
> 1 file changed, 8 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/net/virtio_net.c b/drivers/net/virtio_net.c
> index 4f3de0ac8b0b..14165c5edb7d 100644
> --- a/drivers/net/virtio_net.c
> +++ b/drivers/net/virtio_net.c
> @@ -644,6 +644,7 @@ static struct sk_buff *receive_small(struct net_device *dev,
> unsigned int delta = 0;
> struct page *xdp_page;
> int err;
> + unsigned int metasize = 0;
>
> len -= vi->hdr_len;
> stats->bytes += len;
> @@ -683,8 +684,8 @@ static struct sk_buff *receive_small(struct net_device *dev,
>
> xdp.data_hard_start = buf + VIRTNET_RX_PAD + vi->hdr_len;
> xdp.data = xdp.data_hard_start + xdp_headroom;
> - xdp_set_data_meta_invalid(&xdp);
> xdp.data_end = xdp.data + len;
> + xdp.data_meta = xdp.data;
> xdp.rxq = &rq->xdp_rxq;
> orig_data = xdp.data;
> act = bpf_prog_run_xdp(xdp_prog, &xdp);
> @@ -695,9 +696,11 @@ static struct sk_buff *receive_small(struct net_device *dev,
> /* Recalculate length in case bpf program changed it */
> delta = orig_data - xdp.data;
> len = xdp.data_end - xdp.data;
> + metasize = xdp.data - xdp.data_meta;
> break;
> case XDP_TX:
> stats->xdp_tx++;
> + xdp.data_meta = xdp.data;
> xdpf = convert_to_xdp_frame(&xdp);
> if (unlikely(!xdpf))
> goto err_xdp;
> @@ -735,11 +738,14 @@ static struct sk_buff *receive_small(struct net_device *dev,
> }
> skb_reserve(skb, headroom - delta);
> skb_put(skb, len);
> - if (!delta) {
> + if (!delta && !metasize) {
> buf += header_offset;
> memcpy(skb_vnet_hdr(skb), buf, vi->hdr_len);
> } /* keep zeroed vnet hdr since packet was changed by bpf */
>
> + if (metasize)
> + skb_metadata_set(skb, metasize);
> +
> err:
> return skb;
>
^ permalink raw reply
* [GIT] Networking
From: David Miller @ 2019-06-27 2:50 UTC (permalink / raw)
To: torvalds; +Cc: akpm, netdev, linux-kernel
1) Fix ppp_mppe crypto soft dependencies, from Takashi Iawi.
2) Fix TX completion to be finite, from Sergej Benilov.
3) Use register_pernet_device to avoid a dst leak in tipc, from Xin
Long.
4) Double free of TX cleanup in Dirk van der Merwe.
5) Memory leak in packet_set_ring(), from Eric Dumazet.
6) Out of bounds read in qmi_wwan, from Bjørn Mork.
7) Fix iif used in mcast/bcast looped back packets, from Stephen
Suryaputra.
8) Fix neighbour resolution on raw ipv6 sockets, from Nicolas Dichtel.
Please pull, thanks a lot!
The following changes since commit c356dc4b540edd6c02b409dd8cf3208ba2804c38:
Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/net (2019-06-21 22:23:35 -0700)
are available in the Git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/davem/net
for you to fetch changes up to 89ed5b519004a7706f50b70f611edbd3aaacff2c:
af_packet: Block execution of tasks waiting for transmit to complete in AF_PACKET (2019-06-26 19:38:29 -0700)
----------------------------------------------------------------
Antoine Tenart (1):
net: macb: do not copy the mac address if NULL
Bjørn Mork (1):
qmi_wwan: Fix out-of-bounds read
David S. Miller (2):
Merge branch 'smc-fixes'
Merge branch 'ipv6-fix-neighbour-resolution-with-raw-socket'
Dirk van der Merwe (1):
net/tls: fix page double free on TX cleanup
Dmitry Bogdanov (1):
net: aquantia: fix vlans not working over bridged network
Eiichi Tsukata (1):
net/ipv6: Fix misuse of proc_dointvec "skip_notify_on_dev_down"
Eric Dumazet (1):
net/packet: fix memory leak in packet_set_ring()
Huaping Zhou (1):
net/smc: hold conns_lock before calling smc_lgr_register_conn()
Marek Vasut (1):
net: dsa: microchip: Use gpiod_set_value_cansleep()
Neil Horman (1):
af_packet: Block execution of tasks waiting for transmit to complete in AF_PACKET
Nicolas Dichtel (2):
ipv6: constify rt6_nexthop()
ipv6: fix neighbour resolution with raw socket
Petr Oros (1):
be2net: fix link failure after ethtool offline test
Roland Hii (2):
net: stmmac: fixed new system time seconds value calculation
net: stmmac: set IC bit when transmitting frames with HW timestamp
Sergej Benilov (1):
sis900: fix TX completion
Stephen Suryaputra (2):
ipv4: Use return value of inet_iif() for __raw_v4_lookup in the while loop
ipv4: reset rt_iif for recirculated mcast/bcast out pkts
Takashi Iwai (1):
ppp: mppe: Add softdep to arc4
Xin Long (3):
tipc: change to use register_pernet_device
tipc: check msg->req data len in tipc_nl_compat_bearer_disable
sctp: change to hold sk after auth shkey is created successfully
YueHaibing (4):
net/sched: cbs: Fix error path of cbs_module_init
bonding: Always enable vlan tx offload
net/smc: Fix error path in smc_init
team: Always enable vlan tx offload
drivers/net/bonding/bond_main.c | 2 +-
drivers/net/dsa/microchip/ksz_common.c | 6 +++---
drivers/net/ethernet/aquantia/atlantic/aq_filters.c | 10 ++++++++--
drivers/net/ethernet/aquantia/atlantic/aq_nic.c | 1 +
drivers/net/ethernet/aquantia/atlantic/aq_nic.h | 1 +
drivers/net/ethernet/aquantia/atlantic/hw_atl/hw_atl_b0.c | 19 +++++++++++++------
drivers/net/ethernet/cadence/macb_main.c | 2 +-
drivers/net/ethernet/emulex/benet/be_ethtool.c | 28 ++++++++++++++++++++++------
drivers/net/ethernet/sis/sis900.c | 16 ++++++++--------
drivers/net/ethernet/stmicro/stmmac/stmmac_hwtstamp.c | 2 +-
drivers/net/ethernet/stmicro/stmmac/stmmac_main.c | 22 ++++++++++++++--------
drivers/net/ppp/ppp_mppe.c | 1 +
drivers/net/team/team.c | 2 +-
drivers/net/usb/qmi_wwan.c | 2 +-
drivers/net/vrf.c | 2 +-
include/net/ip6_route.h | 4 ++--
include/net/route.h | 1 +
include/net/tls.h | 15 ---------------
net/bluetooth/6lowpan.c | 4 ++--
net/ipv4/ip_output.c | 12 ++++++++++++
net/ipv4/raw.c | 2 +-
net/ipv4/route.c | 33 +++++++++++++++++++++++++++++++++
net/ipv6/ip6_output.c | 2 +-
net/ipv6/route.c | 5 +++--
net/netfilter/nf_flow_table_ip.c | 2 +-
net/packet/af_packet.c | 23 +++++++++++++++++++----
net/packet/internal.h | 1 +
net/sched/sch_cbs.c | 9 +++++++--
net/sctp/endpointola.c | 8 ++++----
net/smc/af_smc.c | 5 ++++-
net/smc/smc_core.c | 3 +++
net/tipc/core.c | 12 ++++++------
net/tipc/netlink_compat.c | 18 +++++++++++++++---
net/tls/tls_main.c | 3 ++-
34 files changed, 194 insertions(+), 84 deletions(-)
^ permalink raw reply
* Re: [PATCH net] sctp: not bind the socket in sctp_connect
From: Marcelo Ricardo Leitner @ 2019-06-27 2:59 UTC (permalink / raw)
To: Xin Long; +Cc: network dev, linux-sctp, davem, Neil Horman, syzkaller-bugs
In-Reply-To: <35a0e4f6ca68185117c6e5517d8ac924cc2f9d05.1561537899.git.lucien.xin@gmail.com>
On Wed, Jun 26, 2019 at 04:31:39PM +0800, Xin Long wrote:
> Now when sctp_connect() is called with a wrong sa_family, it binds
> to a port but doesn't set bp->port, then sctp_get_af_specific will
> return NULL and sctp_connect() returns -EINVAL.
>
> Then if sctp_bind() is called to bind to another port, the last
> port it has bound will leak due to bp->port is NULL by then.
>
> sctp_connect() doesn't need to bind ports, as later __sctp_connect
> will do it if bp->port is NULL. So remove it from sctp_connect().
> While at it, remove the unnecessary sockaddr.sa_family len check
> as it's already done in sctp_inet_connect.
>
> Fixes: 644fbdeacf1d ("sctp: fix the issue that flags are ignored when using kernel_connect")
> Reported-by: syzbot+079bf326b38072f849d9@syzkaller.appspotmail.com
> Signed-off-by: Xin Long <lucien.xin@gmail.com>
Please give me another day to review this one. Thanks.
^ permalink raw reply
* Re: [PATCH v2 0/4] Compile-test UAPI and kernel headers
From: Masahiro Yamada @ 2019-06-27 3:12 UTC (permalink / raw)
To: Linux Kbuild mailing list
Cc: Sam Ravnborg, Tony Luck, open list:DOCUMENTATION, John Fastabend,
Jonathan Corbet, Jakub Kicinski, linux-riscv, Daniel Borkmann,
xdp-newbies, Anton Vorontsov, Palmer Dabbelt, Matthias Brugger,
Song Liu, Yonghong Song, Michal Marek, Jesper Dangaard Brouer,
Martin KaFai Lau, moderated list:ARM/Mediatek SoC support,
linux-arm-kernel, Albert Ou, Colin Cross, David S. Miller,
Kees Cook, Alexei Starovoitov, Networking,
Linux Kernel Mailing List, bpf
In-Reply-To: <20190627014617.600-1-yamada.masahiro@socionext.com>
On Thu, Jun 27, 2019 at 10:49 AM Masahiro Yamada
<yamada.masahiro@socionext.com> wrote:
>
>
> 1/4: reworked v2.
>
> 2/4: fix a flaw I noticed when I was working on this series
>
> 3/4: maybe useful for 4/4 and in some other places
>
> 4/4: v2. compile as many headers as possible.
>
If you want to test this series,
please check:
git://git.kernel.org/pub/scm/linux/kernel/git/masahiroy/linux-kbuild.git
header-test-v2
> Changes in v2:
> - Add CONFIG_CPU_{BIG,LITTLE}_ENDIAN guard to avoid build error
> - Use 'header-test-' instead of 'no-header-test'
> - Avoid weird 'find' warning when cleaning
> - New patch
> - New patch
> - Add everything to test coverage, and exclude broken ones
> - Rename 'Makefile' to 'Kbuild'
> - Add CONFIG_KERNEL_HEADER_TEST option
>
> Masahiro Yamada (4):
> kbuild: compile-test UAPI headers to ensure they are self-contained
> kbuild: do not create wrappers for header-test-y
> kbuild: support header-test-pattern-y
> kbuild: compile-test kernel headers to ensure they are self-contained
>
> .gitignore | 1 -
> Documentation/dontdiff | 1 -
> Documentation/kbuild/makefiles.txt | 13 +-
> Makefile | 4 +-
> include/Kbuild | 1134 ++++++++++++++++++++++++++++
> init/Kconfig | 22 +
> scripts/Makefile.build | 10 +-
> scripts/Makefile.lib | 12 +-
> scripts/cc-system-headers.sh | 8 +
> usr/.gitignore | 1 -
> usr/Makefile | 2 +
> usr/include/.gitignore | 3 +
> usr/include/Makefile | 133 ++++
> 13 files changed, 1331 insertions(+), 13 deletions(-)
> create mode 100644 include/Kbuild
> create mode 100755 scripts/cc-system-headers.sh
> create mode 100644 usr/include/.gitignore
> create mode 100644 usr/include/Makefile
>
> --
> 2.17.1
>
--
Best Regards
Masahiro Yamada
^ permalink raw reply
* [Linux-kernel-mentees][PATCH v2] packet: Fix undefined behavior in bit shift
From: Jiunn Chang @ 2019-06-27 3:25 UTC (permalink / raw)
To: skhan; +Cc: linux-kernel-mentees, netdev, linux-kernel, davem
In-Reply-To: <20190627010137.5612-1-c0d1n61at3@gmail.com>
Shifting signed 32-bit value by 31 bits is undefined. Changing most
significant bit to unsigned.
Changes included in v2:
- use subsystem specific subject lines
- CC required mailing lists
Signed-off-by: Jiunn Chang <c0d1n61at3@gmail.com>
---
include/uapi/linux/if_packet.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/include/uapi/linux/if_packet.h b/include/uapi/linux/if_packet.h
index 467b654bd4c7..3d884d68eb30 100644
--- a/include/uapi/linux/if_packet.h
+++ b/include/uapi/linux/if_packet.h
@@ -123,7 +123,7 @@ struct tpacket_auxdata {
/* Rx and Tx ring - header status */
#define TP_STATUS_TS_SOFTWARE (1 << 29)
#define TP_STATUS_TS_SYS_HARDWARE (1 << 30) /* deprecated, never set */
-#define TP_STATUS_TS_RAW_HARDWARE (1 << 31)
+#define TP_STATUS_TS_RAW_HARDWARE (1U << 31)
/* Rx ring - feature request bits */
#define TP_FT_REQ_FILL_RXHASH 0x1
--
2.22.0
^ permalink raw reply related
* linux-next: manual merge of the net-next tree with the net tree
From: Stephen Rothwell @ 2019-06-27 3:26 UTC (permalink / raw)
To: David Miller, Networking
Cc: Linux Next Mailing List, Linux Kernel Mailing List,
Stephen Suryaputra, Lawrence Brakmo, Alexei Starovoitov
[-- Attachment #1: Type: text/plain, Size: 1719 bytes --]
Hi all,
Today's linux-next merge of the net-next tree got a conflict in:
net/ipv4/ip_output.c
between commit:
5b18f1289808 ("ipv4: reset rt_iif for recirculated mcast/bcast out pkts")
from the net tree and commit:
956fe2190820 ("bpf: Update BPF_CGROUP_RUN_PROG_INET_EGRESS calls")
from the net-next tree.
I fixed it up (I think - see below) and can carry the fix as necessary.
This is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging. You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.
--
Cheers,
Stephen Rothwell
diff --cc net/ipv4/ip_output.c
index 8c2ec35b6512,cdd6c3418b9e..000000000000
--- a/net/ipv4/ip_output.c
+++ b/net/ipv4/ip_output.c
@@@ -322,7 -330,12 +331,26 @@@ static int ip_mc_finish_output(struct n
int ret;
ret = BPF_CGROUP_RUN_PROG_INET_EGRESS(sk, skb);
- if (ret) {
+ switch (ret) {
++ case NET_XMIT_SUCCESS:
++ case NET_XMIT_CN:
++ /* Reset rt_iif so that inet_iif() will return skb->skb_iif.
++ * Setting this to non-zero causes ipi_ifindex in in_pktinfo
++ * to be overwritten, see ipv4_pktinfo_prepare().
++ */
++ new_rt = rt_dst_clone(net->loopback_dev, skb_rtable(skb));
++ if (new_rt) {
++ new_rt->rt_iif = 0;
++ skb_dst_drop(skb);
++ skb_dst_set(skb, &new_rt->dst);
++ }
++ }
++ switch (ret) {
+ case NET_XMIT_SUCCESS:
+ return dev_loopback_xmit(net, sk, skb);
+ case NET_XMIT_CN:
+ return dev_loopback_xmit(net, sk, skb) ? : ret;
+ default:
kfree_skb(skb);
return ret;
}
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* Re: [Linux-kernel-mentees][PATCH v2] packet: Fix undefined behavior in bit shift
From: Shuah Khan @ 2019-06-27 3:32 UTC (permalink / raw)
To: Jiunn Chang
Cc: linux-kernel-mentees, netdev, linux-kernel, davem,
skh >> Shuah Khan
In-Reply-To: <20190627032532.18374-2-c0d1n61at3@gmail.com>
On 6/26/19 9:25 PM, Jiunn Chang wrote:
> Shifting signed 32-bit value by 31 bits is undefined. Changing most
> significant bit to unsigned.
>
> Changes included in v2:
> - use subsystem specific subject lines
> - CC required mailing lists
>
These version change lines don't belong in the change log.
> Signed-off-by: Jiunn Chang <c0d1n61at3@gmail.com>
> ---
Move them here.
> include/uapi/linux/if_packet.h | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/include/uapi/linux/if_packet.h b/include/uapi/linux/if_packet.h
> index 467b654bd4c7..3d884d68eb30 100644
> --- a/include/uapi/linux/if_packet.h
> +++ b/include/uapi/linux/if_packet.h
> @@ -123,7 +123,7 @@ struct tpacket_auxdata {
> /* Rx and Tx ring - header status */
> #define TP_STATUS_TS_SOFTWARE (1 << 29)
> #define TP_STATUS_TS_SYS_HARDWARE (1 << 30) /* deprecated, never set */
> -#define TP_STATUS_TS_RAW_HARDWARE (1 << 31)
> +#define TP_STATUS_TS_RAW_HARDWARE (1U << 31)
>
> /* Rx ring - feature request bits */
> #define TP_FT_REQ_FILL_RXHASH 0x1
>
thanks,
-- Shuah
^ permalink raw reply
* Reminder: 4 open syzbot bugs in "net/ax25" subsystem
From: Eric Biggers @ 2019-06-27 3:47 UTC (permalink / raw)
To: linux-hams, netdev, Ralf Baechle, David S. Miller
Cc: linux-kernel, syzkaller-bugs
[This email was generated by a script. Let me know if you have any suggestions
to make it better.]
Of the currently open syzbot reports against the upstream kernel, I've manually
marked 4 of them as possibly being bugs in the "net/ax25" subsystem. I've
listed these reports below, sorted by an algorithm that tries to list first the
reports most likely to be still valid, important, and actionable.
If you believe a bug is no longer valid, please close the syzbot report by
sending a '#syz fix', '#syz dup', or '#syz invalid' command in reply to the
original thread, as explained at https://goo.gl/tpsmEJ#status
If you believe I misattributed a bug to the "net/ax25" subsystem, please let me
know, and if possible forward the report to the correct people or mailing list.
Here are the bugs:
--------------------------------------------------------------------------------
Title: general protection fault in ax25_send_frame
Last occurred: 0 days ago
Reported: 177 days ago
Branches: Mainline and others
Dashboard link: https://syzkaller.appspot.com/bug?id=1cdd5b120f129364fc8e9b2b027826cf99fa696e
Original thread: https://lkml.kernel.org/lkml/0000000000009ea37c057e58d787@google.com/T/#u
Unfortunately, this bug does not have a reproducer.
No one replied to the original thread for this bug.
If you fix this bug, please add the following tag to the commit:
Reported-by: syzbot+e0b81535a27b8be39502@syzkaller.appspotmail.com
If you send any email or patch for this bug, please consider replying to the
original thread. For the git send-email command to use, or tips on how to reply
if the thread isn't in your mailbox, see the "Reply instructions" at
https://lkml.kernel.org/r/0000000000009ea37c057e58d787@google.com
--------------------------------------------------------------------------------
Title: KASAN: stack-out-of-bounds Write in ax25_getname
Last occurred: 63 days ago
Reported: 179 days ago
Branches: Mainline and others
Dashboard link: https://syzkaller.appspot.com/bug?id=fb195f91dc044978c1b186f1288b1eff61edcc20
Original thread: https://lkml.kernel.org/lkml/000000000000ed4120057e2df0c6@google.com/T/#u
This bug has a syzkaller reproducer only.
No one replied to the original thread for this bug.
If you fix this bug, please add the following tag to the commit:
Reported-by: syzbot+6a29097222b4d3b8617c@syzkaller.appspotmail.com
If you send any email or patch for this bug, please consider replying to the
original thread. For the git send-email command to use, or tips on how to reply
if the thread isn't in your mailbox, see the "Reply instructions" at
https://lkml.kernel.org/r/000000000000ed4120057e2df0c6@google.com
--------------------------------------------------------------------------------
Title: inconsistent lock state in ax25_std_heartbeat_expiry
Last occurred: 95 days ago
Reported: 93 days ago
Branches: net
Dashboard link: https://syzkaller.appspot.com/bug?id=9086a8eac930890b2730d6441093bd478e32913f
Original thread: https://lkml.kernel.org/lkml/0000000000001b07250584efbee3@google.com/T/#u
Unfortunately, this bug does not have a reproducer.
The original thread for this bug received 2 replies; the last was 92 days ago.
If you fix this bug, please add the following tag to the commit:
Reported-by: syzbot+e350b81e95a6a214da8a@syzkaller.appspotmail.com
If you send any email or patch for this bug, please consider replying to the
original thread. For the git send-email command to use, or tips on how to reply
if the thread isn't in your mailbox, see the "Reply instructions" at
https://lkml.kernel.org/r/0000000000001b07250584efbee3@google.com
--------------------------------------------------------------------------------
Title: general protection fault in ax25_send_control
Last occurred: 170 days ago
Reported: 169 days ago
Branches: net-next
Dashboard link: https://syzkaller.appspot.com/bug?id=bacca5f8fe81f2486fb73fd9e130a3035dc46594
Original thread: https://lkml.kernel.org/lkml/00000000000077264c057eec9ddd@google.com/T/#u
Unfortunately, this bug does not have a reproducer.
No one replied to the original thread for this bug.
If you fix this bug, please add the following tag to the commit:
Reported-by: syzbot+d0b03d6dbe11a950e0ce@syzkaller.appspotmail.com
If you send any email or patch for this bug, please consider replying to the
original thread. For the git send-email command to use, or tips on how to reply
if the thread isn't in your mailbox, see the "Reply instructions" at
https://lkml.kernel.org/r/00000000000077264c057eec9ddd@google.com
^ permalink raw reply
* Reminder: 3 open syzbot bugs in "net/rose" subsystem
From: Eric Biggers @ 2019-06-27 3:47 UTC (permalink / raw)
To: linux-hams, netdev, Ralf Baechle, David S. Miller
Cc: linux-kernel, syzkaller-bugs
[This email was generated by a script. Let me know if you have any suggestions
to make it better.]
Of the currently open syzbot reports against the upstream kernel, I've manually
marked 3 of them as possibly being bugs in the "net/rose" subsystem. I've
listed these reports below, sorted by an algorithm that tries to list first the
reports most likely to be still valid, important, and actionable.
If you believe a bug is no longer valid, please close the syzbot report by
sending a '#syz fix', '#syz dup', or '#syz invalid' command in reply to the
original thread, as explained at https://goo.gl/tpsmEJ#status
If you believe I misattributed a bug to the "net/rose" subsystem, please let me
know, and if possible forward the report to the correct people or mailing list.
Here are the bugs:
--------------------------------------------------------------------------------
Title: general protection fault in rose_send_frame
Last occurred: 0 days ago
Reported: 167 days ago
Branches: Mainline and others
Dashboard link: https://syzkaller.appspot.com/bug?id=f46c94afb217ab49c75350adbd467d86ae2b59a6
Original thread: https://lkml.kernel.org/lkml/00000000000089904d057f1e0ae0@google.com/T/#u
This bug has a C reproducer.
No one replied to the original thread for this bug.
If you fix this bug, please add the following tag to the commit:
Reported-by: syzbot+7078ae989d857fe17988@syzkaller.appspotmail.com
If you send any email or patch for this bug, please consider replying to the
original thread. For the git send-email command to use, or tips on how to reply
if the thread isn't in your mailbox, see the "Reply instructions" at
https://lkml.kernel.org/r/00000000000089904d057f1e0ae0@google.com
--------------------------------------------------------------------------------
Title: INFO: rcu detected stall in rose_loopback_timer (2)
Last occurred: 19 days ago
Reported: 17 days ago
Branches: net
Dashboard link: https://syzkaller.appspot.com/bug?id=42c06438fe5956ab9978486a1898ca2f23b1fc1f
Original thread: https://lkml.kernel.org/lkml/000000000000cf98fa058adf3615@google.com/T/#u
Unfortunately, this bug does not have a reproducer.
No one has replied to the original thread for this bug yet.
If you fix this bug, please add the following tag to the commit:
Reported-by: syzbot+d37efb0ca1b82682326e@syzkaller.appspotmail.com
If you send any email or patch for this bug, please consider replying to the
original thread. For the git send-email command to use, or tips on how to reply
if the thread isn't in your mailbox, see the "Reply instructions" at
https://lkml.kernel.org/r/000000000000cf98fa058adf3615@google.com
--------------------------------------------------------------------------------
Title: INFO: rcu detected stall in rose_connect
Last occurred: 25 days ago
Reported: 22 days ago
Branches: net-next
Dashboard link: https://syzkaller.appspot.com/bug?id=0b258dc8ece5bb93dfb5a137ae25a6db300d5892
Original thread: https://lkml.kernel.org/lkml/00000000000017b026058a785790@google.com/T/#u
Unfortunately, this bug does not have a reproducer.
No one has replied to the original thread for this bug yet.
If you fix this bug, please add the following tag to the commit:
Reported-by: syzbot+af81c7a21a31b18bec0e@syzkaller.appspotmail.com
If you send any email or patch for this bug, please consider replying to the
original thread. For the git send-email command to use, or tips on how to reply
if the thread isn't in your mailbox, see the "Reply instructions" at
https://lkml.kernel.org/r/00000000000017b026058a785790@google.com
^ permalink raw reply
* Reminder: 7 open syzbot bugs in "net/netrom" subsystem
From: Eric Biggers @ 2019-06-27 3:50 UTC (permalink / raw)
To: linux-hams, netdev, Ralf Baechle, David S. Miller
Cc: linux-kernel, syzkaller-bugs
[This email was generated by a script. Let me know if you have any suggestions
to make it better.]
Of the currently open syzbot reports against the upstream kernel, I've manually
marked 7 of them as possibly being bugs in the "net/netrom" subsystem. I've
listed these reports below, sorted by an algorithm that tries to list first the
reports most likely to be still valid, important, and actionable.
Of these 7 bugs, 1 was seen in mainline in the last week.
If you believe a bug is no longer valid, please close the syzbot report by
sending a '#syz fix', '#syz dup', or '#syz invalid' command in reply to the
original thread, as explained at https://goo.gl/tpsmEJ#status
If you believe I misattributed a bug to the "net/netrom" subsystem, please let
me know, and if possible forward the report to the correct people or mailing
list.
Here are the bugs:
--------------------------------------------------------------------------------
Title: general protection fault in prepare_to_wait
Last occurred: 1 day ago
Reported: 174 days ago
Branches: Mainline and others
Dashboard link: https://syzkaller.appspot.com/bug?id=c670fb9da2ce08f7b5101baa9426083b39ee9f90
Original thread: https://lkml.kernel.org/lkml/000000000000fa6a2c057e8b7064@google.com/T/#u
This bug has a C reproducer.
No one replied to the original thread for this bug.
If you fix this bug, please add the following tag to the commit:
Reported-by: syzbot+55f9d3e51d49e20b2ce5@syzkaller.appspotmail.com
If you send any email or patch for this bug, please consider replying to the
original thread. For the git send-email command to use, or tips on how to reply
if the thread isn't in your mailbox, see the "Reply instructions" at
https://lkml.kernel.org/r/000000000000fa6a2c057e8b7064@google.com
--------------------------------------------------------------------------------
Title: memory leak in nr_create
Last occurred: 7 days ago
Reported: 30 days ago
Branches: Mainline
Dashboard link: https://syzkaller.appspot.com/bug?id=24be997a573ef9d497d6d7302518779b75d8119a
Original thread: https://lkml.kernel.org/lkml/0000000000009412c60589e804d8@google.com/T/#u
This bug has a C reproducer.
No one has replied to the original thread for this bug yet.
If you fix this bug, please add the following tag to the commit:
Reported-by: syzbot+10f1194569953b72f1ae@syzkaller.appspotmail.com
If you send any email or patch for this bug, please consider replying to the
original thread. For the git send-email command to use, or tips on how to reply
if the thread isn't in your mailbox, see the "Reply instructions" at
https://lkml.kernel.org/r/0000000000009412c60589e804d8@google.com
--------------------------------------------------------------------------------
Title: memory leak in nr_rx_frame
Last occurred: 30 days ago
Reported: 30 days ago
Branches: Mainline
Dashboard link: https://syzkaller.appspot.com/bug?id=0c00cc3e04fe00ad69ac62fbe8464b2f0fae932a
Original thread: https://lkml.kernel.org/lkml/000000000000da88840589e8fe2c@google.com/T/#u
This bug has a C reproducer.
No one has replied to the original thread for this bug yet.
If you fix this bug, please add the following tag to the commit:
Reported-by: syzbot+d6636a36d3c34bd88938@syzkaller.appspotmail.com
If you send any email or patch for this bug, please consider replying to the
original thread. For the git send-email command to use, or tips on how to reply
if the thread isn't in your mailbox, see the "Reply instructions" at
https://lkml.kernel.org/r/000000000000da88840589e8fe2c@google.com
--------------------------------------------------------------------------------
Title: KASAN: use-after-free Read in lock_sock_nested
Last occurred: 24 days ago
Reported: 175 days ago
Branches: Mainline and others
Dashboard link: https://syzkaller.appspot.com/bug?id=6c137905024f86513297b035845acecb55fa9dab
Original thread: https://lkml.kernel.org/lkml/0000000000007a5aad057e7748c9@google.com/T/#u
This bug has a syzkaller reproducer only.
No one replied to the original thread for this bug.
If you fix this bug, please add the following tag to the commit:
Reported-by: syzbot+500c69d1e21d970e461b@syzkaller.appspotmail.com
If you send any email or patch for this bug, please consider replying to the
original thread. For the git send-email command to use, or tips on how to reply
if the thread isn't in your mailbox, see the "Reply instructions" at
https://lkml.kernel.org/r/0000000000007a5aad057e7748c9@google.com
--------------------------------------------------------------------------------
Title: KASAN: use-after-free Read in nr_release
Last occurred: 0 days ago
Reported: 18 days ago
Branches: net
Dashboard link: https://syzkaller.appspot.com/bug?id=5332f4a9ce674d6378f0bd91af752d2be80f3aba
Original thread: https://lkml.kernel.org/lkml/0000000000007e8b70058acbd60f@google.com/T/#u
Unfortunately, this bug does not have a reproducer.
No one has replied to the original thread for this bug yet.
If you fix this bug, please add the following tag to the commit:
Reported-by: syzbot+6eaef7158b19e3fec3a0@syzkaller.appspotmail.com
If you send any email or patch for this bug, please consider replying to the
original thread. For the git send-email command to use, or tips on how to reply
if the thread isn't in your mailbox, see the "Reply instructions" at
https://lkml.kernel.org/r/0000000000007e8b70058acbd60f@google.com
--------------------------------------------------------------------------------
Title: memory leak in nr_loopback_queue
Last occurred: 28 days ago
Reported: 28 days ago
Branches: Mainline
Dashboard link: https://syzkaller.appspot.com/bug?id=20e5b6ff68ec36b9ba8ac5225e560a3a563f343a
Original thread: https://lkml.kernel.org/lkml/000000000000a7f012058a0c7a65@google.com/T/#u
This bug has a syzkaller reproducer only.
No one has replied to the original thread for this bug yet.
If you fix this bug, please add the following tag to the commit:
Reported-by: syzbot+470d1a4a7b7a7c225881@syzkaller.appspotmail.com
If you send any email or patch for this bug, please consider replying to the
original thread. For the git send-email command to use, or tips on how to reply
if the thread isn't in your mailbox, see the "Reply instructions" at
https://lkml.kernel.org/r/000000000000a7f012058a0c7a65@google.com
--------------------------------------------------------------------------------
Title: KASAN: use-after-free Read in refcount_inc_not_zero_checked (2)
Last occurred: 70 days ago
Reported: 102 days ago
Branches: Mainline
Dashboard link: https://syzkaller.appspot.com/bug?id=b0192a79bb2d222d3e723d7db60dfb5e0ec0e570
Original thread: https://lkml.kernel.org/lkml/000000000000eea12405843bc43c@google.com/T/#u
This bug has a syzkaller reproducer only.
No one replied to the original thread for this bug.
If you fix this bug, please add the following tag to the commit:
Reported-by: syzbot+eff6b596cc8194e2f029@syzkaller.appspotmail.com
If you send any email or patch for this bug, please consider replying to the
original thread. For the git send-email command to use, or tips on how to reply
if the thread isn't in your mailbox, see the "Reply instructions" at
https://lkml.kernel.org/r/000000000000eea12405843bc43c@google.com
^ permalink raw reply
* Re: KASAN: use-after-free Write in xfrm_hash_rebuild
From: syzbot @ 2019-06-27 3:59 UTC (permalink / raw)
To: davem, herbert, linux-kernel, netdev, steffen.klassert,
syzkaller-bugs
In-Reply-To: <000000000000d028b30588fed102@google.com>
syzbot has found a reproducer for the following crash on:
HEAD commit: 249155c2 Merge branch 'parisc-5.2-4' of git://git.kernel.o..
git tree: upstream
console output: https://syzkaller.appspot.com/x/log.txt?x=10f017c3a00000
kernel config: https://syzkaller.appspot.com/x/.config?x=9a31528e58cc12e2
dashboard link: https://syzkaller.appspot.com/bug?extid=0165480d4ef07360eeda
compiler: clang version 9.0.0 (/home/glider/llvm/clang
80fee25776c2fb61e74c1ecb1a523375c2500b69)
syz repro: https://syzkaller.appspot.com/x/repro.syz?x=16cf37c3a00000
IMPORTANT: if you fix the bug, please add the following tag to the commit:
Reported-by: syzbot+0165480d4ef07360eeda@syzkaller.appspotmail.com
==================================================================
BUG: KASAN: use-after-free in __write_once_size
include/linux/compiler.h:221 [inline]
BUG: KASAN: use-after-free in __hlist_del include/linux/list.h:748 [inline]
BUG: KASAN: use-after-free in hlist_del_rcu include/linux/rculist.h:455
[inline]
BUG: KASAN: use-after-free in xfrm_hash_rebuild+0xa0d/0x1000
net/xfrm/xfrm_policy.c:1318
Write of size 8 at addr ffff888095e79c00 by task kworker/1:3/8066
CPU: 1 PID: 8066 Comm: kworker/1:3 Not tainted 5.2.0-rc6+ #7
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
Google 01/01/2011
Workqueue: events xfrm_hash_rebuild
Call Trace:
__dump_stack lib/dump_stack.c:77 [inline]
dump_stack+0x1d8/0x2f8 lib/dump_stack.c:113
print_address_description+0x6d/0x310 mm/kasan/report.c:188
__kasan_report+0x14b/0x1c0 mm/kasan/report.c:317
kasan_report+0x26/0x50 mm/kasan/common.c:614
__asan_report_store8_noabort+0x17/0x20 mm/kasan/generic_report.c:137
__write_once_size include/linux/compiler.h:221 [inline]
__hlist_del include/linux/list.h:748 [inline]
hlist_del_rcu include/linux/rculist.h:455 [inline]
xfrm_hash_rebuild+0xa0d/0x1000 net/xfrm/xfrm_policy.c:1318
process_one_work+0x814/0x1130 kernel/workqueue.c:2269
worker_thread+0xc01/0x1640 kernel/workqueue.c:2415
kthread+0x325/0x350 kernel/kthread.c:255
ret_from_fork+0x24/0x30 arch/x86/entry/entry_64.S:352
Allocated by task 8064:
save_stack mm/kasan/common.c:71 [inline]
set_track mm/kasan/common.c:79 [inline]
__kasan_kmalloc+0x11c/0x1b0 mm/kasan/common.c:489
kasan_kmalloc+0x9/0x10 mm/kasan/common.c:503
__do_kmalloc mm/slab.c:3660 [inline]
__kmalloc+0x23c/0x310 mm/slab.c:3669
kmalloc include/linux/slab.h:552 [inline]
kzalloc include/linux/slab.h:742 [inline]
xfrm_hash_alloc+0x38/0xe0 net/xfrm/xfrm_hash.c:21
xfrm_policy_init net/xfrm/xfrm_policy.c:4036 [inline]
xfrm_net_init+0x269/0xd60 net/xfrm/xfrm_policy.c:4120
ops_init+0x336/0x420 net/core/net_namespace.c:130
setup_net+0x212/0x690 net/core/net_namespace.c:316
copy_net_ns+0x224/0x380 net/core/net_namespace.c:439
create_new_namespaces+0x4ec/0x700 kernel/nsproxy.c:103
unshare_nsproxy_namespaces+0x12a/0x190 kernel/nsproxy.c:202
ksys_unshare+0x540/0xac0 kernel/fork.c:2692
__do_sys_unshare kernel/fork.c:2760 [inline]
__se_sys_unshare kernel/fork.c:2758 [inline]
__x64_sys_unshare+0x38/0x40 kernel/fork.c:2758
do_syscall_64+0xfe/0x140 arch/x86/entry/common.c:301
entry_SYSCALL_64_after_hwframe+0x49/0xbe
Freed by task 17:
save_stack mm/kasan/common.c:71 [inline]
set_track mm/kasan/common.c:79 [inline]
__kasan_slab_free+0x12a/0x1e0 mm/kasan/common.c:451
kasan_slab_free+0xe/0x10 mm/kasan/common.c:459
__cache_free mm/slab.c:3432 [inline]
kfree+0xae/0x120 mm/slab.c:3755
xfrm_hash_free+0x38/0xd0 net/xfrm/xfrm_hash.c:35
xfrm_bydst_resize net/xfrm/xfrm_policy.c:602 [inline]
xfrm_hash_resize+0x13f1/0x1840 net/xfrm/xfrm_policy.c:680
process_one_work+0x814/0x1130 kernel/workqueue.c:2269
worker_thread+0xc01/0x1640 kernel/workqueue.c:2415
kthread+0x325/0x350 kernel/kthread.c:255
ret_from_fork+0x24/0x30 arch/x86/entry/entry_64.S:352
The buggy address belongs to the object at ffff888095e79c00
which belongs to the cache kmalloc-64 of size 64
The buggy address is located 0 bytes inside of
64-byte region [ffff888095e79c00, ffff888095e79c40)
The buggy address belongs to the page:
page:ffffea0002579e40 refcount:1 mapcount:0 mapping:ffff8880aa400340
index:0x0
flags: 0x1fffc0000000200(slab)
raw: 01fffc0000000200 ffffea0002540888 ffffea0002907548 ffff8880aa400340
raw: 0000000000000000 ffff888095e79000 0000000100000020 0000000000000000
page dumped because: kasan: bad access detected
Memory state around the buggy address:
ffff888095e79b00: 00 00 00 00 00 00 00 00 fc fc fc fc fc fc fc fc
ffff888095e79b80: 00 00 00 00 00 00 00 00 fc fc fc fc fc fc fc fc
> ffff888095e79c00: fb fb fb fb fb fb fb fb fc fc fc fc fc fc fc fc
^
ffff888095e79c80: fb fb fb fb fb fb fb fb fc fc fc fc fc fc fc fc
ffff888095e79d00: 00 00 00 00 00 00 00 00 fc fc fc fc fc fc fc fc
==================================================================
^ permalink raw reply
* linux-next: manual merge of the mlx5-next tree with the net-next tree
From: Stephen Rothwell @ 2019-06-27 4:09 UTC (permalink / raw)
To: Leon Romanovsky, David Miller, Networking
Cc: Linux Next Mailing List, Linux Kernel Mailing List,
Yevgeny Kliteynik, Saeed Mahameed, Eli Britstein, Jianbo Liu
[-- Attachment #1: Type: text/plain, Size: 1034 bytes --]
Hi all,
Today's linux-next merge of the mlx5-next tree got a conflict in:
drivers/net/ethernet/mellanox/mlx5/core/eswitch_offloads.c
between commits:
955858009708 ("net/mlx5e: Fix number of vports for ingress ACL configuration")
d4a18e16c570 ("net/mlx5e: Enable setting multiple match criteria for flow group")
from the net-next tree and commits:
7445cfb1169c ("net/mlx5: E-Switch, Tag packet with vport number in VF vports and uplink ingress ACLs")
c01cfd0f1115 ("net/mlx5: E-Switch, Add match on vport metadata for rule in fast path")
from the mlx5-next tree.
I fixed it up (I basically used the latter versions) and can carry the
fix as necessary. This is now fixed as far as linux-next is concerned,
but any non trivial conflicts should be mentioned to your upstream
maintainer when your tree is submitted for merging. You may also want
to consider cooperating with the maintainer of the conflicting tree to
minimise any particularly complex conflicts.
--
Cheers,
Stephen Rothwell
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* [PATCH] net: dsa: mv88e6xxx: wait after reset deactivation
From: Baruch Siach @ 2019-06-27 4:29 UTC (permalink / raw)
To: Andrew Lunn, Vivien Didelot; +Cc: netdev, Baruch Siach
Add a 1ms delay after reset deactivation. Otherwise the chip returns
bogus ID value. This is observed with 88E6390 (Peridot) chip.
Signed-off-by: Baruch Siach <baruch@tkos.co.il>
---
drivers/net/dsa/mv88e6xxx/chip.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/net/dsa/mv88e6xxx/chip.c b/drivers/net/dsa/mv88e6xxx/chip.c
index f4e2db44ad91..549f528f216c 100644
--- a/drivers/net/dsa/mv88e6xxx/chip.c
+++ b/drivers/net/dsa/mv88e6xxx/chip.c
@@ -4910,6 +4910,7 @@ static int mv88e6xxx_probe(struct mdio_device *mdiodev)
err = PTR_ERR(chip->reset);
goto out;
}
+ mdelay(1);
err = mv88e6xxx_detect(chip);
if (err)
--
2.20.1
^ permalink raw reply related
* Re: dm9601: incorrect datasheet URL
From: Corentin Labbe @ 2019-06-27 4:55 UTC (permalink / raw)
To: Arkadiusz Drabczyk; +Cc: netdev, jacmet
In-Reply-To: <20190626141248.GA14356@comp.lan>
On Wed, Jun 26, 2019 at 04:12:48PM +0200, Arkadiusz Drabczyk wrote:
> http://ptm2.cc.utu.fi/ftp/network/cards/DM9601/From_NET/DM9601-DS-P01-930914.pdf
> is gone. In fact, document titled `DM9601-DS-P01-930914.pdf' is
> nowhere to be found online these days but there is
> http://pdf.datasheet.live/74029349/davicom.com.tw/DM9601E.pdf. I'm
> just not sure if this is the same document that the current link was
> pointing to and what does E suffix mean. There is also
> https://www.alldatasheet.com/datasheet-pdf/pdf/119750/ETC1/DM9601.html
> but notice that it says `Version: DM9601-DS-F01' on the bottom of some
> pages and `Version: DM9601-DS-P01' on others - I don't know what that
> means.
>
> Should http://pdf.datasheet.live/74029349/davicom.com.tw/DM9601E.pdf
> be used as a datasheet URL?
>
Hello
I have noticed the same problem some days ago.
The original datasheet could be found using archive.org.
I have downloaded all datasheets and none has the same md5, so it need a more detailled inspection.
Regards
^ permalink raw reply
* [Linux-kernel-mentees][PATCH v3] packet: Fix undefined behavior in bit shift
From: Jiunn Chang @ 2019-06-27 5:04 UTC (permalink / raw)
To: skhan; +Cc: linux-kernel-mentees, netdev, linux-kernel, davem
In-Reply-To: <20190627032532.18374-2-c0d1n61at3@gmail.com>
Shifting signed 32-bit value by 31 bits is undefined. Changing most
significant bit to unsigned.
Signed-off-by: Jiunn Chang <c0d1n61at3@gmail.com>
---
Changes included in v3:
- remove change log from patch description
Changes included in v2:
- use subsystem specific subject lines
- CC required mailing lists
include/uapi/linux/if_packet.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/include/uapi/linux/if_packet.h b/include/uapi/linux/if_packet.h
index 467b654bd4c7..3d884d68eb30 100644
--- a/include/uapi/linux/if_packet.h
+++ b/include/uapi/linux/if_packet.h
@@ -123,7 +123,7 @@ struct tpacket_auxdata {
/* Rx and Tx ring - header status */
#define TP_STATUS_TS_SOFTWARE (1 << 29)
#define TP_STATUS_TS_SYS_HARDWARE (1 << 30) /* deprecated, never set */
-#define TP_STATUS_TS_RAW_HARDWARE (1 << 31)
+#define TP_STATUS_TS_RAW_HARDWARE (1U << 31)
/* Rx ring - feature request bits */
#define TP_FT_REQ_FILL_RXHASH 0x1
--
2.22.0
^ permalink raw reply related
* Re: BUG: unable to handle kernel paging request in tls_prots
From: syzbot @ 2019-06-27 5:24 UTC (permalink / raw)
To: ast, bpf, daniel, davem, edumazet, john.fastabend, kafai, kuznet,
linux-kernel, netdev, songliubraving, syzkaller-bugs, yhs,
yoshfuji
In-Reply-To: <000000000000d7bcbb058c3758a1@google.com>
syzbot has bisected this bug to:
commit e9db4ef6bf4ca9894bb324c76e01b8f1a16b2650
Author: John Fastabend <john.fastabend@gmail.com>
Date: Sat Jun 30 13:17:47 2018 +0000
bpf: sockhash fix omitted bucket lock in sock_close
bisection log: https://syzkaller.appspot.com/x/bisect.txt?x=148e8665a00000
start commit: 904d88d7 qmi_wwan: Fix out-of-bounds read
git tree: net
final crash: https://syzkaller.appspot.com/x/report.txt?x=168e8665a00000
console output: https://syzkaller.appspot.com/x/log.txt?x=128e8665a00000
kernel config: https://syzkaller.appspot.com/x/.config?x=137ec2016ea3870d
dashboard link: https://syzkaller.appspot.com/bug?extid=4207c7f3a443366d8aa2
syz repro: https://syzkaller.appspot.com/x/repro.syz?x=15576c71a00000
Reported-by: syzbot+4207c7f3a443366d8aa2@syzkaller.appspotmail.com
Fixes: e9db4ef6bf4c ("bpf: sockhash fix omitted bucket lock in sock_close")
For information about bisection process see: https://goo.gl/tpsmEJ#bisection
^ permalink raw reply
* Re: [for-next V2 08/10] linux/dim: Implement rdma_dim
From: Yamin Friedman @ 2019-06-27 5:25 UTC (permalink / raw)
To: Sagi Grimberg, Saeed Mahameed, David S. Miller, Doug Ledford,
Jason Gunthorpe
Cc: Leon Romanovsky, Or Gerlitz, Tal Gilboa, netdev@vger.kernel.org,
linux-rdma@vger.kernel.org, Max Gurtovoy
In-Reply-To: <bfa2159e-1576-6b3c-c85b-ee98bd4f9a47@grimberg.me>
On 6/26/2019 1:02 AM, Sagi Grimberg wrote:
>
>> +void rdma_dim(struct dim *dim, u64 completions)
>> +{
>> + struct dim_sample *curr_sample = &dim->measuring_sample;
>> + struct dim_stats curr_stats;
>> + u32 nevents;
>> +
>> + dim_update_sample_with_comps(curr_sample->event_ctr + 1,
>> + curr_sample->pkt_ctr,
>> + curr_sample->byte_ctr,
>> + curr_sample->comp_ctr + completions,
>> + &dim->measuring_sample);
>
> If this is the only caller, why add pkt_ctr and byte_ctr at all?
We wanted to keep the API general enough that if someone wants to
implement a different algorithm using the dim library they will be able
to use all the possible statistics. I agree though that in the rdma_dim
function there is no point in making it seem like they are relevant
parameters.
^ permalink raw reply
* Re: [for-next V2 10/10] RDMA/core: Provide RDMA DIM support for ULPs
From: Yamin Friedman @ 2019-06-27 5:28 UTC (permalink / raw)
To: Sagi Grimberg, Saeed Mahameed, David S. Miller, Doug Ledford,
Jason Gunthorpe
Cc: Leon Romanovsky, Or Gerlitz, Tal Gilboa, netdev@vger.kernel.org,
linux-rdma@vger.kernel.org, Max Gurtovoy
In-Reply-To: <adb3687a-6db3-b1a4-cd32-8b4889550c81@grimberg.me>
On 6/26/2019 12:14 AM, Sagi Grimberg wrote:
>
>
>> +static int ib_poll_dim_handler(struct irq_poll *iop, int budget)
>> +{
>> + struct ib_cq *cq = container_of(iop, struct ib_cq, iop);
>> + struct dim *dim = cq->dim;
>> + int completed;
>> +
>> + completed = __ib_process_cq(cq, budget, cq->wc, IB_POLL_BATCH);
>> + if (completed < budget) {
>> + irq_poll_complete(&cq->iop);
>> + if (ib_req_notify_cq(cq, IB_POLL_FLAGS) > 0)
>> + irq_poll_sched(&cq->iop);
>> + }
>> +
>> + rdma_dim(dim, completed);
>
> Why duplicate the entire thing for a one-liner?
You are right, this was leftover from a previous version where there
were more significant changes. I will remove the extra function.
>
>> +
>> + return completed;
>> +}
>> +
>> static void ib_cq_completion_softirq(struct ib_cq *cq, void *private)
>> {
>> irq_poll_sched(&cq->iop);
>> @@ -105,14 +157,18 @@ static void ib_cq_completion_softirq(struct
>> ib_cq *cq, void *private)
>> static void ib_cq_poll_work(struct work_struct *work)
>> {
>> - struct ib_cq *cq = container_of(work, struct ib_cq, work);
>> + struct ib_cq *cq = container_of(work, struct ib_cq,
>> + work);
>
> Why was that changed?
I will fix this.
>
>> int completed;
>> completed = __ib_process_cq(cq, IB_POLL_BUDGET_WORKQUEUE,
>> cq->wc,
>> IB_POLL_BATCH);
>> +
>
> newline?
Same as above.
>
>> if (completed >= IB_POLL_BUDGET_WORKQUEUE ||
>> ib_req_notify_cq(cq, IB_POLL_FLAGS) > 0)
>> queue_work(cq->comp_wq, &cq->work);
>> + else if (cq->dim)
>> + rdma_dim(cq->dim, completed);
>> }
>> static void ib_cq_completion_workqueue(struct ib_cq *cq, void
>> *private)
>> @@ -166,6 +222,8 @@ struct ib_cq *__ib_alloc_cq_user(struct ib_device
>> *dev, void *private,
>> rdma_restrack_set_task(&cq->res, caller);
>> rdma_restrack_kadd(&cq->res);
>> + rdma_dim_init(cq);
>> +
>> switch (cq->poll_ctx) {
>> case IB_POLL_DIRECT:
>> cq->comp_handler = ib_cq_completion_direct;
>> @@ -173,7 +231,13 @@ struct ib_cq *__ib_alloc_cq_user(struct
>> ib_device *dev, void *private,
>> case IB_POLL_SOFTIRQ:
>> cq->comp_handler = ib_cq_completion_softirq;
>> - irq_poll_init(&cq->iop, IB_POLL_BUDGET_IRQ, ib_poll_handler);
>> + if (cq->dim) {
>> + irq_poll_init(&cq->iop, IB_POLL_BUDGET_IRQ,
>> + ib_poll_dim_handler);
>> + } else
>> + irq_poll_init(&cq->iop, IB_POLL_BUDGET_IRQ,
>> + ib_poll_handler);
>> +
>> ib_req_notify_cq(cq, IB_CQ_NEXT_COMP);
>> break;
>> case IB_POLL_WORKQUEUE:
>> @@ -226,6 +290,9 @@ void ib_free_cq_user(struct ib_cq *cq, struct
>> ib_udata *udata)
>> WARN_ON_ONCE(1);
>> }
>> + if (cq->dim)
>> + cancel_work_sync(&cq->dim->work);
>> + kfree(cq->dim);
>> kfree(cq->wc);
>> rdma_restrack_del(&cq->res);
>> ret = cq->device->ops.destroy_cq(cq, udata);
>> diff --git a/drivers/infiniband/hw/mlx5/main.c
>> b/drivers/infiniband/hw/mlx5/main.c
>> index abac70ad5c7c..b1b45dbe24a5 100644
>> --- a/drivers/infiniband/hw/mlx5/main.c
>> +++ b/drivers/infiniband/hw/mlx5/main.c
>> @@ -6305,6 +6305,8 @@ static int mlx5_ib_stage_caps_init(struct
>> mlx5_ib_dev *dev)
>> MLX5_CAP_GEN(dev->mdev, disable_local_lb_mc)))
>> mutex_init(&dev->lb.mutex);
>> + dev->ib_dev.use_cq_dim = true;
>> +
>
> Please don't. This is a bad choice to opt it in by default.
^ permalink raw reply
* Re: [for-next V2 09/10] RDMA/nldev: Added configuration of RDMA dynamic interrupt moderation to netlink
From: Yamin Friedman @ 2019-06-27 5:29 UTC (permalink / raw)
To: Sagi Grimberg, Saeed Mahameed, David S. Miller, Doug Ledford,
Jason Gunthorpe
Cc: Leon Romanovsky, Or Gerlitz, Tal Gilboa, netdev@vger.kernel.org,
linux-rdma@vger.kernel.org
In-Reply-To: <f621af3b-37a3-eb97-368a-3201fa49f338@grimberg.me>
On 6/26/2019 12:15 AM, Sagi Grimberg wrote:
>
>
> On 6/25/19 1:57 PM, Saeed Mahameed wrote:
>> From: Yamin Friedman <yaminf@mellanox.com>
>>
>> Added parameter in ib_device for enabling dynamic interrupt
>> moderation so
>> that it can be configured in userspace using rdma tool.
>>
>> In order to set dim for an ib device the command is:
>> rdma dev set [DEV] dim [on|off]
>> Please set on/off.
>
> Is "dim" what you want to expose to the user? maybe
> "adaptive-moderation" is more friendly?
That makes sense, I will change it.
^ permalink raw reply
* [PATCH 0/2] Sub ns increment fixes in Macb PTP
From: Harini Katakam @ 2019-06-27 6:20 UTC (permalink / raw)
To: nicolas.ferre, davem, richardcochran, claudiu.beznea, rafalo,
andrei.pistirica
Cc: netdev, linux-kernel, michal.simek, harinikatakamlinux,
harini.katakam
The subns increment register fields are not captured correctly in the
driver. Fix the same and also increase the subns incr resolution.
Sub ns resolution was increased to 24 bits in r1p06f2 version. To my
knowledge, this PTP driver, with its current BD time stamp
implementation, is only useful to that version or above. So, I have
increased the resolution unconditionally. Please let me know if there
is any IP versions incompatible with this - there is no register to
obtain this information from.
Changes from RFC:
None
Harini Katakam (2):
net: macb: Add separate definition for PPM fraction
net: macb: Fix SUBNS increment and increase resolution
drivers/net/ethernet/cadence/macb.h | 9 ++++++++-
drivers/net/ethernet/cadence/macb_ptp.c | 7 +++++--
2 files changed, 13 insertions(+), 3 deletions(-)
--
2.7.4
^ permalink raw reply
* [PATCH 1/2] net: macb: Add separate definition for PPM fraction
From: Harini Katakam @ 2019-06-27 6:20 UTC (permalink / raw)
To: nicolas.ferre, davem, richardcochran, claudiu.beznea, rafalo,
andrei.pistirica
Cc: netdev, linux-kernel, michal.simek, harinikatakamlinux,
harini.katakam
In-Reply-To: <1561616460-32439-1-git-send-email-harini.katakam@xilinx.com>
The scaled ppm parameter passed to _adjfine() contains a 16 bit
fraction. This just happens to be the same as SUBNSINCR_SIZE now.
Hence define this separately.
Signed-off-by: Harini Katakam <harini.katakam@xilinx.com>
---
drivers/net/ethernet/cadence/macb.h | 3 +++
drivers/net/ethernet/cadence/macb_ptp.c | 2 +-
2 files changed, 4 insertions(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/cadence/macb.h b/drivers/net/ethernet/cadence/macb.h
index 515bfd2..90bc70b 100644
--- a/drivers/net/ethernet/cadence/macb.h
+++ b/drivers/net/ethernet/cadence/macb.h
@@ -834,6 +834,9 @@ struct gem_tx_ts {
/* limit RX checksum offload to TCP and UDP packets */
#define GEM_RX_CSUM_CHECKED_MASK 2
+/* Scaled PPM fraction */
+#define PPM_FRACTION 16
+
/* struct macb_tx_skb - data about an skb which is being transmitted
* @skb: skb currently being transmitted, only set for the last buffer
* of the frame
diff --git a/drivers/net/ethernet/cadence/macb_ptp.c b/drivers/net/ethernet/cadence/macb_ptp.c
index 0a8aca8..6276eac 100644
--- a/drivers/net/ethernet/cadence/macb_ptp.c
+++ b/drivers/net/ethernet/cadence/macb_ptp.c
@@ -135,7 +135,7 @@ static int gem_ptp_adjfine(struct ptp_clock_info *ptp, long scaled_ppm)
* (temp / USEC_PER_SEC) + 0.5
*/
adj += (USEC_PER_SEC >> 1);
- adj >>= GEM_SUBNSINCR_SIZE; /* remove fractions */
+ adj >>= PPM_FRACTION; /* remove fractions */
adj = div_u64(adj, USEC_PER_SEC);
adj = neg_adj ? (word - adj) : (word + adj);
--
2.7.4
^ permalink raw reply related
* [PATCH 2/2] net: macb: Fix SUBNS increment and increase resolution
From: Harini Katakam @ 2019-06-27 6:21 UTC (permalink / raw)
To: nicolas.ferre, davem, richardcochran, claudiu.beznea, rafalo,
andrei.pistirica
Cc: netdev, linux-kernel, michal.simek, harinikatakamlinux,
harini.katakam
In-Reply-To: <1561616460-32439-1-git-send-email-harini.katakam@xilinx.com>
The subns increment register has 24 bits as follows:
RegBit[15:0] = Subns[23:8]; RegBit[31:24] = Subns[7:0]
Fix the same in the driver and increase sub ns resolution to the
best capable, 24 bits. This should be the case on all GEM versions
that this PTP driver supports.
Signed-off-by: Harini Katakam <harini.katakam@xilinx.com>
---
drivers/net/ethernet/cadence/macb.h | 6 +++++-
drivers/net/ethernet/cadence/macb_ptp.c | 5 ++++-
2 files changed, 9 insertions(+), 2 deletions(-)
diff --git a/drivers/net/ethernet/cadence/macb.h b/drivers/net/ethernet/cadence/macb.h
index 90bc70b..03983bd 100644
--- a/drivers/net/ethernet/cadence/macb.h
+++ b/drivers/net/ethernet/cadence/macb.h
@@ -496,7 +496,11 @@
/* Bitfields in TISUBN */
#define GEM_SUBNSINCR_OFFSET 0
-#define GEM_SUBNSINCR_SIZE 16
+#define GEM_SUBNSINCRL_OFFSET 24
+#define GEM_SUBNSINCRL_SIZE 8
+#define GEM_SUBNSINCRH_OFFSET 0
+#define GEM_SUBNSINCRH_SIZE 16
+#define GEM_SUBNSINCR_SIZE 24
/* Bitfields in TI */
#define GEM_NSINCR_OFFSET 0
diff --git a/drivers/net/ethernet/cadence/macb_ptp.c b/drivers/net/ethernet/cadence/macb_ptp.c
index 6276eac..43a3f0d 100644
--- a/drivers/net/ethernet/cadence/macb_ptp.c
+++ b/drivers/net/ethernet/cadence/macb_ptp.c
@@ -104,7 +104,10 @@ static int gem_tsu_incr_set(struct macb *bp, struct tsu_incr *incr_spec)
* to take effect.
*/
spin_lock_irqsave(&bp->tsu_clk_lock, flags);
- gem_writel(bp, TISUBN, GEM_BF(SUBNSINCR, incr_spec->sub_ns));
+ /* RegBit[15:0] = Subns[23:8]; RegBit[31:24] = Subns[7:0] */
+ gem_writel(bp, TISUBN, GEM_BF(SUBNSINCRL, incr_spec->sub_ns) |
+ GEM_BF(SUBNSINCRH, (incr_spec->sub_ns >>
+ GEM_SUBNSINCRL_SIZE)));
gem_writel(bp, TI, GEM_BF(NSINCR, incr_spec->ns));
spin_unlock_irqrestore(&bp->tsu_clk_lock, flags);
--
2.7.4
^ permalink raw reply related
* Re: [PATCH 2/3 nf-next] netfilter:nf_flow_table: Support bridge type flow offload
From: wenxu @ 2019-06-27 6:22 UTC (permalink / raw)
To: Florian Westphal; +Cc: pablo, netfilter-devel, netdev
In-Reply-To: <20190626191945.2mktaqrcrfcrfc66@breakpoint.cc>
On 6/27/2019 3:19 AM, Florian Westphal wrote:
> Florian Westphal <fw@strlen.de> wrote:
>> wenxu@ucloud.cn <wenxu@ucloud.cn> wrote:
>>> diff --git a/net/netfilter/nf_flow_table_ip.c b/net/netfilter/nf_flow_table_ip.c
>>> index 0016bb8..9af01ef 100644
>>> --- a/net/netfilter/nf_flow_table_ip.c
>>> +++ b/net/netfilter/nf_flow_table_ip.c
>>> - neigh_xmit(NEIGH_ARP_TABLE, outdev, &nexthop, skb);
>>> + if (family == NFPROTO_IPV4) {
>>> + iph = ip_hdr(skb);
>>> + ip_decrease_ttl(iph);
>>> +
>>> + nexthop = rt_nexthop(rt, flow->tuplehash[!dir].tuple.src_v4.s_addr);
>>> + skb_dst_set_noref(skb, &rt->dst);
>>> + neigh_xmit(NEIGH_ARP_TABLE, outdev, &nexthop, skb);
>>> + } else {
>>> + const struct net_bridge_port *p;
>>> +
>>> + if (vlan_tag && (p = br_port_get_rtnl_rcu(state->in)))
>>> + __vlan_hwaccel_put_tag(skb, p->br->vlan_proto, vlan_tag);
>>> + else
>>> + __vlan_hwaccel_clear_tag(skb);
>>> +
>>> + br_dev_queue_push_xmit(state->net, state->sk, skb);
>> Won't that result in a module dep on bridge?
I will fix it in version 2
>>
>> Whats the idea with this patch?
>>
>> Do you see a performance improvement when bypassing bridge layer? If so,
>> how much?
>>
>> I just wonder if its really cheaper than not using bridge conntrack in
>> the first place :-)
This patch is based on the conntrack function in bridge. It will bypass the fdb lookup
and conntrack lookup to get the performance improvement. The more important things
for hardware offload in the future with nf_tables add hardware offload support
>
^ permalink raw reply
* KASAN: use-after-free Write in xfrm_policy_flush
From: syzbot @ 2019-06-27 6:50 UTC (permalink / raw)
To: davem, herbert, linux-kernel, netdev, steffen.klassert,
syzkaller-bugs
Hello,
syzbot found the following crash on:
HEAD commit: 249155c2 Merge branch 'parisc-5.2-4' of git://git.kernel.o..
git tree: upstream
console output: https://syzkaller.appspot.com/x/log.txt?x=10f1198da00000
kernel config: https://syzkaller.appspot.com/x/.config?x=9a31528e58cc12e2
dashboard link: https://syzkaller.appspot.com/bug?extid=2daeb7ae5e8245095f65
compiler: clang version 9.0.0 (/home/glider/llvm/clang
80fee25776c2fb61e74c1ecb1a523375c2500b69)
Unfortunately, I don't have any reproducer for this crash yet.
IMPORTANT: if you fix the bug, please add the following tag to the commit:
Reported-by: syzbot+2daeb7ae5e8245095f65@syzkaller.appspotmail.com
netlink: 168 bytes leftover after parsing attributes in process
`syz-executor.2'.
==================================================================
BUG: KASAN: use-after-free in __write_once_size
include/linux/compiler.h:221 [inline]
BUG: KASAN: use-after-free in __hlist_del include/linux/list.h:748 [inline]
BUG: KASAN: use-after-free in hlist_del_rcu include/linux/rculist.h:455
[inline]
BUG: KASAN: use-after-free in __xfrm_policy_unlink
net/xfrm/xfrm_policy.c:2217 [inline]
BUG: KASAN: use-after-free in xfrm_policy_flush+0x3be/0x900
net/xfrm/xfrm_policy.c:1794
Write of size 8 at addr ffff8880a5cfdd00 by task syz-executor.2/31717
CPU: 0 PID: 31717 Comm: syz-executor.2 Not tainted 5.2.0-rc6+ #7
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
Google 01/01/2011
Call Trace:
__dump_stack lib/dump_stack.c:77 [inline]
dump_stack+0x1d8/0x2f8 lib/dump_stack.c:113
print_address_description+0x6d/0x310 mm/kasan/report.c:188
__kasan_report+0x14b/0x1c0 mm/kasan/report.c:317
kasan_report+0x26/0x50 mm/kasan/common.c:614
__asan_report_store8_noabort+0x17/0x20 mm/kasan/generic_report.c:137
__write_once_size include/linux/compiler.h:221 [inline]
__hlist_del include/linux/list.h:748 [inline]
hlist_del_rcu include/linux/rculist.h:455 [inline]
__xfrm_policy_unlink net/xfrm/xfrm_policy.c:2217 [inline]
xfrm_policy_flush+0x3be/0x900 net/xfrm/xfrm_policy.c:1794
xfrm_flush_policy+0x132/0x3c0 net/xfrm/xfrm_user.c:2123
xfrm_user_rcv_msg+0x46b/0x720 net/xfrm/xfrm_user.c:2657
netlink_rcv_skb+0x1f0/0x460 net/netlink/af_netlink.c:2482
xfrm_netlink_rcv+0x74/0x90 net/xfrm/xfrm_user.c:2665
netlink_unicast_kernel net/netlink/af_netlink.c:1307 [inline]
netlink_unicast+0x962/0xaf0 net/netlink/af_netlink.c:1333
netlink_sendmsg+0xa7a/0xd40 net/netlink/af_netlink.c:1922
sock_sendmsg_nosec net/socket.c:646 [inline]
sock_sendmsg net/socket.c:665 [inline]
___sys_sendmsg+0x66b/0x9a0 net/socket.c:2286
__sys_sendmsg net/socket.c:2324 [inline]
__do_sys_sendmsg net/socket.c:2333 [inline]
__se_sys_sendmsg net/socket.c:2331 [inline]
__x64_sys_sendmsg+0x1cf/0x290 net/socket.c:2331
do_syscall_64+0xfe/0x140 arch/x86/entry/common.c:301
entry_SYSCALL_64_after_hwframe+0x49/0xbe
RIP: 0033:0x459519
Code: fd b7 fb ff c3 66 2e 0f 1f 84 00 00 00 00 00 66 90 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 0f 83 cb b7 fb ff c3 66 2e 0f 1f 84 00 00 00 00
RSP: 002b:00007f4e7b5f5c78 EFLAGS: 00000246 ORIG_RAX: 000000000000002e
RAX: ffffffffffffffda RBX: 0000000000000003 RCX: 0000000000459519
RDX: 0000000000000000 RSI: 000000002014f000 RDI: 0000000000000003
RBP: 000000000075bf20 R08: 0000000000000000 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000246 R12: 00007f4e7b5f66d4
R13: 00000000004c7264 R14: 00000000004dc6c8 R15: 00000000ffffffff
Allocated by task 8433:
save_stack mm/kasan/common.c:71 [inline]
set_track mm/kasan/common.c:79 [inline]
__kasan_kmalloc+0x11c/0x1b0 mm/kasan/common.c:489
kasan_kmalloc+0x9/0x10 mm/kasan/common.c:503
__do_kmalloc mm/slab.c:3660 [inline]
__kmalloc+0x23c/0x310 mm/slab.c:3669
kmalloc include/linux/slab.h:552 [inline]
kzalloc include/linux/slab.h:742 [inline]
xfrm_hash_alloc+0x38/0xe0 net/xfrm/xfrm_hash.c:21
xfrm_policy_init net/xfrm/xfrm_policy.c:4036 [inline]
xfrm_net_init+0x269/0xd60 net/xfrm/xfrm_policy.c:4120
ops_init+0x336/0x420 net/core/net_namespace.c:130
setup_net+0x212/0x690 net/core/net_namespace.c:316
copy_net_ns+0x224/0x380 net/core/net_namespace.c:439
create_new_namespaces+0x4ec/0x700 kernel/nsproxy.c:103
unshare_nsproxy_namespaces+0x12a/0x190 kernel/nsproxy.c:202
ksys_unshare+0x540/0xac0 kernel/fork.c:2692
__do_sys_unshare kernel/fork.c:2760 [inline]
__se_sys_unshare kernel/fork.c:2758 [inline]
__x64_sys_unshare+0x38/0x40 kernel/fork.c:2758
do_syscall_64+0xfe/0x140 arch/x86/entry/common.c:301
entry_SYSCALL_64_after_hwframe+0x49/0xbe
Freed by task 21222:
save_stack mm/kasan/common.c:71 [inline]
set_track mm/kasan/common.c:79 [inline]
__kasan_slab_free+0x12a/0x1e0 mm/kasan/common.c:451
kasan_slab_free+0xe/0x10 mm/kasan/common.c:459
__cache_free mm/slab.c:3432 [inline]
kfree+0xae/0x120 mm/slab.c:3755
xfrm_hash_free+0x38/0xd0 net/xfrm/xfrm_hash.c:35
xfrm_bydst_resize net/xfrm/xfrm_policy.c:602 [inline]
xfrm_hash_resize+0x13f1/0x1840 net/xfrm/xfrm_policy.c:680
process_one_work+0x814/0x1130 kernel/workqueue.c:2269
worker_thread+0xc01/0x1640 kernel/workqueue.c:2415
kthread+0x325/0x350 kernel/kthread.c:255
ret_from_fork+0x24/0x30 arch/x86/entry/entry_64.S:352
The buggy address belongs to the object at ffff8880a5cfdd00
which belongs to the cache kmalloc-64 of size 64
The buggy address is located 0 bytes inside of
64-byte region [ffff8880a5cfdd00, ffff8880a5cfdd40)
The buggy address belongs to the page:
page:ffffea0002973f40 refcount:1 mapcount:0 mapping:ffff8880aa400340
index:0x0
flags: 0x1fffc0000000200(slab)
raw: 01fffc0000000200 ffffea000267ccc8 ffffea0002a49b08 ffff8880aa400340
raw: 0000000000000000 ffff8880a5cfd000 0000000100000020 0000000000000000
page dumped because: kasan: bad access detected
Memory state around the buggy address:
ffff8880a5cfdc00: 00 00 00 00 00 00 00 00 fc fc fc fc fc fc fc fc
ffff8880a5cfdc80: 00 00 00 00 00 00 00 00 fc fc fc fc fc fc fc fc
> ffff8880a5cfdd00: fb fb fb fb fb fb fb fb fc fc fc fc fc fc fc fc
^
ffff8880a5cfdd80: 00 00 00 00 00 00 00 00 fc fc fc fc fc fc fc fc
ffff8880a5cfde00: 00 00 00 00 00 00 00 00 fc fc fc fc fc fc fc fc
==================================================================
---
This bug is generated by a bot. It may contain errors.
See https://goo.gl/tpsmEJ for more information about syzbot.
syzbot engineers can be reached at syzkaller@googlegroups.com.
syzbot will keep track of this bug report. See:
https://goo.gl/tpsmEJ#status for how to communicate with syzbot.
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox