[PATCH] 4.9.13 brcmfmac: fix use-after-free on resume

KASAN reported 'struct wireless_dev wdev' was read after being freed. Fix by freeing after the access. Signed-off-by: Daniel J Blueman diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/p2p.c b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/p2p.c index

[4.9.13] brcmf use-after-free on resume

When resuming from suspend with a BCM43602 on Ubuntu 16.04 with 4.9.13, we see use after free [1]. We see the struct cfg80211_ops is accessed in the resume path, after it was previously freed: (gdb) list *(brcmf_cfg80211_attach+0x10b) 0x1d77b is in brcmf_cfg80211_attach

[PATCH 2/3] xfrm: Don't use sk_family for socket policy lookups

On IPv4-mapped IPv6 addresses sk_family is AF_INET6, but the flow informations are created based on AF_INET. So the routing set up 'struct flowi4' but we try to access 'struct flowi6' what leads to an out of bounds access. Fix this by using the family we get with the dst_entry, like we do it for

pull request (net): ipsec 2017-03-06

1) Fix lockdep splat on xfrm policy subsystem initialization. From Florian Westphal. 2) When using socket policies on IPv4-mapped IPv6 addresses, we access the flow informations of the wrong address family what leads to an out of bounds access. Fix this by using the family we get with

[PATCH 1/3] xfrm: policy: init locks early

From: Florian Westphal Dmitry reports following splat: INFO: trying to register non-static key. the code is fine but needs lockdep annotation. turning off the locking correctness validator. CPU: 0 PID: 13059 Comm: syz-executor1 Not tainted 4.10.0-rc7-next-20170207 #1 [..]

[PATCH 3/3] vti6: Don't report path MTU below IPV6_MIN_MTU.

In vti6_xmit(), the check for IPV6_MIN_MTU before we send a ICMPV6_PKT_TOOBIG message is missing. So we might report a PMTU below 1280. Fix this by adding the required check. Fixes: ccd740cbc6e ("vti6: Add pmtu handling to vti6_xmit.") Signed-off-by: Steffen Klassert

Re: [PATCH net] dccp: fix use-after-free in dccp_feat_activate_values

On Sun, 2017-03-05 at 21:38 -0800, Cong Wang wrote: > Do you really want to disable BH again here? > > dccp_check_req() should be always called on RX path where BH > is already disabled and BH can't be disabled twice? What makes you think BH can't be disabled twice ? Look, I prefer being

Re: [4.9.13] use after free in ipv4_mtu

On 2 March 2017 at 21:28, Eric Dumazet wrote: > On Thu, 2017-03-02 at 05:08 -0800, Eric Dumazet wrote: > >> Thanks for the report ! >> >> This patch should solve this precise issue, but we need more work. >> >> We need to audit all __sk_dst_get() and make sure they are

Re: [PATCH] udp: avoid ufo handling on IP payload compression packets

On Fri, Mar 03, 2017 at 03:37:32PM +0300, Alexey Kodanev wrote: > commit c146066ab802 ("ipv4: Don't use ufo handling on later transformed > packets") and commit f89c56ce710a ("ipv6: Don't use ufo handling on > later transformed packets") added a check that 'rt->dst.header_len' isn't > zero in

Re: [PATCH net] dccp: fix use-after-free in dccp_feat_activate_values

On Sun, Mar 5, 2017 at 10:52 AM, Eric Dumazet wrote: > --- a/net/dccp/minisocks.c > +++ b/net/dccp/minisocks.c > @@ -142,6 +142,13 @@ struct sock *dccp_check_req(struct sock *sk, struct > sk_buff *skb, > struct dccp_request_sock *dreq = dccp_rsk(req); >

[PATCH v2] can: m_can: enable transmission of FD frame on latest version

Enables the transmission of CAN FD frames on M_CAN IP core >= v3.1.x and with the bit rate switching. Tested on M_CAN IP 3.1.0 (CREL = 0x31040730) of SAMA5D2 SoC. Signed-off-by: Wenyou Yang --- The testing is based on [RESEND PATCH 1/1] can: m_can: fix bitrate setup on

RE: [PATCH] can: m_can: support transmit frame in CAN FD format

Hi Oliver, Thank you for your review. > -Original Message- > From: Oliver Hartkopp [mailto:socket...@hartkopp.net] > Sent: 2017年3月6日 3:34 > To: Wenyou Yang - A41535 ; Wolfgang > Grandegger ; Marc Kleine-Budde > Cc:

Re: net/ipv4: deadlock in ip_ra_control

On Fri, Mar 3, 2017 at 10:43 AM, Dmitry Vyukov wrote: > On Thu, Mar 2, 2017 at 10:40 AM, Dmitry Vyukov wrote: >> On Wed, Mar 1, 2017 at 6:18 PM, Cong Wang wrote: >>> On Wed, Mar 1, 2017 at 2:44 AM, Dmitry Vyukov

Re: [PATCH net v2] net: phy: Do not perform software reset for Generic PHY

From: Florian Fainelli Date: Sun, 5 Mar 2017 12:34:49 -0800 > The Generic PHY driver is a catch-all PHY driver and it should preserve > whatever prior initialization has been done by boot loader or firmware > agents. For specific PHY device configuration it is expected

Re: [PATCH net] bpf: add get_next_key callback to LPM map

From: Alexei Starovoitov Date: Sun, 5 Mar 2017 10:58:00 -0800 > On 3/5/17 10:44 AM, David Miller wrote: >> From: Alexei Starovoitov >> Date: Sun, 5 Mar 2017 09:41:08 -0800 >> >>> map_get_next_key callback is mandatory. Supply dummy handler. >>> >>> Fixes: b95a5c4db09b

[PATCH] net: toshiba: spider_net: use new api ethtool_{get|set}_link_ksettings

The ethtool api {get|set}_settings is deprecated. We move this driver to new api {get|set}_link_ksettings. As I don't have the hardware, I'd be very pleased if someone may test this patch. Signed-off-by: Philippe Reynes --- drivers/net/ethernet/toshiba/spider_net_ethtool.c |

Re: [PATCH 1/2] net: phy: Add dependencies for Cavium SoCs

Hi Peter, [auto build test ERROR on net-next/master] [also build test ERROR on v4.11-rc1 next-20170303] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url:

[PATCH] net: toshiba: ps3_genic_net: use new api ethtool_{get|set}_link_ksettings

The ethtool api {get|set}_settings is deprecated. We move this driver to new api {get|set}_link_ksettings. As I don't have the hardware, I'd be very pleased if someone may test this patch. Signed-off-by: Philippe Reynes --- drivers/net/ethernet/toshiba/ps3_gelic_net.c | 51

Re: [PATCH 1/2] net: phy: Add dependencies for Cavium SoCs

Hi Peter, [auto build test WARNING on net-next/master] [also build test WARNING on v4.11-rc1 next-20170303] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url:

[PATCH] net: sun: sunhme: use new api ethtool_{get|set}_link_ksettings

The ethtool api {get|set}_settings is deprecated. We move this driver to new api {get|set}_link_ksettings. As I don't have the hardware, I'd be very pleased if someone may test this patch. Signed-off-by: Philippe Reynes --- drivers/net/ethernet/sun/sunhme.c | 62

[Patch net] ipv6: reorder icmpv6_init() and ip6_mr_init()

Andrey reported the following kernel crash: kasan: GPF could be caused by NULL-ptr deref or user memory access general protection fault: [#1] SMP KASAN Dumping ftrace buffer: (ftrace buffer empty) Modules linked in: CPU: 0 PID: 14446 Comm: syz-executor6 Not tainted 4.10.0+ #82 Hardware

[PATCH net v2] net: phy: Do not perform software reset for Generic PHY

The Generic PHY driver is a catch-all PHY driver and it should preserve whatever prior initialization has been done by boot loader or firmware agents. For specific PHY device configuration it is expected that a specialized PHY driver would take over that role. Resetting the generic PHY was a bad

Re: [PATCH net] net: phy: Do not perform software reset for Generic PHY

Le 03/05/17 à 12:26, Florian Fainelli a écrit : > The Generic PHY driver is a catch-all PHY driver and it should preserve > whatever prior initialization has been done by boot loader or firmware > agents. For specific PHY device configuration it is expected that a > specialized PHY driver would

[PATCH 1/2 net] ibmvnic: Fix overflowing firmware/hardware TX queue

Use a counter to track the number of outstanding transmissions sent that have not received completions. If the counter reaches the maximum number of queue entries, stop transmissions on that queue. As we receive more completions from firmware, wake the queue once the counter reaches an

[PATCH net] net: phy: Do not perform software reset for Generic PHY

The Generic PHY driver is a catch-all PHY driver and it should preserve whatever prior initialization has been done by boot loader or firmware agents. For specific PHY device configuration it is expected that a specialized PHY driver would take over that role. Resetting the generic PHY was a bad

Re: net/ipv6: null-ptr-deref in ip6mr_sk_done

On Sun, Mar 5, 2017 at 8:54 AM, Andrey Konovalov wrote: > Hi, > > I've got the following bug report while fuzzing the kernel with syzkaller. > Unfortunately it's not reproducible. > > On commit e5d56efc97f8240d0b5d66c03949382b6d7e5570 (Feb 26). > > kasan: GPF could be

Re: [PATCH net] bpf: add get_next_key callback to LPM map

On 3/5/17 10:44 AM, David Miller wrote: From: Alexei Starovoitov Date: Sun, 5 Mar 2017 09:41:08 -0800 map_get_next_key callback is mandatory. Supply dummy handler. Fixes: b95a5c4db09b ("bpf: add a longest prefix match trie map implementation") Reported-by: Dmitry Vyukov

Re: [PATCH] can: m_can: support transmit frame in CAN FD format

The patch has some issues: On 03/03/2017 06:33 AM, Wenyou Yang wrote: Add support to transmit the frame in the CAN FD format and with the bit rate switching. This is a misleading comment. "can: m_can: support transmit frame in CAN FD format" is misleading too. You were able to send CAN FD

[PATCH 2/2 net] ibmvnic: Allocate number of rx/tx buffers agreed on by firmware

The amount of TX/RX buffers that the vNIC driver currently allocates is different from the amount agreed upon in negotiation with firmware. Correct that by allocating the requested number of buffers confirmed by firmware. Signed-off-by: Thomas Falcon ---

Re: [PATCH net] bpf: add get_next_key callback to LPM map

From: Alexei Starovoitov Date: Sun, 5 Mar 2017 09:41:08 -0800 > map_get_next_key callback is mandatory. Supply dummy handler. > > Fixes: b95a5c4db09b ("bpf: add a longest prefix match trie map > implementation") > Reported-by: Dmitry Vyukov > Signed-off-by:

[PATCH net] dccp: fix use-after-free in dccp_feat_activate_values

From: Eric Dumazet Dmitry reported crashes in DCCP stack [1] Problem here is that when I got rid of listener spinlock, I missed the fact that DCCP stores a complex state in struct dccp_request_sock, while TCP does not. Since multiple cpus could access it at the same time,

[PATCH 1/2 net] ibmvnic: Fix overflowing firmware/hardware TX queue

Use a counter to track the number of outstanding transmissions sent that have not received completions. If the counter reaches the maximum number of queue entries, stop transmissions on that queue. As we receive more completions from firmware, wake the queue once the counter reaches an

[PATCH 2/2 net] ibmvnic: Allocate number of rx/tx buffers agreed on by firmware

The amount of TX/RX buffers that the vNIC driver currently allocates is different from the amount agreed upon in negotiation with firmware. Correct that by allocating the requested number of buffers confirmed by firmware. Signed-off-by: Thomas Falcon ---

Re: crypto: deadlock between crypto_alg_sem/rtnl_mutex/genl_mutex

On Sun, Mar 5, 2017 at 4:08 PM, Dmitry Vyukov wrote: > Hello, > > I am getting the following deadlock reports while running syzkaller > fuzzer on net-next/8d70eeb84ab277377c017af6a21d0a337025dede: > > == > [ INFO: possible

[PATCH net] bpf: add get_next_key callback to LPM map

map_get_next_key callback is mandatory. Supply dummy handler. Fixes: b95a5c4db09b ("bpf: add a longest prefix match trie map implementation") Reported-by: Dmitry Vyukov Signed-off-by: Alexei Starovoitov --- kernel/bpf/lpm_trie.c | 6 ++ 1 file changed,

Re: [PATCH net] tcp: fix various issues for sockets morphing to listen state

On Sun, Mar 5, 2017 at 4:00 AM, Dmitry Vyukov wrote: > On Fri, Mar 3, 2017 at 11:08 PM, Eric Dumazet wrote: >> From: Eric Dumazet >> >> Dmitry Vyukov reported a divide by 0 triggered by syzkaller, exploiting >> tcp_disconnect()

net/ipv6: null-ptr-deref in ip6mr_sk_done

Hi, I've got the following bug report while fuzzing the kernel with syzkaller. Unfortunately it's not reproducible. On commit e5d56efc97f8240d0b5d66c03949382b6d7e5570 (Feb 26). kasan: GPF could be caused by NULL-ptr deref or user memory access general protection fault: [#1] SMP KASAN

Re: [PATCH 1/2] net: phy: Add dependencies for Cavium SoCs

On Sun, Mar 05, 2017 at 12:14:33PM +, Peter Robinson wrote: > Add dependencies on the Cavium architectures for the PHYs Hi Peter These are not PHY drivers, but MDIO bus drivers. > as well as COMPILE_TEST to ensure build coverage. > > Signed-off-by: Peter Robinson >

bpf: kernel NULL pointer dereference in map_get_next_key

Hello, The following program causes kernel NULL pointer dereference in map_get_next_key: BUG: unable to handle kernel NULL pointer dereference at (null) IP: (null) PGD 64a8f067 PUD 65c78067 PMD 0 Oops: 0010 [#1] SMP KASAN Modules linked in: CPU: 3 PID: 2953 Comm: a.out Not

crypto: deadlock between crypto_alg_sem/rtnl_mutex/genl_mutex

Hello, I am getting the following deadlock reports while running syzkaller fuzzer on net-next/8d70eeb84ab277377c017af6a21d0a337025dede: == [ INFO: possible circular locking dependency detected ] 4.10.0+ #5 Not tainted

Re: Tighten some of the net/phy SoC dependencies

On Sun, Mar 05, 2017 at 12:14:32PM +, Peter Robinson wrote: > A pair of small Kconfig patches to tightend some of the PHY MDIO > dependencies one the SoCs, fairly self explanatory. Hi Peter Please use git format-patch --cover to generate the cover note for a patch set. [PATCH 1/2] net:

Re: [PATCH v2] net: smsc: smc91x: use new api ethtool_{get|set}_link_ksettings

Philippe Reynes writes: > The ethtool api {get|set}_settings is deprecated. > We move this driver to new api {get|set}_link_ksettings. > > As I don't have the hardware, I'd be very pleased if > someone may test this patch. > > Signed-off-by: Philippe Reynes

Re: net/dccp: use-after-free in dccp_feat_activate_values

On Fri, Mar 3, 2017 at 5:00 PM, Eric Dumazet wrote: > On Fri, 2017-03-03 at 07:22 -0800, Eric Dumazet wrote: >> On Fri, Mar 3, 2017 at 7:12 AM, Dmitry Vyukov wrote: >> > The first bot that picked this up started spewing: >> > >> > BUG: spinlock

[PATCH net 3/3] rds: tcp: Sequence teardown of listen and acceptor sockets to avoid races

Commit a93d01f5777e ("RDS: TCP: avoid bad page reference in rds_tcp_listen_data_ready") added the function rds_tcp_listen_sock_def_readable() to handle the case when a partially set-up acceptor socket drops into rds_tcp_listen_data_ready(). However, if the listen socket (rtn->rds_tcp_listen_sock)

[PATCH net 2/3] rds: tcp: Reorder initialization sequence in rds_tcp_init to avoid races

Order of initialization in rds_tcp_init needs to be done so that resources are set up and destroyed in the correct synchronization sequence with both the data path, as well as netns create/destroy path. Specifically, - we must call register_pernet_subsys and get the rds_tcp_netid before calling

[PATCH net 1/3] rds: tcp: Take explicit refcounts on struct net

It is incorrect for the rds_connection to piggyback on the sock_net() refcount for the netns because this gives rise to a chicken-and-egg problem during rds_conn_destroy. Instead explicitly take a ref on the net, and hold the netns down till the connection tear-down is complete. Reported-by:

[PATCH net 0/3] rds: tcp: fix various rds-tcp issues during netns create/delete sequences

Dmitry Vyukov reported some syszkaller panics during netns deletion. While I have not been able to reproduce those exact panics, my attempts to do so uncovered a few other problems, which are fixed patch 2 and patch 3 of this patch series. In addition, as mentioned in,

[PATCH 1/2] net: phy: Add dependencies for Cavium SoCs

Add dependencies on the Cavium architectures for the PHYs as well as COMPILE_TEST to ensure build coverage. Signed-off-by: Peter Robinson --- drivers/net/phy/Kconfig | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/net/phy/Kconfig

[PATCH 2/2] net:phy:hisi: Depend on the appropraite SoC

The HiSi PHY only ships on the ARM SoC so depend on it. Signed-off-by: Peter Robinson --- drivers/net/phy/Kconfig | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/net/phy/Kconfig b/drivers/net/phy/Kconfig index 59b8313..be6f853 100644 ---

Tighten some of the net/phy SoC dependencies

A pair of small Kconfig patches to tightend some of the PHY MDIO dependencies one the SoCs, fairly self explanatory. Peter

Re: [PATCH net] tcp: fix various issues for sockets morphing to listen state

On Fri, Mar 3, 2017 at 11:08 PM, Eric Dumazet wrote: > From: Eric Dumazet > > Dmitry Vyukov reported a divide by 0 triggered by syzkaller, exploiting > tcp_disconnect() path that was never really considered and/or used > before syzkaller ;) > > I was

Re: net: heap out-of-bounds in fib6_clean_node/rt6_fill_node/fib6_age/fib6_prune_clone

On Sat, Mar 4, 2017 at 9:15 PM, Eric Dumazet wrote: >> > On 3/3/17 6:39 AM, Dmitry Vyukov wrote: >> >> I am getting heap out-of-bounds reports in >> >> fib6_clean_node/rt6_fill_node/fib6_age/fib6_prune_clone while running >> >> syzkaller fuzzer on

RE: [PATCH net 5/7] bnx2x: do not rollback VF MAC/VLAN filters we did not configure

> On failure to configure a VF MAC/VLAN filter we should not attempt to > rollback filters that we failed to configure with -EEXIST. Is this theoretical or did you actually manage to hit it? If so, did it involve non-linux VFs? Asking as linux VFs don't actually send multiple vlan/umac

RE: [PATCH net 3/7] bnx2x: fix possible overrun of VFPF multicast addresses array

> @@ -883,6 +883,15 @@ int bnx2x_vfpf_set_mcast(struct net_device *dev) > /* Get Rx mode requested */ > DP(NETIF_MSG_IFUP, "dev->flags = %x\n", dev->flags); > > + /* We support PFVF_MAX_MULTICAST_PER_VF mcast addresses tops > */ > + if (netdev_mc_count(dev) >

RE: [PATCH net 0/7] bnx2x: PTP crash, VF VLAN fixes

> Hello, > here are fixes for a crash with PTP, a crash in setting of VF multicast > addresses, and non-working VLAN filters configuration from the VF side. > > Michal Schmidt (7): > bnx2x: prevent crash when accessing PTP with interface down > bnx2x: lower verbosity of VF stats debug

RE: [PATCH net 1/7] bnx2x: prevent crash when accessing PTP with interface down

> It is possible to crash the kernel by accessing a PTP device while its > associated bnx2x interface is down. Before the interface is brought up, the > timecounter is not initialized, so accessing it results in NULL dereference. > > Fix it by checking if the interface is up. > > Use -ENETDOWN