* [PATCH v2] socket: fix struct ifreq size in compat ioctl
From: Johannes Berg @ 2018-09-13 12:40 UTC (permalink / raw)
To: netdev; +Cc: Robert O'Callahan, Al Viro, Johannes Berg
From: Johannes Berg <johannes.berg@intel.com>
As reported by Reobert O'Callahan, since Viro's commit to kill
dev_ifsioc() we attempt to copy too much data in compat mode,
which may lead to EFAULT when the 32-bit version of struct ifreq
sits at/near the end of a page boundary, and the next page isn't
mapped.
Fix this by passing the approprate compat/non-compat size to copy
and using that, as before the dev_ifsioc() removal. This works
because only the embedded "struct ifmap" has different size, and
this is only used in SIOCGIFMAP/SIOCSIFMAP which has a different
handler. All other parts of the union are naturally compatible.
This fixes https://bugzilla.kernel.org/show_bug.cgi?id=199469.
Fixes: bf4405737f9f ("kill dev_ifsioc()")
Reported-by: Robert O'Callahan <robert@ocallahan.org>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
---
net/socket.c | 22 ++++++++++++++--------
1 file changed, 14 insertions(+), 8 deletions(-)
diff --git a/net/socket.c b/net/socket.c
index e6945e318f02..01f3f8f32d6f 100644
--- a/net/socket.c
+++ b/net/socket.c
@@ -941,7 +941,8 @@ void dlci_ioctl_set(int (*hook) (unsigned int, void __user *))
EXPORT_SYMBOL(dlci_ioctl_set);
static long sock_do_ioctl(struct net *net, struct socket *sock,
- unsigned int cmd, unsigned long arg)
+ unsigned int cmd, unsigned long arg,
+ unsigned int ifreq_size)
{
int err;
void __user *argp = (void __user *)arg;
@@ -967,11 +968,11 @@ static long sock_do_ioctl(struct net *net, struct socket *sock,
} else {
struct ifreq ifr;
bool need_copyout;
- if (copy_from_user(&ifr, argp, sizeof(struct ifreq)))
+ if (copy_from_user(&ifr, argp, ifreq_size))
return -EFAULT;
err = dev_ioctl(net, cmd, &ifr, &need_copyout);
if (!err && need_copyout)
- if (copy_to_user(argp, &ifr, sizeof(struct ifreq)))
+ if (copy_to_user(argp, &ifr, ifreq_size))
return -EFAULT;
}
return err;
@@ -1070,7 +1071,8 @@ static long sock_ioctl(struct file *file, unsigned cmd, unsigned long arg)
err = open_related_ns(&net->ns, get_net_ns);
break;
default:
- err = sock_do_ioctl(net, sock, cmd, arg);
+ err = sock_do_ioctl(net, sock, cmd, arg,
+ sizeof(struct ifreq));
break;
}
return err;
@@ -2750,7 +2752,8 @@ static int do_siocgstamp(struct net *net, struct socket *sock,
int err;
set_fs(KERNEL_DS);
- err = sock_do_ioctl(net, sock, cmd, (unsigned long)&ktv);
+ err = sock_do_ioctl(net, sock, cmd, (unsigned long)&ktv,
+ sizeof(struct compat_ifreq));
set_fs(old_fs);
if (!err)
err = compat_put_timeval(&ktv, up);
@@ -2766,7 +2769,8 @@ static int do_siocgstampns(struct net *net, struct socket *sock,
int err;
set_fs(KERNEL_DS);
- err = sock_do_ioctl(net, sock, cmd, (unsigned long)&kts);
+ err = sock_do_ioctl(net, sock, cmd, (unsigned long)&kts,
+ sizeof(struct compat_ifreq));
set_fs(old_fs);
if (!err)
err = compat_put_timespec(&kts, up);
@@ -3072,7 +3076,8 @@ static int routing_ioctl(struct net *net, struct socket *sock,
}
set_fs(KERNEL_DS);
- ret = sock_do_ioctl(net, sock, cmd, (unsigned long) r);
+ ret = sock_do_ioctl(net, sock, cmd, (unsigned long) r,
+ sizeof(struct compat_ifreq));
set_fs(old_fs);
out:
@@ -3185,7 +3190,8 @@ static int compat_sock_ioctl_trans(struct file *file, struct socket *sock,
case SIOCBONDSETHWADDR:
case SIOCBONDCHANGEACTIVE:
case SIOCGIFNAME:
- return sock_do_ioctl(net, sock, cmd, arg);
+ return sock_do_ioctl(net, sock, cmd, arg,
+ sizeof(struct compat_ifreq));
}
return -ENOIOCTLCMD;
--
2.14.4
^ permalink raw reply related
* Re: [PATCH 2/2] net: qcom/emac: add shared mdio bus support
From: Andrew Lunn @ 2018-09-13 12:42 UTC (permalink / raw)
To: Wang Dongsheng; +Cc: timur, davem, yu.zheng, netdev
In-Reply-To: <1536829493-10088-3-git-send-email-dongsheng.wang@hxt-semitech.com>
On Thu, Sep 13, 2018 at 05:04:53PM +0800, Wang Dongsheng wrote:
> Share the mii_bus for others MAC device because QDF2400 emac
> include MDIO, and the motherboard has more than one PHY connected
> to an MDIO bus.
>
> Tested: QDF2400 (ACPI), buildin/insmod/rmmod
>
> Signed-off-by: Wang Dongsheng <dongsheng.wang@hxt-semitech.com>
Hi Wang
This is a pretty big patch, and is hard to review. Could you try to
break it up into a number of smaller patches. You could for example
first refactor emacs_phy_config(), without making any functional
changes. Then add the sharing. Maybe do OF an ACPI in different
patches?
Thanks
Andrew
^ permalink raw reply
* Re: [PATCH v2,net-next 1/2] ip_gre: fix parsing gre header in ipgre_err
From: David Miller @ 2018-09-13 17:58 UTC (permalink / raw)
To: yanhaishuang; +Cc: kuznet, jbenc, netdev, linux-kernel
In-Reply-To: <1536744082-3568-1-git-send-email-yanhaishuang@cmss.chinamobile.com>
From: Haishuang Yan <yanhaishuang@cmss.chinamobile.com>
Date: Wed, 12 Sep 2018 17:21:21 +0800
> @@ -86,7 +86,7 @@ int gre_parse_header(struct sk_buff *skb, struct tnl_ptk_info *tpi,
>
> options = (__be32 *)(greh + 1);
> if (greh->flags & GRE_CSUM) {
> - if (skb_checksum_simple_validate(skb)) {
> + if (csum_err && skb_checksum_simple_validate(skb)) {
> *csum_err = true;
> return -EINVAL;
> }
You want to ignore csum errors, but you do not want to elide the side
effects of the skb_checksum_simple_validate() call which are to set
skb->csum_valid and skb->csum.
Therefore, the skb_checksum_simple_validate() call still needs to be
performed. We just wont return -EINVAL in the NULL csum_err case.
^ permalink raw reply
* Re: [RFC PATCH iproute2-next] man: Add devlink health man page
From: Eran Ben Elisha @ 2018-09-13 12:49 UTC (permalink / raw)
To: Andrew Lunn
Cc: netdev, Jiri Pirko, Andy Gospodarek, Michael Chan, Jakub Kicinski,
Simon Horman, Alexander Duyck, Florian Fainelli, Tal Alon,
Ariel Almog
In-Reply-To: <20180913120815.GB11702@lunn.ch>
On 9/13/2018 3:08 PM, Andrew Lunn wrote:
>> devlink health sensor set pci/0000:01:00.0 name TX_COMP_ERROR action reset off action dump on
>> Sets TX_COMP_ERROR sensor parameters for a specific device.
>
> I hope the real sensors have more understandable names. If i remember
> correctly, the same sort of comment was given for resource
> management. It was pretty unclear what the resource names actually
> mean. Is an average user going to have any idea how to actually use
> these sensors and actions?
well, hopefully. the whole point is to have it fully controlled by the
user. However, names for the command should be short. I guess we shall
have it documented (challenge is to fit to multi vendors).
>
> Can you give more examples of sensors. We should understand if there
> are any overlaps with hwmon.
I restate here that we shall have SW sensors as well, and not only HW
sensors.
This is what I had in mind:
1. command interface error
2. command interface timeout
3. stuck TX queue (like tx_timeout)
4. stuck TX completion queue (driver did not process packets in a
reasonable time period)
5. stuck RX queue
6. RX completion error
7. TX completion error
8. HW / FW catastrophic error report
9. completion queue overrun
Eran
>
> Andrew
>
^ permalink raw reply
* Re: [PATCH net-next V2 00/11] vhost_net TX batching
From: Michael S. Tsirkin @ 2018-09-13 18:02 UTC (permalink / raw)
To: David Miller; +Cc: jasowang, netdev, linux-kernel, kvm, virtualization
In-Reply-To: <20180913.092819.2099750169529223026.davem@davemloft.net>
On Thu, Sep 13, 2018 at 09:28:19AM -0700, David Miller wrote:
> From: Jason Wang <jasowang@redhat.com>
> Date: Wed, 12 Sep 2018 11:16:58 +0800
>
> > This series tries to batch submitting packets to underlayer socket
> > through msg_control during sendmsg(). This is done by:
> ...
>
> Series applied, thanks Jason.
Going over it now I don't see a lot to complain about, but I'd
appreciate a bit more time for review in the future. 3 days ok?
--
MST
^ permalink raw reply
* Re: [PATCH net-next V2 11/11] vhost_net: batch submitting XDP buffers to underlayer sockets
From: Michael S. Tsirkin @ 2018-09-13 18:04 UTC (permalink / raw)
To: Jason Wang; +Cc: netdev, linux-kernel, kvm, virtualization
In-Reply-To: <20180912031709.14112-12-jasowang@redhat.com>
On Wed, Sep 12, 2018 at 11:17:09AM +0800, Jason Wang wrote:
> +static void vhost_tx_batch(struct vhost_net *net,
> + struct vhost_net_virtqueue *nvq,
> + struct socket *sock,
> + struct msghdr *msghdr)
> +{
> + struct tun_msg_ctl ctl = {
> + .type = TUN_MSG_PTR,
> + .num = nvq->batched_xdp,
> + .ptr = nvq->xdp,
> + };
> + int err;
> +
> + if (nvq->batched_xdp == 0)
> + goto signal_used;
> +
> + msghdr->msg_control = &ctl;
> + err = sock->ops->sendmsg(sock, msghdr, 0);
> + if (unlikely(err < 0)) {
> + vq_err(&nvq->vq, "Fail to batch sending packets\n");
> + return;
> + }
> +
> +signal_used:
> + vhost_net_signal_used(nvq);
> + nvq->batched_xdp = 0;
> +}
> +
Given it's all tun-specific now, how about just exporting tap_sendmsg
and calling that? Will get rid of some indirection too.
--
MST
^ permalink raw reply
* Re: [PATCH net-next V2 00/11] vhost_net TX batching
From: David Miller @ 2018-09-13 18:05 UTC (permalink / raw)
To: mst; +Cc: netdev, linux-kernel, kvm, virtualization
In-Reply-To: <20180913135833-mutt-send-email-mst@kernel.org>
From: "Michael S. Tsirkin" <mst@redhat.com>
Date: Thu, 13 Sep 2018 14:02:13 -0400
> On Thu, Sep 13, 2018 at 09:28:19AM -0700, David Miller wrote:
>> From: Jason Wang <jasowang@redhat.com>
>> Date: Wed, 12 Sep 2018 11:16:58 +0800
>>
>> > This series tries to batch submitting packets to underlayer socket
>> > through msg_control during sendmsg(). This is done by:
>> ...
>>
>> Series applied, thanks Jason.
>
> Going over it now I don't see a lot to complain about, but I'd
> appreciate a bit more time for review in the future. 3 days ok?
I try to handle every patchwork entry within 48 hours, more
specifically 2 business days.
Given the rate at which patches flow through networking, I think
this is both reasonable and necessary.
One always have the option to send a quick reply to the list saying
"Please wait for my review, I'll get to it in the next day or two."
which I will certainly honor.
Thank you.
^ permalink raw reply
* [PATCH v3] neighbour: confirm neigh entries when ARP packet is received
From: Vasily Khoruzhick @ 2018-09-13 18:12 UTC (permalink / raw)
To: David S. Miller, Roopa Prabhu, Alexey Dobriyan, Eric Dumazet,
Stephen Hemminger, Jim Westfall, Wolfgang Bumiller,
Vasily Khoruzhick, Kees Cook, Ihar Hrachyshka, netdev,
linux-kernel, Sergei Shtylyov
Cc: Vasily Khoruzhick
Update 'confirmed' timestamp when ARP packet is received. It shouldn't
affect locktime logic and anyway entry can be confirmed by any higher-layer
protocol. Thus it makes sense to confirm it when ARP packet is received.
Fixes: 77d7123342 ("neighbour: update neigh timestamps iff update is effective")
Signed-off-by: Vasily Khoruzhick <vasilykh@arista.com>
---
v2: - update comment to match new code.
v3: - fix wording in commit message, make 'Fixes' tag one line, remove extra new line
between 'Fixes' and 'Signed-off-by'.
net/core/neighbour.c | 13 ++++++++-----
1 file changed, 8 insertions(+), 5 deletions(-)
diff --git a/net/core/neighbour.c b/net/core/neighbour.c
index aa19d86937af..91592fceeaad 100644
--- a/net/core/neighbour.c
+++ b/net/core/neighbour.c
@@ -1180,6 +1180,12 @@ int neigh_update(struct neighbour *neigh, const u8 *lladdr, u8 new,
lladdr = neigh->ha;
}
+ /* Update confirmed timestamp for neighbour entry after we
+ * received ARP packet even if it doesn't change IP to MAC binding.
+ */
+ if (new & NUD_CONNECTED)
+ neigh->confirmed = jiffies;
+
/* If entry was valid and address is not changed,
do not change entry state, if new one is STALE.
*/
@@ -1201,15 +1207,12 @@ int neigh_update(struct neighbour *neigh, const u8 *lladdr, u8 new,
}
}
- /* Update timestamps only once we know we will make a change to the
+ /* Update timestamp only once we know we will make a change to the
* neighbour entry. Otherwise we risk to move the locktime window with
* noop updates and ignore relevant ARP updates.
*/
- if (new != old || lladdr != neigh->ha) {
- if (new & NUD_CONNECTED)
- neigh->confirmed = jiffies;
+ if (new != old || lladdr != neigh->ha)
neigh->updated = jiffies;
- }
if (new != old) {
neigh_del_timer(neigh);
--
2.18.0
^ permalink raw reply related
* Compliment of the day to you Dear Friend.
From: Mrs. Amina Kadi @ 2018-09-13 13:22 UTC (permalink / raw)
Compliment of the day to you Dear Friend.
Dear Friend.
I am Mrs. Amina Kadi. am sending this brief letter to solicit your
partnership to transfer $5.5 million US Dollars. I shall send you
more information and procedures when I receive positive response from
you.
Mrs. Amina Kadi
^ permalink raw reply
* [RFC/fix] Re: libbpf build broken on musl libc (Alpine Linux)
From: Arnaldo Carvalho de Melo @ 2018-09-13 18:32 UTC (permalink / raw)
To: Alexei Starovoitov
Cc: Jakub Kicinski, Daniel Borkmann, Thomas Richter,
Hendrik Brueckner, Jiri Olsa, Namhyung Kim,
Linux Kernel Mailing List,
Linux Networking Development Mailing List
In-Reply-To: <20180911212451.hvnyfwyvcs4yojqy@ast-mbp>
Em Tue, Sep 11, 2018 at 02:24:53PM -0700, Alexei Starovoitov escreveu:
> On Tue, Sep 11, 2018 at 09:15:43AM -0300, Arnaldo Carvalho de Melo wrote:
> > Em Tue, Sep 11, 2018 at 12:22:18PM +0200, Jakub Kicinski escreveu:
> > > On Mon, 10 Sep 2018 14:29:03 -0300, Arnaldo Carvalho de Melo wrote:
> > > > After lunch I'll work on a patch to fix this,
> > > Any luck?
> > Well, we need to apply the patch below and make tools/lib/str_error_r.c
> > live in a library that libbpf and perf is linked to.
> do you want us to take the patch or you're applying it yourself?
Please do some testing with my perf/libbpf+str_error_r branch, it has
two patches to get this fixed, the one I sent and a prep one making
libbpf link against libapi.
[acme@jouet perf]$ git log --oneline -2
a7ab924b7fec (HEAD -> perf/urgent, acme.korg/perf/libbpf+str_error_r) tools lib bpf: Use str_error_r() to fix the build in Alpine Linux
fb4a79e04c2b tools lib bpf: Build and link to tools/lib/api/
[acme@jouet perf]$
I did a lot of tests to make sure tools/perf, tools/lib/bpf,
tools/bpf/bpftools and the bpf selftests all build as expected, with
OUTPUT= and in place.
The csets have further comments about tricky aspects of this.
- Arnaldo
^ permalink raw reply
* Re: [RFC PATCH iproute2-next] man: Add devlink health man page
From: Andrew Lunn @ 2018-09-13 13:24 UTC (permalink / raw)
To: Eran Ben Elisha
Cc: netdev, Jiri Pirko, Andy Gospodarek, Michael Chan, Jakub Kicinski,
Simon Horman, Alexander Duyck, Florian Fainelli, Tal Alon,
Ariel Almog
In-Reply-To: <5c12253d-2100-09bb-9e3e-6259fc7a9323@mellanox.com>
On Thu, Sep 13, 2018 at 03:49:37PM +0300, Eran Ben Elisha wrote:
>
>
> On 9/13/2018 3:08 PM, Andrew Lunn wrote:
> >> devlink health sensor set pci/0000:01:00.0 name TX_COMP_ERROR action reset off action dump on
> >> Sets TX_COMP_ERROR sensor parameters for a specific device.
> >
> >I hope the real sensors have more understandable names. If i remember
> >correctly, the same sort of comment was given for resource
> >management. It was pretty unclear what the resource names actually
> >mean. Is an average user going to have any idea how to actually use
> >these sensors and actions?
>
> well, hopefully. the whole point is to have it fully controlled by the user.
> However, names for the command should be short. I guess we shall have it
> documented (challenge is to fit to multi vendors).
>
> >
> >Can you give more examples of sensors. We should understand if there
> >are any overlaps with hwmon.
>
> I restate here that we shall have SW sensors as well, and not only HW
> sensors.
>
> This is what I had in mind:
> 1. command interface error
> 2. command interface timeout
> 3. stuck TX queue (like tx_timeout)
> 4. stuck TX completion queue (driver did not process packets in a reasonable
> time period)
> 5. stuck RX queue
> 6. RX completion error
> 7. TX completion error
> 8. HW / FW catastrophic error report
> 9. completion queue overrun
Hi Eran
I'm having trouble differentiating between these SW sensors and bugs
which need fixing. What causes a command interface error? Sending it a
command it does not understand? A wrongly formatted command? A command
the version of the firmware does not support? These all sound just
like plain old bugs which need fixing, not something which needs a
framework to detect them and try to recover from them by resetting
something.
I would of expected that all the issues are about physical
properties. Something similar to SMART for hard disks. The power
supplies are starting to droop, suggesting it might die soon. The
tacho on the fan suggests the FAN is not rotating as fast as it
should, so the motor is going to die soon. An SFP is giving i2c
errors, suggesting it is not seated correctly. The card as a whole is
overheating, despite the fan working, suggesting the ambient
temperature is just too high.
Andrew
^ permalink raw reply
* [PATCH net-next] net: phy: et011c: Remove incorrect PHY_POLL flags
From: Florian Fainelli @ 2018-09-13 18:36 UTC (permalink / raw)
To: netdev; +Cc: Florian Fainelli, Andrew Lunn, David S. Miller, open list
PHY_POLL is defined as -1 which means that we would be setting all flags of the
PHY driver, this is also not a valid flag to tell PHYLIB about, just remove it.
Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
---
drivers/net/phy/et1011c.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/net/phy/et1011c.c b/drivers/net/phy/et1011c.c
index ab541c9c56fb..565e49e7f76f 100644
--- a/drivers/net/phy/et1011c.c
+++ b/drivers/net/phy/et1011c.c
@@ -92,7 +92,6 @@ static struct phy_driver et1011c_driver[] = { {
.name = "ET1011C",
.phy_id_mask = 0xfffffff0,
.features = PHY_GBIT_FEATURES,
- .flags = PHY_POLL,
.config_aneg = et1011c_config_aneg,
.read_status = et1011c_read_status,
} };
--
2.17.1
^ permalink raw reply related
* [PATCH net-next] tg3: Fix fall-through annotations
From: Gustavo A. R. Silva @ 2018-09-13 18:39 UTC (permalink / raw)
To: Siva Reddy Kallam, Prashant Sreedharan, Michael Chan,
David S. Miller
Cc: netdev, linux-kernel, Gustavo A. R. Silva
Replace "fallthru" with a proper "fall through" annotation.
This fix is part of the ongoing efforts to enabling
-Wimplicit-fallthrough
Signed-off-by: Gustavo A. R. Silva <gustavo@embeddedor.com>
---
drivers/net/ethernet/broadcom/tg3.c | 12 ++++++------
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/drivers/net/ethernet/broadcom/tg3.c b/drivers/net/ethernet/broadcom/tg3.c
index e6f28c7..ee7ef32 100644
--- a/drivers/net/ethernet/broadcom/tg3.c
+++ b/drivers/net/ethernet/broadcom/tg3.c
@@ -1598,7 +1598,7 @@ static int tg3_mdio_init(struct tg3 *tp)
phydev->dev_flags |= PHY_BRCM_EXT_IBND_RX_ENABLE;
if (tg3_flag(tp, RGMII_EXT_IBND_TX_EN))
phydev->dev_flags |= PHY_BRCM_EXT_IBND_TX_ENABLE;
- /* fallthru */
+ /* fall through */
case PHY_ID_RTL8211C:
phydev->interface = PHY_INTERFACE_MODE_RGMII;
break;
@@ -2127,7 +2127,7 @@ static int tg3_phy_init(struct tg3 *tp)
SUPPORTED_Asym_Pause);
break;
}
- /* fallthru */
+ /* fall through */
case PHY_INTERFACE_MODE_MII:
phydev->supported &= (PHY_BASIC_FEATURES |
SUPPORTED_Pause |
@@ -5215,7 +5215,7 @@ static int tg3_fiber_aneg_smachine(struct tg3 *tp,
if (ap->flags & (MR_AN_ENABLE | MR_RESTART_AN))
ap->state = ANEG_STATE_AN_ENABLE;
- /* fallthru */
+ /* fall through */
case ANEG_STATE_AN_ENABLE:
ap->flags &= ~(MR_AN_COMPLETE | MR_PAGE_RX);
if (ap->flags & MR_AN_ENABLE) {
@@ -5245,7 +5245,7 @@ static int tg3_fiber_aneg_smachine(struct tg3 *tp,
ret = ANEG_TIMER_ENAB;
ap->state = ANEG_STATE_RESTART;
- /* fallthru */
+ /* fall through */
case ANEG_STATE_RESTART:
delta = ap->cur_time - ap->link_time;
if (delta > ANEG_STATE_SETTLE_TIME)
@@ -5288,7 +5288,7 @@ static int tg3_fiber_aneg_smachine(struct tg3 *tp,
ap->state = ANEG_STATE_ACK_DETECT;
- /* fallthru */
+ /* fall through */
case ANEG_STATE_ACK_DETECT:
if (ap->ack_match != 0) {
if ((ap->rxconfig & ~ANEG_CFG_ACK) ==
@@ -14013,7 +14013,7 @@ static int tg3_ioctl(struct net_device *dev, struct ifreq *ifr, int cmd)
case SIOCGMIIPHY:
data->phy_id = tp->phy_addr;
- /* fallthru */
+ /* fall through */
case SIOCGMIIREG: {
u32 mii_regval;
--
2.7.4
^ permalink raw reply related
* general protection fault in xfrmi_rcv_cb
From: syzbot @ 2018-09-13 13:31 UTC (permalink / raw)
To: davem, herbert, linux-kernel, netdev, steffen.klassert,
syzkaller-bugs
Hello,
syzbot found the following crash on:
HEAD commit: 11957be20ff6 htb: use anonymous union for simplicity
git tree: net-next
console output: https://syzkaller.appspot.com/x/log.txt?x=1773c6da400000
kernel config: https://syzkaller.appspot.com/x/.config?x=8f59875069d721b6
dashboard link: https://syzkaller.appspot.com/bug?extid=af91688fec2b033aa620
compiler: gcc (GCC) 8.0.1 20180413 (experimental)
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+af91688fec2b033aa620@syzkaller.appspotmail.com
RBP: 0000000020000000 R08: 00000000000000f0 R09: 0000000000000000
R10: 0000000000000064 R11: 0000000000000293 R12: 0000000000000004
R13: 00000000004d7270 R14: 00000000004ca37e R15: 0000000000000003
kasan: CONFIG_KASAN_INLINE enabled
kasan: GPF could be caused by NULL-ptr deref or user memory access
general protection fault: 0000 [#1] PREEMPT SMP KASAN
CPU: 0 PID: 12674 Comm: syz-executor3 Not tainted 4.19.0-rc2+ #211
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
Google 01/01/2011
RIP: 0010:xs_net include/net/xfrm.h:253 [inline]
RIP: 0010:xfrmi_rcv_cb+0xd4/0x9d0 net/xfrm/xfrm_interface.c:256
Code: 7c e5 10 48 89 fa 48 c1 ea 03 80 3c 02 00 0f 85 f0 07 00 00 48 b8 00
00 00 00 00 fc ff df 4f 8b 64 e5 10 4c 89 e2 48 c1 ea 03 <80> 3c 02 00 0f
85 da 07 00 00 49 8b 3c 24 49 8d b4 24 d0 00 00 00
RSP: 0018:ffff88019dd3e968 EFLAGS: 00010246
RAX: dffffc0000000000 RBX: ffff8801c56c5bc0 RCX: ffffc90003252000
RDX: 0000000000000000 RSI: ffffffff86b73915 RDI: ffff8801b93b6b88
RBP: ffff88019dd3e9a8 R08: ffff880191300640 R09: 1ffffffff12f43cd
R10: ffffed003b584732 R11: ffff8801dac23993 R12: 0000000000000000
R13: ffff8801b93b6b80 R14: ffff8801c56c5c28 R15: 0000000000000001
FS: 00007f969fbaa700(0000) GS:ffff8801dac00000(0000) knlGS:0000000000000000
kobject: 'loop0' (000000007546342c): kobject_uevent_env
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 0000000000000000 CR3: 000000019bf04000 CR4: 00000000001406f0
Call Trace:
xfrm6_rcv_cb+0x220/0x400 net/ipv6/xfrm6_protocol.c:59
kobject: 'tx-3' (000000000393e75f): kobject_uevent_env
xfrm_rcv_cb net/xfrm/xfrm_input.c:108 [inline]
xfrm_input+0x8aa/0x3190 net/xfrm/xfrm_input.c:495
kobject: 'loop0' (000000007546342c): fill_kobj_path: path
= '/devices/virtual/block/loop0'
kobject: 'tx-3' (000000000393e75f): fill_kobj_path: path
= '/devices/virtual/mac80211_hwsim/hwsim3/net/wlan1/queues/tx-3'
kobject: 'loop1' (000000003d7d00b3): kobject_uevent_env
kobject: 'loop1' (000000003d7d00b3): fill_kobj_path: path
= '/devices/virtual/block/loop1'
xfrm6_rcv_spi net/ipv6/xfrm6_input.c:31 [inline]
xfrm6_rcv_tnl+0x168/0x1d0 net/ipv6/xfrm6_input.c:73
xfrm6_rcv+0x17/0x20 net/ipv6/xfrm6_input.c:80
kobject: 'loop4' (00000000627de047): kobject_uevent_env
xfrm6_esp_rcv+0x1a5/0x3a0 net/ipv6/xfrm6_protocol.c:74
kobject: 'loop4' (00000000627de047): fill_kobj_path: path
= '/devices/virtual/block/loop4'
ip6_input_finish+0x3fc/0x1aa0 net/ipv6/ip6_input.c:383
NF_HOOK include/linux/netfilter.h:287 [inline]
ip6_input+0xe9/0x600 net/ipv6/ip6_input.c:426
ip6_mc_input+0x48a/0xd20 net/ipv6/ip6_input.c:503
dst_input include/net/dst.h:450 [inline]
ip6_rcv_finish+0x17a/0x330 net/ipv6/ip6_input.c:76
NF_HOOK include/linux/netfilter.h:287 [inline]
ipv6_rcv+0x11e/0x650 net/ipv6/ip6_input.c:271
__netif_receive_skb_one_core+0x14d/0x200 net/core/dev.c:4894
__netif_receive_skb+0x2c/0x1e0 net/core/dev.c:5004
netif_receive_skb_internal+0x12c/0x620 net/core/dev.c:5107
napi_frags_finish net/core/dev.c:5643 [inline]
napi_gro_frags+0x75a/0xc90 net/core/dev.c:5716
tun_get_user+0x31d5/0x42a0 drivers/net/tun.c:1965
tun_chr_write_iter+0xb9/0x154 drivers/net/tun.c:2010
call_write_iter include/linux/fs.h:1807 [inline]
do_iter_readv_writev+0x8b0/0xa80 fs/read_write.c:680
do_iter_write+0x185/0x5f0 fs/read_write.c:959
vfs_writev+0x1f1/0x360 fs/read_write.c:1004
do_writev+0x11a/0x310 fs/read_write.c:1039
__do_sys_writev fs/read_write.c:1112 [inline]
__se_sys_writev fs/read_write.c:1109 [inline]
__x64_sys_writev+0x75/0xb0 fs/read_write.c:1109
do_syscall_64+0x1b9/0x820 arch/x86/entry/common.c:290
entry_SYSCALL_64_after_hwframe+0x49/0xbe
RIP: 0033:0x457161
Code: 75 14 b8 14 00 00 00 0f 05 48 3d 01 f0 ff ff 0f 83 34 b6 fb ff c3 48
83 ec 08 e8 da 2c 00 00 48 89 04 24 b8 14 00 00 00 0f 05 <48> 8b 3c 24 48
89 c2 e8 23 2d 00 00 48 89 d0 48 83 c4 08 48 3d 01
RSP: 002b:00007f969fba9ba0 EFLAGS: 00000293 ORIG_RAX: 0000000000000014
RAX: ffffffffffffffda RBX: 000000000000004a RCX: 0000000000457161
RDX: 0000000000000001 RSI: 00007f969fba9bf0 RDI: 00000000000000f0
RBP: 0000000020000000 R08: 00000000000000f0 R09: 0000000000000000
R10: 0000000000000064 R11: 0000000000000293 R12: 0000000000000004
R13: 00000000004d7270 R14: 00000000004ca37e R15: 0000000000000003
Modules linked in:
---[ end trace 37ac9ade311d7a37 ]---
RIP: 0010:xs_net include/net/xfrm.h:253 [inline]
RIP: 0010:xfrmi_rcv_cb+0xd4/0x9d0 net/xfrm/xfrm_interface.c:256
Code: 7c e5 10 48 89 fa 48 c1 ea 03 80 3c 02 00 0f 85 f0 07 00 00 48 b8 00
00 00 00 00 fc ff df 4f 8b 64 e5 10 4c 89 e2 48 c1 ea 03 <80> 3c 02 00 0f
85 da 07 00 00 49 8b 3c 24 49 8d b4 24 d0 00 00 00
RSP: 0018:ffff88019dd3e968 EFLAGS: 00010246
RAX: dffffc0000000000 RBX: ffff8801c56c5bc0 RCX: ffffc90003252000
RDX: 0000000000000000 RSI: ffffffff86b73915 RDI: ffff8801b93b6b88
RBP: ffff88019dd3e9a8 R08: ffff880191300640 R09: 1ffffffff12f43cd
R10: ffffed003b584732 R11: ffff8801dac23993 R12: 0000000000000000
R13: ffff8801b93b6b80 R14: ffff8801c56c5c28 R15: 0000000000000001
FS: 00007f969fbaa700(0000) GS:ffff8801dac00000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 0000000000000000 CR3: 000000019bf04000 CR4: 00000000001406f0
---
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#bug-status-tracking for how to communicate with
syzbot.
^ permalink raw reply
* Re: [RFC/fix] Re: libbpf build broken on musl libc (Alpine Linux)
From: Alexei Starovoitov @ 2018-09-13 18:56 UTC (permalink / raw)
To: Arnaldo Carvalho de Melo
Cc: Jakub Kicinski, Daniel Borkmann, Thomas Richter,
Hendrik Brueckner, Jiri Olsa, Namhyung Kim,
Linux Kernel Mailing List,
Linux Networking Development Mailing List
In-Reply-To: <20180913183240.GF30969@kernel.org>
On Thu, Sep 13, 2018 at 03:32:40PM -0300, Arnaldo Carvalho de Melo wrote:
> Em Tue, Sep 11, 2018 at 02:24:53PM -0700, Alexei Starovoitov escreveu:
> > On Tue, Sep 11, 2018 at 09:15:43AM -0300, Arnaldo Carvalho de Melo wrote:
> > > Em Tue, Sep 11, 2018 at 12:22:18PM +0200, Jakub Kicinski escreveu:
> > > > On Mon, 10 Sep 2018 14:29:03 -0300, Arnaldo Carvalho de Melo wrote:
> > > > > After lunch I'll work on a patch to fix this,
> > > > Any luck?
>
> > > Well, we need to apply the patch below and make tools/lib/str_error_r.c
> > > live in a library that libbpf and perf is linked to.
>
> > do you want us to take the patch or you're applying it yourself?
>
> Please do some testing with my perf/libbpf+str_error_r branch, it has
> two patches to get this fixed, the one I sent and a prep one making
> libbpf link against libapi.
>
> [acme@jouet perf]$ git log --oneline -2
> a7ab924b7fec (HEAD -> perf/urgent, acme.korg/perf/libbpf+str_error_r) tools lib bpf: Use str_error_r() to fix the build in Alpine Linux
> fb4a79e04c2b tools lib bpf: Build and link to tools/lib/api/
https://git.kernel.org/pub/scm/linux/kernel/git/acme/linux.git/commit/?h=perf/libbpf%2bstr_error_r&id=fb4a79e04c2b37ee873a3b31a3250925cf466fff
we cannot do this.
lib/api is GPL we cannot use it in LGPL library.
^ permalink raw reply
* Re: [PATCH v3] neighbour: confirm neigh entries when ARP packet is received
From: David Miller @ 2018-09-13 19:02 UTC (permalink / raw)
To: sergei.shtylyov
Cc: vasilykh, roopa, adobriyan, edumazet, stephen, jwestfall,
w.bumiller, anarsoul, keescook, ihrachys, netdev, linux-kernel
In-Reply-To: <16ad730b-ef79-62b0-4b11-9473c0b033e1@cogentembedded.com>
From: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
Date: Thu, 13 Sep 2018 21:26:42 +0300
> Hello!
>
> On 09/13/2018 09:12 PM, Vasily Khoruzhick wrote:
>
>> Update 'confirmed' timestamp when ARP packet is received. It shouldn't
>> affect locktime logic and anyway entry can be confirmed by any higher-layer
>> protocol. Thus it makes sense to confirm it when ARP packet is received.
>>
>> Fixes: 77d7123342 ("neighbour: update neigh timestamps iff update is effective")
>
> Need at least 12 hex digits... Perhaps could be fixed when applying?
Yeah I took care of that.
>
>> Signed-off-by: Vasily Khoruzhick <vasilykh@arista.com>
> [...]
Applied and queued up for -stable.
^ permalink raw reply
* [PATCH net-next] pktgen: Fix fall-through annotation
From: Gustavo A. R. Silva @ 2018-09-13 19:03 UTC (permalink / raw)
To: David S. Miller; +Cc: netdev, linux-kernel, Gustavo A. R. Silva
Replace "fallthru" with a proper "fall through" annotation.
This fix is part of the ongoing efforts to enabling
-Wimplicit-fallthrough
Signed-off-by: Gustavo A. R. Silva <gustavo@embeddedor.com>
---
net/core/pktgen.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/net/core/pktgen.c b/net/core/pktgen.c
index 7f69384..6ac9198 100644
--- a/net/core/pktgen.c
+++ b/net/core/pktgen.c
@@ -3426,7 +3426,7 @@ static void pktgen_xmit(struct pktgen_dev *pkt_dev)
net_info_ratelimited("%s xmit error: %d\n",
pkt_dev->odevname, ret);
pkt_dev->errors++;
- /* fallthru */
+ /* fall through */
case NETDEV_TX_BUSY:
/* Retry it next time */
refcount_dec(&(pkt_dev->skb->users));
--
2.7.4
^ permalink raw reply related
* Re: KMSAN: uninit-value in pppoe_rcv
From: Eric Dumazet @ 2018-09-13 13:57 UTC (permalink / raw)
To: Alexander Potapenko, syzbot+f5f6080811c849739212
Cc: LKML, mostrows, Networking, syzkaller-bugs
In-Reply-To: <CAG_fn=Vk2HMPCLJV3aj1dt0KkDmksasBRRfKGnCTRHjvQ6OnQg@mail.gmail.com>
On 09/12/2018 03:38 AM, Alexander Potapenko wrote:
> On Wed, Sep 12, 2018 at 12:24 PM syzbot
> <syzbot+f5f6080811c849739212@syzkaller.appspotmail.com> wrote:
>>
>> Hello,
>>
>> syzbot found the following crash on:
>>
>> HEAD commit: d2d741e5d189 kmsan: add initialization for shmem pages
>> git tree: https://github.com/google/kmsan.git/master
>> console output: https://syzkaller.appspot.com/x/log.txt?x=1465fc37800000
>> kernel config: https://syzkaller.appspot.com/x/.config?x=48f9de3384bcd0f
>> dashboard link: https://syzkaller.appspot.com/bug?extid=f5f6080811c849739212
>> compiler: clang version 7.0.0 (trunk 329391)
>> syz repro: https://syzkaller.appspot.com/x/repro.syz?x=14d6e607800000
>> C reproducer: https://syzkaller.appspot.com/x/repro.c?x=10a15b5b800000
>>
>> IMPORTANT: if you fix the bug, please add the following tag to the commit:
>> Reported-by: syzbot+f5f6080811c849739212@syzkaller.appspotmail.com
>>
>> IPVS: ftp: loaded support on port[0] = 21
>> ==================================================================
>> BUG: KMSAN: uninit-value in __get_item drivers/net/ppp/pppoe.c:172 [inline]
>> BUG: KMSAN: uninit-value in get_item drivers/net/ppp/pppoe.c:236 [inline]
>> BUG: KMSAN: uninit-value in pppoe_rcv+0xcef/0x10e0
>> drivers/net/ppp/pppoe.c:450
>> CPU: 0 PID: 4543 Comm: syz-executor355 Not tainted 4.16.0+ #87
>> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
>> Google 01/01/2011
>> Call Trace:
>> __dump_stack lib/dump_stack.c:17 [inline]
>> dump_stack+0x185/0x1d0 lib/dump_stack.c:53
>> kmsan_report+0x142/0x240 mm/kmsan/kmsan.c:1067
>> __msan_warning_32+0x6c/0xb0 mm/kmsan/kmsan_instr.c:683
>> __get_item drivers/net/ppp/pppoe.c:172 [inline]
>> get_item drivers/net/ppp/pppoe.c:236 [inline]
>> pppoe_rcv+0xcef/0x10e0 drivers/net/ppp/pppoe.c:450
>> __netif_receive_skb_core+0x47df/0x4a90 net/core/dev.c:4562
>> __netif_receive_skb net/core/dev.c:4627 [inline]
>> netif_receive_skb_internal+0x49d/0x630 net/core/dev.c:4701
>> netif_receive_skb+0x230/0x240 net/core/dev.c:4725
>> tun_rx_batched drivers/net/tun.c:1555 [inline]
>> tun_get_user+0x740f/0x7c60 drivers/net/tun.c:1962
>> tun_chr_write_iter+0x1d4/0x330 drivers/net/tun.c:1990
>> call_write_iter include/linux/fs.h:1782 [inline]
>> new_sync_write fs/read_write.c:469 [inline]
>> __vfs_write+0x7fb/0x9f0 fs/read_write.c:482
>> vfs_write+0x463/0x8d0 fs/read_write.c:544
>> SYSC_write+0x172/0x360 fs/read_write.c:589
>> SyS_write+0x55/0x80 fs/read_write.c:581
>> do_syscall_64+0x309/0x430 arch/x86/entry/common.c:287
>> entry_SYSCALL_64_after_hwframe+0x3d/0xa2
>> RIP: 0033:0x4447c9
>> RSP: 002b:00007fff64c8fc28 EFLAGS: 00000297 ORIG_RAX: 0000000000000001
>> RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00000000004447c9
>> RDX: 000000000000fd87 RSI: 0000000020000600 RDI: 0000000000000004
>> RBP: 00000000006cf018 R08: 00007fff64c8fda8 R09: 00007fff00006bda
>> R10: 0000000000005fe7 R11: 0000000000000297 R12: 00000000004020d0
>> R13: 0000000000402160 R14: 0000000000000000 R15: 0000000000000000
>>
>> Uninit was created at:
>> kmsan_save_stack_with_flags mm/kmsan/kmsan.c:278 [inline]
>> kmsan_internal_poison_shadow+0xb8/0x1b0 mm/kmsan/kmsan.c:188
>> kmsan_kmalloc+0x94/0x100 mm/kmsan/kmsan.c:314
>> kmsan_slab_alloc+0x11/0x20 mm/kmsan/kmsan.c:321
>> slab_post_alloc_hook mm/slab.h:445 [inline]
>> slab_alloc_node mm/slub.c:2737 [inline]
>> __kmalloc_node_track_caller+0xaed/0x11c0 mm/slub.c:4369
>> __kmalloc_reserve net/core/skbuff.c:138 [inline]
>> __alloc_skb+0x2cf/0x9f0 net/core/skbuff.c:206
>> alloc_skb include/linux/skbuff.h:984 [inline]
>> alloc_skb_with_frags+0x1d4/0xb20 net/core/skbuff.c:5234
>> sock_alloc_send_pskb+0xb56/0x1190 net/core/sock.c:2085
>> tun_alloc_skb drivers/net/tun.c:1532 [inline]
>> tun_get_user+0x2242/0x7c60 drivers/net/tun.c:1829
>> tun_chr_write_iter+0x1d4/0x330 drivers/net/tun.c:1990
>> call_write_iter include/linux/fs.h:1782 [inline]
>> new_sync_write fs/read_write.c:469 [inline]
>> __vfs_write+0x7fb/0x9f0 fs/read_write.c:482
>> vfs_write+0x463/0x8d0 fs/read_write.c:544
>> SYSC_write+0x172/0x360 fs/read_write.c:589
>> SyS_write+0x55/0x80 fs/read_write.c:581
>> do_syscall_64+0x309/0x430 arch/x86/entry/common.c:287
>> entry_SYSCALL_64_after_hwframe+0x3d/0xa2
>> ==================================================================
> I did a little digging before sending the bug upstream.
> If I add memset(obj, 0xfe, size) to __kmalloc_reserve(), these 0xfe
> bytes are visible in __get_item() at the place where KMSAN reports an
> error.
>
> The problem is somehow related to tun_get_user() creating a fragmented
> sk_buff - when I change the call to tun_alloc_skb() so that it
> allocates a single buffer the bug goes away.
>
I guess the following patch would fix the issue
(I will submit it more formally)
diff --git a/drivers/net/ppp/pppoe.c b/drivers/net/ppp/pppoe.c
index ce61231e96ea5fe27f512fbd0d80d4609997e508..333e967ed968ea3ff2dda25289f7f657263db2b9 100644
--- a/drivers/net/ppp/pppoe.c
+++ b/drivers/net/ppp/pppoe.c
@@ -423,6 +423,7 @@ static int pppoe_rcv(struct sk_buff *skb, struct net_device *dev,
struct pppoe_hdr *ph;
struct pppox_sock *po;
struct pppoe_net *pn;
+ __be16 sid;
int len;
skb = skb_share_check(skb, GFP_ATOMIC);
@@ -434,6 +435,7 @@ static int pppoe_rcv(struct sk_buff *skb, struct net_device *dev,
ph = pppoe_hdr(skb);
len = ntohs(ph->length);
+ sid = ph->sid;
skb_pull_rcsum(skb, sizeof(*ph));
if (skb->len < len)
@@ -447,7 +449,7 @@ static int pppoe_rcv(struct sk_buff *skb, struct net_device *dev,
/* Note that get_item does a sock_hold(), so sk_pppox(po)
* is known to be safe.
*/
- po = get_item(pn, ph->sid, eth_hdr(skb)->h_source, dev->ifindex);
+ po = get_item(pn, sid, eth_hdr(skb)->h_source, dev->ifindex);
if (!po)
goto drop;
^ permalink raw reply related
* Re: [PATCH v3] neighbour: confirm neigh entries when ARP packet is received
From: Vasiliy Khoruzhick @ 2018-09-13 19:10 UTC (permalink / raw)
To: David Miller
Cc: sergei.shtylyov, Roopa Prabhu, Alexey Dobriyan, Eric Dumazet,
Stephen Hemminger, Jim Westfall, Wolfgang Bumiller,
Vasily Khoruzhick, Kees Cook, Ihar Hrachyshka, netdev,
linux-kernel
In-Reply-To: <20180913.120241.924379440079172532.davem@davemloft.net>
On Thu, Sep 13, 2018 at 12:02 PM, David Miller <davem@davemloft.net> wrote:
> From: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
> Date: Thu, 13 Sep 2018 21:26:42 +0300
>
>> Hello!
>>
>> On 09/13/2018 09:12 PM, Vasily Khoruzhick wrote:
>>
>>> Update 'confirmed' timestamp when ARP packet is received. It shouldn't
>>> affect locktime logic and anyway entry can be confirmed by any higher-layer
>>> protocol. Thus it makes sense to confirm it when ARP packet is received.
>>>
>>> Fixes: 77d7123342 ("neighbour: update neigh timestamps iff update is effective")
>>
>> Need at least 12 hex digits... Perhaps could be fixed when applying?
>
> Yeah I took care of that.
>
>>
>>> Signed-off-by: Vasily Khoruzhick <vasilykh@arista.com>
>> [...]
>
> Applied and queued up for -stable.
Thanks!
^ permalink raw reply
* Re: [PATCH net-next] vxlan: Remove duplicated include from vxlan.h
From: David Miller @ 2018-09-13 19:10 UTC (permalink / raw)
To: yuehaibing; +Cc: linux-kernel, netdev
In-Reply-To: <20180913133223.14984-1-yuehaibing@huawei.com>
From: YueHaibing <yuehaibing@huawei.com>
Date: Thu, 13 Sep 2018 21:32:23 +0800
> Remove duplicated include.
>
> Signed-off-by: YueHaibing <yuehaibing@huawei.com>
Applied and queued up for -stable.
^ permalink raw reply
* Re: [PATCH net-next] net: phy: et011c: Remove incorrect PHY_POLL flags
From: Andrew Lunn @ 2018-09-13 19:13 UTC (permalink / raw)
To: Florian Fainelli; +Cc: netdev, David S. Miller, open list
In-Reply-To: <20180913183630.32584-1-f.fainelli@gmail.com>
On Thu, Sep 13, 2018 at 11:36:30AM -0700, Florian Fainelli wrote:
> PHY_POLL is defined as -1 which means that we would be setting all flags of the
> PHY driver, this is also not a valid flag to tell PHYLIB about, just remove it.
>
> Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Andrew
^ permalink raw reply
* Re: [PATCH net] gso_segment: Reset skb->mac_len after modifying network header
From: Eric Dumazet @ 2018-09-13 14:11 UTC (permalink / raw)
To: Toke Høiland-Jørgensen, netdev; +Cc: cake, Eric Dumazet
In-Reply-To: <153670437243.12756.693381878569982309.stgit@alrua-kau>
On 09/11/2018 03:19 PM, Toke Høiland-Jørgensen wrote:
> When splitting a GSO segment that consists of encapsulated packets, the
> skb->mac_len of the segments can end up being set wrong, causing packet
> drops in particular when using act_mirred and ifb interfaces in
> combination with a qdisc that splits GSO packets.
>
> This happens because at the time skb_segment() is called, network_header
> will point to the inner header, throwing off the calculation in
> skb_reset_mac_len(). The network_header is subsequently adjust by the
> outer IP gso_segment handlers, but they don't set the mac_len.
>
> Fix this by adding skb_reset_mac_len() calls to both the IPv4 and IPv6
> gso_segment handlers, after they modify the network_header.
>
> Signed-off-by: Toke Høiland-Jørgensen <toke@toke.dk>
Looks good but I would have appreciated a thanks or something
after the help I gave on this problem.
Reviewed-by: Eric Dumazet <edumazet@google.com>
^ permalink raw reply
* Re: KMSAN: uninit-value in pppoe_rcv
From: Alexander Potapenko @ 2018-09-13 14:12 UTC (permalink / raw)
To: Eric Dumazet
Cc: syzbot+f5f6080811c849739212, LKML, mostrows, Networking,
syzkaller-bugs
In-Reply-To: <7424e094-afda-084a-ad80-299f219ced92@gmail.com>
On Thu, Sep 13, 2018 at 3:57 PM Eric Dumazet <eric.dumazet@gmail.com> wrote:
>
>
>
> On 09/12/2018 03:38 AM, Alexander Potapenko wrote:
> > On Wed, Sep 12, 2018 at 12:24 PM syzbot
> > <syzbot+f5f6080811c849739212@syzkaller.appspotmail.com> wrote:
> >>
> >> Hello,
> >>
> >> syzbot found the following crash on:
> >>
> >> HEAD commit: d2d741e5d189 kmsan: add initialization for shmem pages
> >> git tree: https://github.com/google/kmsan.git/master
> >> console output: https://syzkaller.appspot.com/x/log.txt?x=1465fc37800000
> >> kernel config: https://syzkaller.appspot.com/x/.config?x=48f9de3384bcd0f
> >> dashboard link: https://syzkaller.appspot.com/bug?extid=f5f6080811c849739212
> >> compiler: clang version 7.0.0 (trunk 329391)
> >> syz repro: https://syzkaller.appspot.com/x/repro.syz?x=14d6e607800000
> >> C reproducer: https://syzkaller.appspot.com/x/repro.c?x=10a15b5b800000
> >>
> >> IMPORTANT: if you fix the bug, please add the following tag to the commit:
> >> Reported-by: syzbot+f5f6080811c849739212@syzkaller.appspotmail.com
> >>
> >> IPVS: ftp: loaded support on port[0] = 21
> >> ==================================================================
> >> BUG: KMSAN: uninit-value in __get_item drivers/net/ppp/pppoe.c:172 [inline]
> >> BUG: KMSAN: uninit-value in get_item drivers/net/ppp/pppoe.c:236 [inline]
> >> BUG: KMSAN: uninit-value in pppoe_rcv+0xcef/0x10e0
> >> drivers/net/ppp/pppoe.c:450
> >> CPU: 0 PID: 4543 Comm: syz-executor355 Not tainted 4.16.0+ #87
> >> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
> >> Google 01/01/2011
> >> Call Trace:
> >> __dump_stack lib/dump_stack.c:17 [inline]
> >> dump_stack+0x185/0x1d0 lib/dump_stack.c:53
> >> kmsan_report+0x142/0x240 mm/kmsan/kmsan.c:1067
> >> __msan_warning_32+0x6c/0xb0 mm/kmsan/kmsan_instr.c:683
> >> __get_item drivers/net/ppp/pppoe.c:172 [inline]
> >> get_item drivers/net/ppp/pppoe.c:236 [inline]
> >> pppoe_rcv+0xcef/0x10e0 drivers/net/ppp/pppoe.c:450
> >> __netif_receive_skb_core+0x47df/0x4a90 net/core/dev.c:4562
> >> __netif_receive_skb net/core/dev.c:4627 [inline]
> >> netif_receive_skb_internal+0x49d/0x630 net/core/dev.c:4701
> >> netif_receive_skb+0x230/0x240 net/core/dev.c:4725
> >> tun_rx_batched drivers/net/tun.c:1555 [inline]
> >> tun_get_user+0x740f/0x7c60 drivers/net/tun.c:1962
> >> tun_chr_write_iter+0x1d4/0x330 drivers/net/tun.c:1990
> >> call_write_iter include/linux/fs.h:1782 [inline]
> >> new_sync_write fs/read_write.c:469 [inline]
> >> __vfs_write+0x7fb/0x9f0 fs/read_write.c:482
> >> vfs_write+0x463/0x8d0 fs/read_write.c:544
> >> SYSC_write+0x172/0x360 fs/read_write.c:589
> >> SyS_write+0x55/0x80 fs/read_write.c:581
> >> do_syscall_64+0x309/0x430 arch/x86/entry/common.c:287
> >> entry_SYSCALL_64_after_hwframe+0x3d/0xa2
> >> RIP: 0033:0x4447c9
> >> RSP: 002b:00007fff64c8fc28 EFLAGS: 00000297 ORIG_RAX: 0000000000000001
> >> RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00000000004447c9
> >> RDX: 000000000000fd87 RSI: 0000000020000600 RDI: 0000000000000004
> >> RBP: 00000000006cf018 R08: 00007fff64c8fda8 R09: 00007fff00006bda
> >> R10: 0000000000005fe7 R11: 0000000000000297 R12: 00000000004020d0
> >> R13: 0000000000402160 R14: 0000000000000000 R15: 0000000000000000
> >>
> >> Uninit was created at:
> >> kmsan_save_stack_with_flags mm/kmsan/kmsan.c:278 [inline]
> >> kmsan_internal_poison_shadow+0xb8/0x1b0 mm/kmsan/kmsan.c:188
> >> kmsan_kmalloc+0x94/0x100 mm/kmsan/kmsan.c:314
> >> kmsan_slab_alloc+0x11/0x20 mm/kmsan/kmsan.c:321
> >> slab_post_alloc_hook mm/slab.h:445 [inline]
> >> slab_alloc_node mm/slub.c:2737 [inline]
> >> __kmalloc_node_track_caller+0xaed/0x11c0 mm/slub.c:4369
> >> __kmalloc_reserve net/core/skbuff.c:138 [inline]
> >> __alloc_skb+0x2cf/0x9f0 net/core/skbuff.c:206
> >> alloc_skb include/linux/skbuff.h:984 [inline]
> >> alloc_skb_with_frags+0x1d4/0xb20 net/core/skbuff.c:5234
> >> sock_alloc_send_pskb+0xb56/0x1190 net/core/sock.c:2085
> >> tun_alloc_skb drivers/net/tun.c:1532 [inline]
> >> tun_get_user+0x2242/0x7c60 drivers/net/tun.c:1829
> >> tun_chr_write_iter+0x1d4/0x330 drivers/net/tun.c:1990
> >> call_write_iter include/linux/fs.h:1782 [inline]
> >> new_sync_write fs/read_write.c:469 [inline]
> >> __vfs_write+0x7fb/0x9f0 fs/read_write.c:482
> >> vfs_write+0x463/0x8d0 fs/read_write.c:544
> >> SYSC_write+0x172/0x360 fs/read_write.c:589
> >> SyS_write+0x55/0x80 fs/read_write.c:581
> >> do_syscall_64+0x309/0x430 arch/x86/entry/common.c:287
> >> entry_SYSCALL_64_after_hwframe+0x3d/0xa2
> >> ==================================================================
> > I did a little digging before sending the bug upstream.
> > If I add memset(obj, 0xfe, size) to __kmalloc_reserve(), these 0xfe
> > bytes are visible in __get_item() at the place where KMSAN reports an
> > error.
> >
> > The problem is somehow related to tun_get_user() creating a fragmented
> > sk_buff - when I change the call to tun_alloc_skb() so that it
> > allocates a single buffer the bug goes away.
> >
>
> I guess the following patch would fix the issue
>
> (I will submit it more formally)
No, as far as I can see it doesn't.
Saving sid before __skb_pull() is still a good idea, but in this
particular case |ph| doesn't change.
> diff --git a/drivers/net/ppp/pppoe.c b/drivers/net/ppp/pppoe.c
> index ce61231e96ea5fe27f512fbd0d80d4609997e508..333e967ed968ea3ff2dda25289f7f657263db2b9 100644
> --- a/drivers/net/ppp/pppoe.c
> +++ b/drivers/net/ppp/pppoe.c
> @@ -423,6 +423,7 @@ static int pppoe_rcv(struct sk_buff *skb, struct net_device *dev,
> struct pppoe_hdr *ph;
> struct pppox_sock *po;
> struct pppoe_net *pn;
> + __be16 sid;
> int len;
>
> skb = skb_share_check(skb, GFP_ATOMIC);
> @@ -434,6 +435,7 @@ static int pppoe_rcv(struct sk_buff *skb, struct net_device *dev,
>
> ph = pppoe_hdr(skb);
> len = ntohs(ph->length);
> + sid = ph->sid;
>
> skb_pull_rcsum(skb, sizeof(*ph));
> if (skb->len < len)
> @@ -447,7 +449,7 @@ static int pppoe_rcv(struct sk_buff *skb, struct net_device *dev,
> /* Note that get_item does a sock_hold(), so sk_pppox(po)
> * is known to be safe.
> */
> - po = get_item(pn, ph->sid, eth_hdr(skb)->h_source, dev->ifindex);
> + po = get_item(pn, sid, eth_hdr(skb)->h_source, dev->ifindex);
> if (!po)
> goto drop;
>
>
>
> --
> You received this message because you are subscribed to the Google Groups "syzkaller-bugs" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to syzkaller-bugs+unsubscribe@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/msgid/syzkaller-bugs/7424e094-afda-084a-ad80-299f219ced92%40gmail.com.
> For more options, visit https://groups.google.com/d/optout.
--
Alexander Potapenko
Software Engineer
Google Germany GmbH
Erika-Mann-Straße, 33
80636 München
Geschäftsführer: Paul Manicle, Halimah DeLaine Prado
Registergericht und -nummer: Hamburg, HRB 86891
Sitz der Gesellschaft: Hamburg
^ permalink raw reply
* Re: [Cake] [PATCH net] gso_segment: Reset skb->mac_len after modifying network header
From: Dave Taht @ 2018-09-13 14:14 UTC (permalink / raw)
To: Eric Dumazet
Cc: Toke Høiland-Jørgensen, Linux Kernel Network Developers,
Cake List, Eric Dumazet
In-Reply-To: <5dc16f03-7cd2-f797-1bda-592d5f5462b5@gmail.com>
On Thu, Sep 13, 2018 at 7:11 AM Eric Dumazet <eric.dumazet@gmail.com> wrote:
>
>
>
> On 09/11/2018 03:19 PM, Toke Høiland-Jørgensen wrote:
> > When splitting a GSO segment that consists of encapsulated packets, the
> > skb->mac_len of the segments can end up being set wrong, causing packet
> > drops in particular when using act_mirred and ifb interfaces in
> > combination with a qdisc that splits GSO packets.
> >
> > This happens because at the time skb_segment() is called, network_header
> > will point to the inner header, throwing off the calculation in
> > skb_reset_mac_len(). The network_header is subsequently adjust by the
> > outer IP gso_segment handlers, but they don't set the mac_len.
> >
> > Fix this by adding skb_reset_mac_len() calls to both the IPv4 and IPv6
> > gso_segment handlers, after they modify the network_header.
> >
> > Signed-off-by: Toke Høiland-Jørgensen <toke@toke.dk>
>
> Looks good but I would have appreciated a thanks or something
> after the help I gave on this problem.
>
> Reviewed-by: Eric Dumazet <edumazet@google.com>
Thanks, eric! (post-hoc)
Acked-by: Dave Taht <dave.taht@gmail.com>
> _______________________________________________
> Cake mailing list
> Cake@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/cake
--
Dave Täht
CEO, TekLibre, LLC
http://www.teklibre.com
Tel: 1-669-226-2619
^ permalink raw reply
* Re: [PATCH net] gso_segment: Reset skb->mac_len after modifying network header
From: Toke Høiland-Jørgensen @ 2018-09-13 14:22 UTC (permalink / raw)
To: Eric Dumazet, netdev; +Cc: cake, Eric Dumazet
In-Reply-To: <5dc16f03-7cd2-f797-1bda-592d5f5462b5@gmail.com>
On 13 September 2018 16:11:18 CEST, Eric Dumazet <eric.dumazet@gmail.com> wrote:
>
>
>On 09/11/2018 03:19 PM, Toke Høiland-Jørgensen wrote:
>> When splitting a GSO segment that consists of encapsulated packets,
>the
>> skb->mac_len of the segments can end up being set wrong, causing
>packet
>> drops in particular when using act_mirred and ifb interfaces in
>> combination with a qdisc that splits GSO packets.
>>
>> This happens because at the time skb_segment() is called,
>network_header
>> will point to the inner header, throwing off the calculation in
>> skb_reset_mac_len(). The network_header is subsequently adjust by the
>> outer IP gso_segment handlers, but they don't set the mac_len.
>>
>> Fix this by adding skb_reset_mac_len() calls to both the IPv4 and
>IPv6
>> gso_segment handlers, after they modify the network_header.
>>
>> Signed-off-by: Toke Høiland-Jørgensen <toke@toke.dk>
>
>Looks good but I would have appreciated a thanks or something
>after the help I gave on this problem.
Yes, of course. Should have mentioned that in the commit message.
My apologies, won't happen again. And thanks! :)
-Toke
^ 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