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 de19c7c..aa0f470 100644
--- a/
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
(drivers/net/wireless/broa
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 th
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
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
[..]
spin_lock_bh includ
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
---
net/ipv6/ip6_vti.c | 8 +
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 cautio
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 inside an
>> rcu_read_lock()
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 order
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);
> bool own_req;
>
> + /
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 latest silicon
http://lkml
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: Alexandre Belloni ; Florian Fainelli
> ; Quentin Schulz ;
> Wenyou Yang -
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 wrote:
Hello,
I've got the following deadlock report while running s
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 that a
> specialized PHY d
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 ("bpf: add a longest prefix
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 | 24 --
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:
https://github.com/0day-ci/linux/commits/Peter-Robinson/net-phy-Add-dependencies-for
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 +++
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:
https://github.com/0day-ci/linux/commits/Peter-Robinson/net-phy-Add-dependencies
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 --
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 nam
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 i
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 tak
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 acceptable
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 i
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 caused by NULL-ptr deref or u
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
Signed-off-by: Alexei
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 fra
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
---
drivers/net/ethernet/ibm/ibmvnic.c | 16 +
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: Alexei Starovoitov
Wouldn't it be
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, we need to add
protect
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 acceptable
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
---
drivers/net/ethernet/ibm/ibmvnic.c | 16 +
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 circular locking depend
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, 6 insertions(+)
diff --git a/kernel/b
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() path that was never really considered and/or used
>> before syzkalle
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
Dumpin
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
> ---
> drivers/net/phy/
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 tai
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
---
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: phy:
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
> ---
> Changelog:
> v2:
> - also upda
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 recursion on CPU#1, syz-executor2/9452
>>
>> Yes. Th
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)
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
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: Dmitr
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,
https://www.spinics.net/li
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 b/drivers/net/phy/Kconfig
index 8d
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
--- a/drivers/net/phy/Kconfig
+++ b/drivers/net/ph
A pair of small Kconfig patches to tightend some of the PHY MDIO
dependencies one the SoCs, fairly self explanatory.
Peter
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 not able to reproduce the bug, but it seems is
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 86292b33d4b79ee03e2f43ea0381ef85f077c760. They all
> 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 configurat
> @@ -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) > PFVF_MAX_MULTICAST
> 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 messages
> 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 as
56 matches
Mail list logo