Skip to content

K
Kernel

openeuler / Kernel
1 年多 前同步成功

通知 8
Star 0
Fork 0
K
Kernel
切换分支/标签
  1. 21 7月, 2020 1 次提交
  3. 20 7月, 2020 14 次提交
    • T
      bonding: check error value of register_netdevice() immediately · 544f287b
      由 Taehee Yoo 提交于 
      If register_netdevice() is failed, net_device should not be used
because variables are uninitialized or freed.
So, the routine should be stopped immediately.
But, bond_create() doesn't check return value of register_netdevice()
immediately. That will result in a panic because of using uninitialized
or freed memory.

Test commands:
    modprobe netdev-notifier-error-inject
    echo -22 > /sys/kernel/debug/notifier-error-inject/netdev/\
actions/NETDEV_REGISTER/error
    modprobe bonding max_bonds=3

Splat looks like:
[  375.028492][  T193] general protection fault, probably for non-canonical address 0x6b6b6b6b6b6b6b6b: 0000 [#1] SMP DEBUG_PAGEALLOC PTI
[  375.033207][  T193] CPU: 2 PID: 193 Comm: kworker/2:2 Not tainted 5.8.0-rc4+ #645
[  375.036068][  T193] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.10.2-1ubuntu1 04/01/2014
[  375.039673][  T193] Workqueue: events linkwatch_event
[  375.041557][  T193] RIP: 0010:dev_activate+0x4a/0x340
[  375.043381][  T193] Code: 40 a8 04 0f 85 db 00 00 00 8b 83 08 04 00 00 85 c0 0f 84 0d 01 00 00 31 d2 89 d0 48 8d 04 40 48 c1 e0 07 48 03 83 00 04 00 00 <48> 8b 48 10 f6 41 10 01 75 08 f0 80 a1 a0 01 00 00 fd 48 89 48 08
[  375.050267][  T193] RSP: 0018:ffff9f8facfcfdd8 EFLAGS: 00010202
[  375.052410][  T193] RAX: 6b6b6b6b6b6b6b6b RBX: ffff9f8fae6ea000 RCX: 0000000000000006
[  375.055178][  T193] RDX: 0000000000000000 RSI: 0000000000000000 RDI: ffff9f8fae6ea000
[  375.057762][  T193] RBP: ffff9f8fae6ea000 R08: 0000000000000000 R09: 0000000000000000
[  375.059810][  T193] R10: 0000000000000001 R11: 0000000000000000 R12: ffff9f8facfcfe08
[  375.061892][  T193] R13: ffffffff883587e0 R14: 0000000000000000 R15: ffff9f8fae6ea580
[  375.063931][  T193] FS:  0000000000000000(0000) GS:ffff9f8fbae00000(0000) knlGS:0000000000000000
[  375.066239][  T193] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[  375.067841][  T193] CR2: 00007f2f542167a0 CR3: 000000012cee6002 CR4: 00000000003606e0
[  375.069657][  T193] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
[  375.071471][  T193] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
[  375.073269][  T193] Call Trace:
[  375.074005][  T193]  linkwatch_do_dev+0x4d/0x50
[  375.075052][  T193]  __linkwatch_run_queue+0x10b/0x200
[  375.076244][  T193]  linkwatch_event+0x21/0x30
[  375.077274][  T193]  process_one_work+0x252/0x600
[  375.078379][  T193]  ? process_one_work+0x600/0x600
[  375.079518][  T193]  worker_thread+0x3c/0x380
[  375.080534][  T193]  ? process_one_work+0x600/0x600
[  375.081668][  T193]  kthread+0x139/0x150
[  375.082567][  T193]  ? kthread_park+0x90/0x90
[  375.083567][  T193]  ret_from_fork+0x22/0x30

Fixes: e826eafa ("bonding: Call netif_carrier_off after register_netdevice")
Signed-off-by: NTaehee Yoo <ap420073@gmail.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      544f287b
    • R
      arm64: dts: clearfog-gt-8k: fix switch link configuration · 7c6719a1
      由 Russell King 提交于 
      The commit below caused a regression for clearfog-gt-8k, where the link
between the switch and the host does not come up.

Investigation revealed two issues:
- MV88E6xxx DSA no longer allows an in-band link to come up as the link
  is programmed to be forced down. Commit "net: dsa: mv88e6xxx: fix
  in-band AN link establishment" addresses this.

- The dts configured dissimilar link modes at each end of the host to
  switch link; the host was configured using a fixed link (so has no
  in-band status) and the switch was configured to expect in-band
  status.

With both issues fixed, the regression is resolved.

Fixes: 34b5e6a3 ("net: dsa: mv88e6xxx: Configure MAC when using fixed link")
Reported-by: NMartin Rowe <martin.p.rowe@gmail.com>
Signed-off-by: NRussell King <rmk+kernel@armlinux.org.uk>
Reviewed-by: NAndrew Lunn <andrew@lunn.ch>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      7c6719a1
    • R
      net: dsa: mv88e6xxx: fix in-band AN link establishment · fad58190
      由 Russell King 提交于 
      If in-band negotiation or fixed-link modes are specified for a DSA
port, the DSA code will force the link down during initialisation. For
fixed-link mode, this is fine, as phylink will manage the link state.
However, for in-band mode, phylink expects the PCS to detect link,
which will not happen if the link is forced down.

There is a related issue that in in-band mode, the link could come up
while we are making configuration changes, so we should force the link
down prior to reconfiguring the interface mode.

This patch addresses both issues.

Fixes: 3be98b2d ("net: dsa: Down cpu/dsa ports phylink will control")
Signed-off-by: NRussell King <rmk+kernel@armlinux.org.uk>
Reviewed-by: NAndrew Lunn <andrew@lunn.ch>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      fad58190
    • D
      Merge branch 'net-smc-fixes' · a463fa2c
      由 David S. Miller 提交于 
      Karsten Graul says:

====================
net/smc: fixes 2020-07-16

Please apply the following patch series for smc to netdev's net tree.

The patches address problems caused by late or unexpected link layer
control packets, dma sync calls for unmapped memory, freed buffers
that are not removed from the buffer list and a possible null pointer
access that results in a crash.

v1->v2: in patch 4, improve patch description and correct the comment
        for the new mutex
====================
Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      a463fa2c
    • K
      net/smc: fix restoring of fallback changes · 1ad24058
      由 Karsten Graul 提交于 
      When a listen socket is closed then all non-accepted sockets in its
accept queue are to be released. Inside __smc_release() the helper
smc_restore_fallback_changes() restores the changes done to the socket
without to check if the clcsocket has a file set. This can result in
a crash. Fix this by checking the file pointer first.
Reviewed-by: NUrsula Braun <ubraun@linux.ibm.com>
Fixes: f536dffc ("net/smc: fix closing of fallback SMC sockets")
Signed-off-by: NKarsten Graul <kgraul@linux.ibm.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      1ad24058
    • K
      net/smc: remove freed buffer from list · fd7f3a74
      由 Karsten Graul 提交于 
      Two buffers are allocated for each SMC connection. Each buffer is
added to a buffer list after creation. When the second buffer
allocation fails, the first buffer is freed but not deleted from
the list. This might result in crashes when another connection picks
up the freed buffer later and starts to work with it.
Reviewed-by: NUrsula Braun <ubraun@linux.ibm.com>
Fixes: 6511aad3 ("net/smc: change smc_buf_free function parameters")
Signed-off-by: NKarsten Graul <kgraul@linux.ibm.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      fd7f3a74
    • K
      net/smc: do not call dma sync for unmapped memory · 741a49a4
      由 Karsten Graul 提交于 
      The dma related ...sync_sg... functions check the link state before the
dma function is actually called. But the check in smc_link_usable()
allows links in ACTIVATING state which are not yet mapped to dma memory.
Under high load it may happen that the sync_sg functions are called for
such a link which results in an debug output like
   DMA-API: mlx5_core 0002:00:00.0: device driver tries to sync
   DMA memory it has not allocated [device address=0x0000000103370000]
   [size=65536 bytes]
To fix that introduce a helper to check for the link state ACTIVE and
use it where appropriate. And move the link state update to ACTIVATING
to the end of smcr_link_init() when most initial setup is done.
Reviewed-by: NUrsula Braun <ubraun@linux.ibm.com>
Fixes: d854fcbf ("net/smc: add new link state and related helpers")
Signed-off-by: NKarsten Graul <kgraul@linux.ibm.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      741a49a4
    • K
      net/smc: fix handling of delete link requests · b9979c2e
      由 Karsten Graul 提交于 
      As smc client the delete link requests are assigned to the flow when
_any_ flow is active. This may break other flows that do not expect
delete link requests during their handling. Fix that by assigning the
request only when an add link flow is active. With that fix the code
for smc client and smc server is the same, so remove the separate
handling.
Reviewed-by: NUrsula Braun <ubraun@linux.ibm.com>
Fixes: 9ec6bf19 ("net/smc: llc_del_link_work and use the LLC flow for delete link")
Signed-off-by: NKarsten Graul <kgraul@linux.ibm.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      b9979c2e
    • K
      net/smc: move add link processing for new device into llc layer · c48254fa
      由 Karsten Graul 提交于 
      When a new ib device is up smc will send an add link invitation to the
peer if needed. This is currently done with rudimentary flow control.
Under high workload these add link invitations can disturb other llc
flows because they arrive unexpected. Fix this by integrating the
invitations into the normal llc event flow and handle them as a flow.
While at it, check for already assigned requests in the flow before
the new add link request is assigned.
Reviewed-by: NUrsula Braun <ubraun@linux.ibm.com>
Fixes: 1f90a05d ("net/smc: add smcr_port_add() and smcr_link_up() processing")
Signed-off-by: NKarsten Graul <kgraul@linux.ibm.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      c48254fa
    • K
      net/smc: drop out-of-flow llc response messages · 2ff08678
      由 Karsten Graul 提交于 
      To be save from unexpected or late llc response messages check if the
arrived message fits to the current flow type and drop out-of-flow
messages. And drop it when there is already a response assigned to
the flow.
Reviewed-by: NUrsula Braun <ubraun@linux.ibm.com>
Fixes: ef79d439 ("net/smc: process llc responses in tasklet context")
Signed-off-by: NKarsten Graul <kgraul@linux.ibm.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      2ff08678
    • K
      net/smc: protect smc ib device initialization · 63673597
      由 Karsten Graul 提交于 
      Before an smc ib device is used the first time for an smc link it is
lazily initialized. When there are 2 active link groups and a new ib
device is brought online then it might happen that 2 link creations run
in parallel and enter smc_ib_setup_per_ibdev(). Both allocate new send
and receive completion queues on the device, but only one set of them
keeps assigned and the other leaks.
Fix that by protecting the setup and cleanup code using a mutex.
Reviewed-by: NUrsula Braun <ubraun@linux.ibm.com>
Fixes: f3c1dedd ("net/smc: separate function for link initialization")
Signed-off-by: NKarsten Graul <kgraul@linux.ibm.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      63673597
    • K
      net/smc: fix link lookup for new rdma connections · 7df8bcb5
      由 Karsten Graul 提交于 
      For new rdma connections the SMC server assigns the link and sends the
link data in the clc accept message. To match the correct link use not
only the qp_num but also the gid and the mac of the links. If there are
equal qp_nums for different links the wrong link would be chosen.
Reviewed-by: NUrsula Braun <ubraun@linux.ibm.com>
Fixes: 0fb0b02b ("net/smc: adapt SMC client code to use the LLC flow")
Signed-off-by: NKarsten Graul <kgraul@linux.ibm.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      7df8bcb5
    • K
      net/smc: clear link during SMC client link down processing · 68fd8942
      由 Karsten Graul 提交于 
      In a link-down condition we notify the SMC server and expect that the
server will finally trigger the link clear processing on the client
side. This could fail when anything along this notification path goes
wrong. Clear the link as part of SMC client link-down processing to
prevent dangling links.
Reviewed-by: NUrsula Braun <ubraun@linux.ibm.com>
Fixes: 541afa10 ("net/smc: add smcr_port_err() and smcr_link_down() processing")
Signed-off-by: NKarsten Graul <kgraul@linux.ibm.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      68fd8942
    • K
      net/smc: handle unexpected response types for confirm link · a35fffbf
      由 Karsten Graul 提交于 
      A delete link could arrive during confirm link processing. Handle this
situation directly in smc_llc_srv_conf_link() rather than using the
logic in smc_llc_wait() to avoid the unexpected message handling there.
Reviewed-by: NUrsula Braun <ubraun@linux.ibm.com>
Fixes: 1551c95b ("net/smc: final part of add link processing as SMC server")
Signed-off-by: NKarsten Graul <kgraul@linux.ibm.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      a35fffbf
  5. 18 7月, 2020 15 次提交
  7. 17 7月, 2020 2 次提交
  9. 16 7月, 2020 3 次提交
    • G
      ax88172a: fix ax88172a_unbind() failures · c28d9a28
      由 George Kennedy 提交于 
      If ax88172a_unbind() fails, make sure that the return code is
less than zero so that cleanup is done properly and avoid UAF.

Fixes: a9a51bd7 ("ax88172a: fix information leak on short answers")
Signed-off-by: NGeorge Kennedy <george.kennedy@oracle.com>
Reported-by: syzbot+4cd84f527bf4a10fc9c1@syzkaller.appspotmail.com
Signed-off-by: NJakub Kicinski <kuba@kernel.org>
      c28d9a28
    • S
      vsock/virtio: annotate 'the_virtio_vsock' RCU pointer · f961134a
      由 Stefano Garzarella 提交于 
      Commit 0deab087 ("vsock/virtio: use RCU to avoid use-after-free
on the_virtio_vsock") starts to use RCU to protect 'the_virtio_vsock'
pointer, but we forgot to annotate it.

This patch adds the annotation to fix the following sparse errors:

    net/vmw_vsock/virtio_transport.c:73:17: error: incompatible types in comparison expression (different address spaces):
    net/vmw_vsock/virtio_transport.c:73:17:    struct virtio_vsock [noderef] __rcu *
    net/vmw_vsock/virtio_transport.c:73:17:    struct virtio_vsock *
    net/vmw_vsock/virtio_transport.c:171:17: error: incompatible types in comparison expression (different address spaces):
    net/vmw_vsock/virtio_transport.c:171:17:    struct virtio_vsock [noderef] __rcu *
    net/vmw_vsock/virtio_transport.c:171:17:    struct virtio_vsock *
    net/vmw_vsock/virtio_transport.c:207:17: error: incompatible types in comparison expression (different address spaces):
    net/vmw_vsock/virtio_transport.c:207:17:    struct virtio_vsock [noderef] __rcu *
    net/vmw_vsock/virtio_transport.c:207:17:    struct virtio_vsock *
    net/vmw_vsock/virtio_transport.c:561:13: error: incompatible types in comparison expression (different address spaces):
    net/vmw_vsock/virtio_transport.c:561:13:    struct virtio_vsock [noderef] __rcu *
    net/vmw_vsock/virtio_transport.c:561:13:    struct virtio_vsock *
    net/vmw_vsock/virtio_transport.c:612:9: error: incompatible types in comparison expression (different address spaces):
    net/vmw_vsock/virtio_transport.c:612:9:    struct virtio_vsock [noderef] __rcu *
    net/vmw_vsock/virtio_transport.c:612:9:    struct virtio_vsock *
    net/vmw_vsock/virtio_transport.c:631:9: error: incompatible types in comparison expression (different address spaces):
    net/vmw_vsock/virtio_transport.c:631:9:    struct virtio_vsock [noderef] __rcu *
    net/vmw_vsock/virtio_transport.c:631:9:    struct virtio_vsock *

Fixes: 0deab087 ("vsock/virtio: use RCU to avoid use-after-free on the_virtio_vsock")
Reported-by: NMichael S. Tsirkin <mst@redhat.com>
Signed-off-by: NStefano Garzarella <sgarzare@redhat.com>
Reviewed-by: NStefan Hajnoczi <stefanha@redhat.com>
Acked-by: NMichael S. Tsirkin <mst@redhat.com>
Signed-off-by: NJakub Kicinski <kuba@kernel.org>
      f961134a
    • I
      dpaa2-eth: check fsl_mc_get_endpoint for IS_ERR_OR_NULL() · 841eb401
      由 Ioana Ciornei 提交于 
      The fsl_mc_get_endpoint() function can return an error or directly a
NULL pointer in case the peer device is not under the root DPRC
container. Treat this case also, otherwise it would lead to a NULL
pointer when trying to access the peer fsl_mc_device.

Fixes: 71947923 ("dpaa2-eth: add MAC/PHY support through phylink")
Signed-off-by: NIoana Ciornei <ioana.ciornei@nxp.com>
Signed-off-by: NJakub Kicinski <kuba@kernel.org>
      841eb401
  11. 15 7月, 2020 4 次提交
  13. 14 7月, 2020 1 次提交