[PATCH] NFC: fix attrs checks in netlink interface

[Andrey Konovalov]

nfc_genl_deactivate_target() relies on the NFC_ATTR_TARGET_INDEX
attribute being present, but doesn't check whether it is actually
provided by the user. Same goes for nfc_genl_fw_download() and
NFC_ATTR_FIRMWARE_NAME.

This patch adds appropriate checks.

Found with syzkaller.

Signed-off-by: Andrey Konovalov <andreyk...@google.com>
---
 net/nfc/netlink.c | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/net/nfc/netlink.c b/net/nfc/netlink.c
index f018eafc2a0d..58adfb0c90f6 100644
--- a/net/nfc/netlink.c
+++ b/net/nfc/netlink.c
@@ -936,7 +936,8 @@ static int nfc_genl_deactivate_target(struct sk_buff *skb,
u32 device_idx, target_idx;
int rc;
 
-   if (!info->attrs[NFC_ATTR_DEVICE_INDEX])
+   if (!info->attrs[NFC_ATTR_DEVICE_INDEX] ||
+   !info->attrs[NFC_ATTR_TARGET_INDEX])
return -EINVAL;
 
device_idx = nla_get_u32(info->attrs[NFC_ATTR_DEVICE_INDEX]);
@@ -1245,7 +1246,8 @@ static int nfc_genl_fw_download(struct sk_buff *skb, 
struct genl_info *info)
u32 idx;
char firmware_name[NFC_FIRMWARE_NAME_MAXSIZE + 1];
 
-   if (!info->attrs[NFC_ATTR_DEVICE_INDEX])
+   if (!info->attrs[NFC_ATTR_DEVICE_INDEX] ||
+   !info->attrs[NFC_ATTR_FIRMWARE_NAME])
return -EINVAL;
 
idx = nla_get_u32(info->attrs[NFC_ATTR_DEVICE_INDEX]);
-- 
2.17.0.484.g0c8726318c-goog

Re: WARNING in refcount_inc (2)

[Andrey Konovalov]

On Wed, Jan 31, 2018 at 8:27 AM, Eric Biggers  wrote:
>
> Also Dmitry, syzbot seems to be grouping together unrelated bugs under the
> refcount_t WARNINGs; maybe those should be on a blacklist?

Not a blacklist, we need a proper way of extracting the offending
caller like it's done for reports from __this_cpu_* [1].

[1] https://github.com/google/syzkaller/blob/master/pkg/report/linux.go#L579

usb/net/zd1211rw: possible deadlock in zd_chip_disable_rxtx

[Andrey Konovalov]

Hi!

I've got the following report while fuzzing the kernel with syzkaller.

On commit e1d1ea549b57790a3d8cf6300e6ef86118d692a3 (4.15-rc1).

usb 1-1: New USB device found, idVendor=0baf, idProduct=0121
usb 1-1: New USB device strings: Mfr=0, Product=0, SerialNumber=0
usb 1-1: config 0 descriptor??
usb 1-1: reset full-speed USB device number 2 using dummy_hcd
ieee80211 phy2: Selected rate control algorithm 'minstrel_ht'
zd1211rw 1-1:0.0: phy2
zd1211rw 1-1:0.0: error ioread32(CR_REG1): -11
usb 1-1: reset full-speed USB device number 2 using dummy_hcd
ieee80211 phy3: Selected rate control algorithm 'minstrel_ht'
zd1211rw 1-1:0.8: phy3
zd1211rw 1-1:0.8 rename38: renamed from wlan3
zd1211rw 1-1:0.0: error ioread32(CR_REG1): -11

WARNING: possible recursive locking detected
4.14.0-57501-g9284d204d604 #119 Not tainted

kworker/1:1/43 is trying to acquire lock:
 (>mutex){+.+.}, at: [] zd_chip_disable_rxtx+0x25/0x50

but task is already holding lock:
 (>mutex){+.+.}, at: [] pre_reset+0x1e5/0x250

other info that might help us debug this:
 Possible unsafe locking scenario:

   CPU0
   
  lock(>mutex);
  lock(>mutex);

 *** DEADLOCK ***

 May be due to missing lock nesting notation

6 locks held by kworker/1:1/43:
 #0:  ((wq_completion)"usb_hub_wq"){+.+.}, at: []
process_one_work+0x71d/0x15f0
 #1:  ((work_completion)(>events)){+.+.}, at:
[] process_one_work+0x750/0x15f0
 #2:  (>mutex){}, at: [] hub_event_impl+0xa7/0x3440
 #3:  (>mutex){}, at: [] __device_attach+0x36/0x2a0
 #4:  (>mutex){}, at: [] __device_attach+0x36/0x2a0
 #5:  (>mutex){+.+.}, at: [] pre_reset+0x1e5/0x250

stack backtrace:
CPU: 1 PID: 43 Comm: kworker/1:1 Not tainted 4.14.0-57501-g9284d204d604 #119
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011
Workqueue: usb_hub_wq hub_event
Call Trace:
 __dump_stack lib/dump_stack.c:17
 dump_stack+0xe1/0x157 lib/dump_stack.c:53
 check_deadlock kernel/locking/lockdep.c:1809
 validate_chain kernel/locking/lockdep.c:2457
 __lock_acquire.cold.66+0x132/0x3bc kernel/locking/lockdep.c:3500
 lock_acquire+0x113/0x330 kernel/locking/lockdep.c:4004
 __mutex_lock_common kernel/locking/mutex.c:756
 __mutex_lock+0x78/0xf70 kernel/locking/mutex.c:893
 mutex_lock_nested+0x1b/0x20 kernel/locking/mutex.c:908
 zd_chip_disable_rxtx+0x25/0x50
drivers/net/wireless/zydas/zd1211rw/zd_chip.c:1478
 zd_op_stop+0x4e/0xe0 drivers/net/wireless/zydas/zd1211rw/zd_mac.c:356
 zd_usb_stop drivers/net/wireless/zydas/zd1211rw/zd_usb.c:1490
 pre_reset+0x195/0x250 drivers/net/wireless/zydas/zd1211rw/zd_usb.c:1513
 usb_reset_device+0x389/0x940 drivers/usb/core/hub.c:5776
 probe+0x117/0x910 drivers/net/wireless/zydas/zd1211rw/zd_usb.c:1382
 usb_probe_interface+0x324/0x940 drivers/usb/core/driver.c:361
 really_probe drivers/base/dd.c:424
 driver_probe_device+0x564/0x820 drivers/base/dd.c:566
 __device_attach_driver+0x25d/0x2d0 drivers/base/dd.c:662
 bus_for_each_drv+0xff/0x160 drivers/base/bus.c:463
 __device_attach+0x1ab/0x2a0 drivers/base/dd.c:719
 device_initial_probe+0x1f/0x30 drivers/base/dd.c:766
 bus_probe_device+0x1fc/0x2a0 drivers/base/bus.c:523
 device_add+0xc27/0x15a0 drivers/base/core.c:1835
 usb_set_configuration+0xd55/0x17a0 drivers/usb/core/message.c:1967
 generic_probe+0xbb/0x120 drivers/usb/core/generic.c:174
 usb_probe_device+0xab/0x100 drivers/usb/core/driver.c:266
 really_probe drivers/base/dd.c:424
 driver_probe_device+0x564/0x820 drivers/base/dd.c:566
 __device_attach_driver+0x25d/0x2d0 drivers/base/dd.c:662
 bus_for_each_drv+0xff/0x160 drivers/base/bus.c:463
 __device_attach+0x1ab/0x2a0 drivers/base/dd.c:719
 device_initial_probe+0x1f/0x30 drivers/base/dd.c:766
 bus_probe_device+0x1fc/0x2a0 drivers/base/bus.c:523
 device_add+0xc27/0x15a0 drivers/base/core.c:1835
 usb_new_device+0x7fa/0x1090 drivers/usb/core/hub.c:2538
 hub_port_connect drivers/usb/core/hub.c:5000
 hub_port_connect_change drivers/usb/core/hub.c:5106
 port_event drivers/usb/core/hub.c:5212
 hub_event_impl+0x17bc/0x3440 drivers/usb/core/hub.c:5324
 hub_event+0x38/0x50 drivers/usb/core/hub.c:5222
 process_one_work+0x944/0x15f0 kernel/workqueue.c:2112
 worker_thread+0xef/0x10d0 kernel/workqueue.c:2246
 kthread+0x367/0x420 kernel/kthread.c:238
 ret_from_fork+0x24/0x30 arch/x86/entry/entry_64.S:437

Re: [PATCH] net: usb: asix: fill null-ptr-deref in asix_suspend

[Andrey Konovalov]

On Mon, Nov 6, 2017 at 4:20 PM, Oliver Neukum <oneu...@suse.com> wrote:
> Am Montag, den 06.11.2017, 13:30 +0100 schrieb Andrey Konovalov:
>> On Mon, Nov 6, 2017 at 10:49 AM, Oliver Neukum <oneu...@suse.com> wrote:
>> >
>> >
>> > 2. Will a device work after that? The appropriate fix may be to wait
>> > until the device is properly initialized.
>>
>> This shouldn't affect real devices as far as I understand. The crash
>> can be caused by a crafted malicious device.
>
> Hi!
>
> Hm. That seems strange as driver_priv is kmalloced. Do you
> still have a descriptor that causes this?
> Shouldn't we rather reject such a broken device?

I do have a way to reproduce this.

As far as I understand, for this particular device ax88172_bind() is
called, which doesn't assign anything to dev->driver_priv, so that's
why it is NULL in suspend() and resume().

>
> Regards
> Oliver
>

Re: usb/net/qmi_wwan: divide error in qmi_wwan_probe/usbnet_probe

[Andrey Konovalov]

On Mon, Nov 6, 2017 at 3:06 PM, Bjørn Mork <bj...@mork.no> wrote:
> Andrey Konovalov <andreyk...@google.com> writes:
>
>> Hi!
>>
>> I've got the following report while fuzzing the kernel with syzkaller.
>
> Thanks.  It would have helped a lot of you said *what* you were fuzzing,
> though But based on where the bug is, I assume it is USB
> descriptors?

Yes, I was connecting USB devices with random descriptors. I though
it's obvious from the stack trace, but I'll include that in the
following reports. Thanks!

>
>
>> On commit 39dae59d66acd86d1de24294bd2f343fd5e7a625 (4.14-rc8).
>>
>> qmi_wwan 1-1:0.4: cdc-wdm0: USB WDM device
>> divide error:  [#1] PREEMPT SMP KASAN
>> Modules linked in:
>> CPU: 0 PID: 24 Comm: kworker/0:1 Not tainted 4.14.0-rc8-44453-g1fdc1a82c34f 
>> #56
>> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011
>> Workqueue: usb_hub_wq hub_event
>> task: 88006bef5c00 task.stack: 88006bf6
>> RIP: 0010:usbnet_update_max_qlen+0x24d/0x390 drivers/net/usb/usbnet.c:355
>> RSP: 0018:88006bf67508 EFLAGS: 00010246
>> RAX: 000163c8 RBX: 8800621fce40 RCX: 8800621fcf34
>> RDX:  RSI: 837ecb7a RDI: 8800621fcf34
>> RBP: 88006bf67520 R08: 88006bef5c00 R09: ed000c43f881
>> R10: ed000c43f880 R11: 8800621fc406 R12: 0003
>> R13: 85c71de0 R14:  R15: 
>> FS:  () GS:88006ca0() knlGS:
>> CS:  0010 DS:  ES:  CR0: 80050033
>> CR2: 7ffe9c0d6dac CR3: 614f4000 CR4: 06f0
>> Call Trace:
>>  usbnet_probe+0x18b5/0x2790 drivers/net/usb/usbnet.c:1783
>>  qmi_wwan_probe+0x133/0x220 drivers/net/usb/qmi_wwan.c:1338
>
> So, looking over this again and again, the only obviously risky division
> I can see is the usbnet_update_max_qlen() call where we divide on both
> dev->rx_urb_size and dev->hard_mtu.
>
> I don't think dev->rx_urb_size can be 0 unless dev->hard_mtu is 0.  But
> the latter is possible, and this is a bug. In qmi_wwan_bind(), which is
> called by usbnet_probe() prior to the usbnet_update_max_qlen() call, we
> do
>
> if (cdc_ether) {
> dev->hard_mtu = le16_to_cpu(cdc_ether->wMaxSegmentSize);
> usbnet_get_ethernet_addr(dev, cdc_ether->iMACAddress);
> }
>
> which will be fatal if cdc_ether->wMaxSegmentSize is 0.  I assume that
> is what your fuzzer did?  Fix coming up RSN.  Thanks a lot for pointing
> this out.

I don't see the crash with your patches. Thanks for a quick fix!

>
>
> Bjørn

usb/net/qmi_wwan: divide error in qmi_wwan_probe/usbnet_probe

[Andrey Konovalov]

Hi!

I've got the following report while fuzzing the kernel with syzkaller.

On commit 39dae59d66acd86d1de24294bd2f343fd5e7a625 (4.14-rc8).

qmi_wwan 1-1:0.4: cdc-wdm0: USB WDM device
divide error:  [#1] PREEMPT SMP KASAN
Modules linked in:
CPU: 0 PID: 24 Comm: kworker/0:1 Not tainted 4.14.0-rc8-44453-g1fdc1a82c34f #56
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011
Workqueue: usb_hub_wq hub_event
task: 88006bef5c00 task.stack: 88006bf6
RIP: 0010:usbnet_update_max_qlen+0x24d/0x390 drivers/net/usb/usbnet.c:355
RSP: 0018:88006bf67508 EFLAGS: 00010246
RAX: 000163c8 RBX: 8800621fce40 RCX: 8800621fcf34
RDX:  RSI: 837ecb7a RDI: 8800621fcf34
RBP: 88006bf67520 R08: 88006bef5c00 R09: ed000c43f881
R10: ed000c43f880 R11: 8800621fc406 R12: 0003
R13: 85c71de0 R14:  R15: 
FS:  () GS:88006ca0() knlGS:
CS:  0010 DS:  ES:  CR0: 80050033
CR2: 7ffe9c0d6dac CR3: 614f4000 CR4: 06f0
Call Trace:
 usbnet_probe+0x18b5/0x2790 drivers/net/usb/usbnet.c:1783
 qmi_wwan_probe+0x133/0x220 drivers/net/usb/qmi_wwan.c:1338
 usb_probe_interface+0x324/0x940 drivers/usb/core/driver.c:361
 really_probe drivers/base/dd.c:413
 driver_probe_device+0x522/0x740 drivers/base/dd.c:557
 __device_attach_driver+0x25d/0x2d0 drivers/base/dd.c:653
 bus_for_each_drv+0xff/0x160 drivers/base/bus.c:463
 __device_attach+0x1a8/0x2a0 drivers/base/dd.c:710
 device_initial_probe+0x1f/0x30 drivers/base/dd.c:757
 bus_probe_device+0x1fc/0x2a0 drivers/base/bus.c:523
 device_add+0xc27/0x15a0 drivers/base/core.c:1835
 usb_set_configuration+0xd4f/0x17a0 drivers/usb/core/message.c:1932
 generic_probe+0xbb/0x120 drivers/usb/core/generic.c:174
 usb_probe_device+0xab/0x100 drivers/usb/core/driver.c:266
 really_probe drivers/base/dd.c:413
 driver_probe_device+0x522/0x740 drivers/base/dd.c:557
 __device_attach_driver+0x25d/0x2d0 drivers/base/dd.c:653
 bus_for_each_drv+0xff/0x160 drivers/base/bus.c:463
 __device_attach+0x1a8/0x2a0 drivers/base/dd.c:710
 device_initial_probe+0x1f/0x30 drivers/base/dd.c:757
 bus_probe_device+0x1fc/0x2a0 drivers/base/bus.c:523
 device_add+0xc27/0x15a0 drivers/base/core.c:1835
 usb_new_device+0x7fa/0x1090 drivers/usb/core/hub.c:2538
 hub_port_connect drivers/usb/core/hub.c:4987
 hub_port_connect_change drivers/usb/core/hub.c:5093
 port_event drivers/usb/core/hub.c:5199
 hub_event_impl+0x17b8/0x3440 drivers/usb/core/hub.c:5311
 hub_event+0x38/0x50 drivers/usb/core/hub.c:5209
 process_one_work+0x925/0x15d0 kernel/workqueue.c:2113
 worker_thread+0xef/0x10d0 kernel/workqueue.c:2247
 kthread+0x346/0x410 kernel/kthread.c:231
 ret_from_fork+0x2a/0x40 arch/x86/entry/entry_64.S:432
Code: b8 00 00 00 00 00 fc ff df 48 89 fa 48 c1 ea 03 80 3c 02 00 0f
85 46 01 00 00 48 8d bb f4 00 00 00 31 d2 b8 c8 63 01 00 48 89 f9 <48>
f7 b3 b0 01 00 00 48 ba 00 00 00 00 00 fc ff df 48 c1 e9 03
RIP: usbnet_update_max_qlen+0x24d/0x390 RSP: 88006bf67508
---[ end trace 834034903d6f2b37 ]---

Re: [PATCH] net: usb: asix: fill null-ptr-deref in asix_suspend

[Andrey Konovalov]

On Mon, Nov 6, 2017 at 10:49 AM, Oliver Neukum <oneu...@suse.com> wrote:
> Am Donnerstag, den 02.11.2017, 21:26 +0100 schrieb Andrey Konovalov:
>> When asix_suspend() is called dev->driver_priv might not have been
>> assigned a value, so we need to check that it's not NULL.
>>
>> Found by syzkaller.
>
> Hi,

Hi Oliver,

>
> 1. if that happens on suspend, it will also happen on resume

Indeed, got crashes in asix_resume() tonight as well. Mailed v2.

> 2. Will a device work after that? The appropriate fix may be to wait
> until the device is properly initialized.

This shouldn't affect real devices as far as I understand. The crash
can be caused by a crafted malicious device.

Go ahead if you see a better way to fix this, my patch is more of a
hot fix trying to prevent the crashes.

Thanks!

>
> Regards
> Oliver
>

[PATCH v2] net: usb: asix: fill null-ptr-deref in asix_suspend

[Andrey Konovalov]

When asix_suspend() is called dev->driver_priv might not have been
assigned a value, so we need to check that it's not NULL.

Similar issue is present in asix_resume(), this patch fixes it as well.

Found by syzkaller.

kasan: CONFIG_KASAN_INLINE enabled
kasan: GPF could be caused by NULL-ptr deref or user memory access
general protection fault:  [#1] PREEMPT SMP KASAN
Modules linked in:
CPU: 0 PID: 24 Comm: kworker/0:1 Not tainted 4.14.0-rc4-43422-geccacdd69a8c #400
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011
Workqueue: usb_hub_wq hub_event
task: 88006bb36300 task.stack: 88006bba8000
RIP: 0010:asix_suspend+0x76/0xc0 drivers/net/usb/asix_devices.c:629
RSP: 0018:88006bbae718 EFLAGS: 00010202
RAX: dc00 RBX: 880061ba3b80 RCX: 11000c34d644
RDX: 0001 RSI: 0402 RDI: 0008
RBP: 88006bbae738 R08: 11000d775cad R09: 
R10:  R11:  R12: 8800630a8b40
R13:  R14: 0402 R15: 880061ba3b80
FS:  () GS:88006c60() knlGS:
CS:  0010 DS:  ES:  CR0: 80050033
CR2: 7ff33cf89000 CR3: 61c0a000 CR4: 06f0
Call Trace:
 usb_suspend_interface drivers/usb/core/driver.c:1209
 usb_suspend_both+0x27f/0x7e0 drivers/usb/core/driver.c:1314
 usb_runtime_suspend+0x41/0x120 drivers/usb/core/driver.c:1852
 __rpm_callback+0x339/0xb60 drivers/base/power/runtime.c:334
 rpm_callback+0x106/0x220 drivers/base/power/runtime.c:461
 rpm_suspend+0x465/0x1980 drivers/base/power/runtime.c:596
 __pm_runtime_suspend+0x11e/0x230 drivers/base/power/runtime.c:1009
 pm_runtime_put_sync_autosuspend ./include/linux/pm_runtime.h:251
 usb_new_device+0xa37/0x1020 drivers/usb/core/hub.c:2487
 hub_port_connect drivers/usb/core/hub.c:4903
 hub_port_connect_change drivers/usb/core/hub.c:5009
 port_event drivers/usb/core/hub.c:5115
 hub_event+0x194d/0x3740 drivers/usb/core/hub.c:5195
 process_one_work+0xc7f/0x1db0 kernel/workqueue.c:2119
 worker_thread+0x221/0x1850 kernel/workqueue.c:2253
 kthread+0x3a1/0x470 kernel/kthread.c:231
 ret_from_fork+0x2a/0x40 arch/x86/entry/entry_64.S:431
Code: 8d 7c 24 20 48 89 fa 48 c1 ea 03 80 3c 02 00 75 5b 48 b8 00 00
00 00 00 fc ff df 4d 8b 6c 24 20 49 8d 7d 08 48 89 fa 48 c1 ea 03 <80>
3c 02 00 75 34 4d 8b 6d 08 4d 85 ed 74 0b e8 26 2b 51 fd 4c
RIP: asix_suspend+0x76/0xc0 RSP: 88006bbae718
---[ end trace dfc4f5649284342c ]---

Signed-off-by: Andrey Konovalov <andreyk...@google.com>
---

Changes in v2:
- added asix_resume() fix

---
 drivers/net/usb/asix_devices.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/net/usb/asix_devices.c b/drivers/net/usb/asix_devices.c
index b2ff88e69a81..3d4f7959dabb 100644
--- a/drivers/net/usb/asix_devices.c
+++ b/drivers/net/usb/asix_devices.c
@@ -626,7 +626,7 @@ static int asix_suspend(struct usb_interface *intf, 
pm_message_t message)
struct usbnet *dev = usb_get_intfdata(intf);
struct asix_common_private *priv = dev->driver_priv;
 
-   if (priv->suspend)
+   if (priv && priv->suspend)
priv->suspend(dev);
 
return usbnet_suspend(intf, message);
@@ -678,7 +678,7 @@ static int asix_resume(struct usb_interface *intf)
struct usbnet *dev = usb_get_intfdata(intf);
struct asix_common_private *priv = dev->driver_priv;
 
-   if (priv->resume)
+   if (priv && priv->resume)
priv->resume(dev);
 
return usbnet_resume(intf);
-- 
2.15.0.403.gc27cc4dac6-goog

[PATCH] net: usb: asix: fill null-ptr-deref in asix_suspend

[Andrey Konovalov]

When asix_suspend() is called dev->driver_priv might not have been
assigned a value, so we need to check that it's not NULL.

Found by syzkaller.

kasan: CONFIG_KASAN_INLINE enabled
kasan: GPF could be caused by NULL-ptr deref or user memory access
general protection fault:  [#1] PREEMPT SMP KASAN
Modules linked in:
CPU: 0 PID: 24 Comm: kworker/0:1 Not tainted 4.14.0-rc4-43422-geccacdd69a8c #400
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011
Workqueue: usb_hub_wq hub_event
task: 88006bb36300 task.stack: 88006bba8000
RIP: 0010:asix_suspend+0x76/0xc0 drivers/net/usb/asix_devices.c:629
RSP: 0018:88006bbae718 EFLAGS: 00010202
RAX: dc00 RBX: 880061ba3b80 RCX: 11000c34d644
RDX: 0001 RSI: 0402 RDI: 0008
RBP: 88006bbae738 R08: 11000d775cad R09: 
R10:  R11:  R12: 8800630a8b40
R13:  R14: 0402 R15: 880061ba3b80
FS:  () GS:88006c60() knlGS:
CS:  0010 DS:  ES:  CR0: 80050033
CR2: 7ff33cf89000 CR3: 61c0a000 CR4: 06f0
Call Trace:
 usb_suspend_interface drivers/usb/core/driver.c:1209
 usb_suspend_both+0x27f/0x7e0 drivers/usb/core/driver.c:1314
 usb_runtime_suspend+0x41/0x120 drivers/usb/core/driver.c:1852
 __rpm_callback+0x339/0xb60 drivers/base/power/runtime.c:334
 rpm_callback+0x106/0x220 drivers/base/power/runtime.c:461
 rpm_suspend+0x465/0x1980 drivers/base/power/runtime.c:596
 __pm_runtime_suspend+0x11e/0x230 drivers/base/power/runtime.c:1009
 pm_runtime_put_sync_autosuspend ./include/linux/pm_runtime.h:251
 usb_new_device+0xa37/0x1020 drivers/usb/core/hub.c:2487
 hub_port_connect drivers/usb/core/hub.c:4903
 hub_port_connect_change drivers/usb/core/hub.c:5009
 port_event drivers/usb/core/hub.c:5115
 hub_event+0x194d/0x3740 drivers/usb/core/hub.c:5195
 process_one_work+0xc7f/0x1db0 kernel/workqueue.c:2119
 worker_thread+0x221/0x1850 kernel/workqueue.c:2253
 kthread+0x3a1/0x470 kernel/kthread.c:231
 ret_from_fork+0x2a/0x40 arch/x86/entry/entry_64.S:431
Code: 8d 7c 24 20 48 89 fa 48 c1 ea 03 80 3c 02 00 75 5b 48 b8 00 00
00 00 00 fc ff df 4d 8b 6c 24 20 49 8d 7d 08 48 89 fa 48 c1 ea 03 <80>
3c 02 00 75 34 4d 8b 6d 08 4d 85 ed 74 0b e8 26 2b 51 fd 4c
RIP: asix_suspend+0x76/0xc0 RSP: 88006bbae718
---[ end trace dfc4f5649284342c ]---

Signed-off-by: Andrey Konovalov <andreyk...@google.com>
---
 drivers/net/usb/asix_devices.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/usb/asix_devices.c b/drivers/net/usb/asix_devices.c
index b2ff88e69a81..743416be84f3 100644
--- a/drivers/net/usb/asix_devices.c
+++ b/drivers/net/usb/asix_devices.c
@@ -626,7 +626,7 @@ static int asix_suspend(struct usb_interface *intf, 
pm_message_t message)
struct usbnet *dev = usb_get_intfdata(intf);
struct asix_common_private *priv = dev->driver_priv;
 
-   if (priv->suspend)
+   if (priv && priv->suspend)
priv->suspend(dev);
 
return usbnet_suspend(intf, message);
-- 
2.15.0.403.gc27cc4dac6-goog

Re: usb/net/asix: kernel hang in asix_phy_reset

[Andrey Konovalov]

On Tue, Oct 24, 2017 at 4:59 PM, Andrey Konovalov <andreyk...@google.com> wrote:
> Hi!
>
> While fuzzing the kernel with syzkaller I've been getting kernel hangs
> within the asix driver.
>
> On commit 6cff0a118f23b98c604a3604ea9de11338e24fbe (4.14-rc6+).
>
> As far as I can tell the issue is that asix_phy_reset() doesn't
> enforce proper timeout.
>
> asix_phy_reset() calls asix_mdio_read() in a loop 5000 times with 100
> us delay, which gives 500 ms of sleeping time, but it doesn't account
> for the time while asix_mdio_read() executes. asix_mdio_read() in
> turns contains another loop for 30 iterations with a sleep for 1 ms
> (and does a bunch of stuff besides that). As a result asix_mdio_read()
> takes ~80 ms in my setup. This results in at least 5000 * 80 ms = 400
> seconds of delay in addition to those insignificant 500 ms.
>
> Hang stack trace:
>
> [] usb_start_wait_urb+0xfe/0x220 
> drivers/usb/core/message.c:61
> [< inline >] usb_internal_control_msg drivers/usb/core/message.c:100
> [] usb_control_msg+0x2c5/0x3a0 
> drivers/usb/core/message.c:151
> [] __usbnet_read_cmd+0xcd/0x180 
> drivers/net/usb/usbnet.c:1986
> [] usbnet_read_cmd+0x7f/0xe0 drivers/net/usb/usbnet.c:2044
> [] asix_read_cmd+0x75/0xe0 drivers/net/usb/asix_common.c:37
> [] asix_mdio_read+0xbb/0x150 
> drivers/net/usb/asix_common.c:471
> [] asix_phy_reset.isra.9+0xfa/0x1d0
> drivers/net/usb/asix_devices.c:227
> [] ax88172_bind+0x397/0x4e0 
> drivers/net/usb/asix_devices.c:284
> [] usbnet_probe+0xb06/0x2600 drivers/net/usb/usbnet.c:1726
> [] usb_probe_interface+0x358/0x880
> drivers/usb/core/driver.c:361
> [< inline >] really_probe drivers/base/dd.c:413
> [] driver_probe_device+0x490/0x800 drivers/base/dd.c:557
> [] __device_attach_driver+0x22b/0x290 drivers/base/dd.c:653
> [] bus_for_each_drv+0xfa/0x170 drivers/base/bus.c:463
> [] __device_attach+0x1ab/0x290 drivers/base/dd.c:710
> [] device_initial_probe+0x1a/0x20 drivers/base/dd.c:757
> [] bus_probe_device+0x1e6/0x290 drivers/base/bus.c:523
> [] device_add+0xb2f/0x1340 drivers/base/core.c:1835
> [] usb_set_configuration+0xe9d/0x1660
> drivers/usb/core/message.c:1932
> [] generic_probe+0x6e/0xe0 drivers/usb/core/generic.c:174
> [] usb_probe_device+0xaa/0xe0 drivers/usb/core/driver.c:266
> [< inline >] really_probe drivers/base/dd.c:413
> [] driver_probe_device+0x490/0x800 drivers/base/dd.c:557
> [] __device_attach_driver+0x22b/0x290 drivers/base/dd.c:653
> [] bus_for_each_drv+0xfa/0x170 drivers/base/bus.c:463
> [] __device_attach+0x1ab/0x290 drivers/base/dd.c:710
> [] device_initial_probe+0x1a/0x20 drivers/base/dd.c:757
> [] bus_probe_device+0x1e6/0x290 drivers/base/bus.c:523
> [] device_add+0xb2f/0x1340 drivers/base/core.c:1835
> [] usb_new_device+0x7b3/0xff0 drivers/usb/core/hub.c:2457
> [< inline >] hub_port_connect drivers/usb/core/hub.c:4906
> [< inline >] hub_port_connect_change drivers/usb/core/hub.c:5012
> [< inline >] port_event drivers/usb/core/hub.c:5118
> [] hub_event+0x133a/0x2d90 drivers/usb/core/hub.c:5198
> [] process_one_work+0x78b/0x1540 kernel/workqueue.c:2113
> [] worker_thread+0xe7/0xff0 kernel/workqueue.c:2247
> [] kthread+0x33c/0x410 kernel/kthread.c:231
> [] ret_from_fork+0x2a/0x40 arch/x86/entry/entry_64.S:431
> [] 0x

And another hang stack, this time in mdiobus_scan():

[] usb_start_wait_urb+0xfe/0x220 drivers/usb/core/message.c:61
[< inline >] usb_internal_control_msg drivers/usb/core/message.c:100
[] usb_control_msg+0x2c5/0x3a0 drivers/usb/core/message.c:151
[] __usbnet_write_cmd+0xd4/0x170 drivers/net/usb/usbnet.c:2024
[] usbnet_write_cmd+0x7f/0xe0 drivers/net/usb/usbnet.c:2062
[] asix_write_cmd+0x75/0xe0 drivers/net/usb/asix_common.c:60
[] asix_set_sw_mii+0x29/0x90 drivers/net/usb/asix_common.c:288
[] asix_mdio_read+0x75/0x150 drivers/net/usb/asix_common.c:467
[] asix_mdio_bus_read+0x66/0x80 drivers/net/usb/ax88172a.c:43
[] mdiobus_read+0x6f/0x2f0 drivers/net/phy/mdio_bus.c:541
[< inline >] get_phy_id drivers/net/phy/phy_device.c:537
[] get_phy_device+0x74/0x2f0 drivers/net/phy/phy_device.c:569
[] mdiobus_scan+0x1f/0x60 drivers/net/phy/mdio_bus.c:475
[] __mdiobus_register+0x2c6/0x560
drivers/net/phy/mdio_bus.c:377
[< inline >] ax88172a_init_mdio drivers/net/usb/ax88172a.c:117
[] ax88172a_bind+0x515/0x8e0 drivers/net/usb/ax88172a.c:255
[] usbnet_probe+0xb06/0x2600 drivers/net/usb/usbnet.c:1726
[] usb_probe_interface+0x358/0x880
drivers/usb/core/driver.c:361
[< inline >] really_probe drivers/base/dd.c:413
[] driver_probe_device+0x490/0x800 drivers/base/dd.c:557
[] __device_attach_driver+0x22b/0x290 drivers/base/dd.c:653
[] bus_for_each_drv+0xfa/0x170 drivers/base/bus.c:463
[] __device_att

usb/net/asix: kernel hang in asix_phy_reset

[Andrey Konovalov]

Hi!

While fuzzing the kernel with syzkaller I've been getting kernel hangs
within the asix driver.

On commit 6cff0a118f23b98c604a3604ea9de11338e24fbe (4.14-rc6+).

As far as I can tell the issue is that asix_phy_reset() doesn't
enforce proper timeout.

asix_phy_reset() calls asix_mdio_read() in a loop 5000 times with 100
us delay, which gives 500 ms of sleeping time, but it doesn't account
for the time while asix_mdio_read() executes. asix_mdio_read() in
turns contains another loop for 30 iterations with a sleep for 1 ms
(and does a bunch of stuff besides that). As a result asix_mdio_read()
takes ~80 ms in my setup. This results in at least 5000 * 80 ms = 400
seconds of delay in addition to those insignificant 500 ms.

Hang stack trace:

[] usb_start_wait_urb+0xfe/0x220 drivers/usb/core/message.c:61
[< inline >] usb_internal_control_msg drivers/usb/core/message.c:100
[] usb_control_msg+0x2c5/0x3a0 drivers/usb/core/message.c:151
[] __usbnet_read_cmd+0xcd/0x180 drivers/net/usb/usbnet.c:1986
[] usbnet_read_cmd+0x7f/0xe0 drivers/net/usb/usbnet.c:2044
[] asix_read_cmd+0x75/0xe0 drivers/net/usb/asix_common.c:37
[] asix_mdio_read+0xbb/0x150 drivers/net/usb/asix_common.c:471
[] asix_phy_reset.isra.9+0xfa/0x1d0
drivers/net/usb/asix_devices.c:227
[] ax88172_bind+0x397/0x4e0 drivers/net/usb/asix_devices.c:284
[] usbnet_probe+0xb06/0x2600 drivers/net/usb/usbnet.c:1726
[] usb_probe_interface+0x358/0x880
drivers/usb/core/driver.c:361
[< inline >] really_probe drivers/base/dd.c:413
[] driver_probe_device+0x490/0x800 drivers/base/dd.c:557
[] __device_attach_driver+0x22b/0x290 drivers/base/dd.c:653
[] bus_for_each_drv+0xfa/0x170 drivers/base/bus.c:463
[] __device_attach+0x1ab/0x290 drivers/base/dd.c:710
[] device_initial_probe+0x1a/0x20 drivers/base/dd.c:757
[] bus_probe_device+0x1e6/0x290 drivers/base/bus.c:523
[] device_add+0xb2f/0x1340 drivers/base/core.c:1835
[] usb_set_configuration+0xe9d/0x1660
drivers/usb/core/message.c:1932
[] generic_probe+0x6e/0xe0 drivers/usb/core/generic.c:174
[] usb_probe_device+0xaa/0xe0 drivers/usb/core/driver.c:266
[< inline >] really_probe drivers/base/dd.c:413
[] driver_probe_device+0x490/0x800 drivers/base/dd.c:557
[] __device_attach_driver+0x22b/0x290 drivers/base/dd.c:653
[] bus_for_each_drv+0xfa/0x170 drivers/base/bus.c:463
[] __device_attach+0x1ab/0x290 drivers/base/dd.c:710
[] device_initial_probe+0x1a/0x20 drivers/base/dd.c:757
[] bus_probe_device+0x1e6/0x290 drivers/base/bus.c:523
[] device_add+0xb2f/0x1340 drivers/base/core.c:1835
[] usb_new_device+0x7b3/0xff0 drivers/usb/core/hub.c:2457
[< inline >] hub_port_connect drivers/usb/core/hub.c:4906
[< inline >] hub_port_connect_change drivers/usb/core/hub.c:5012
[< inline >] port_event drivers/usb/core/hub.c:5118
[] hub_event+0x133a/0x2d90 drivers/usb/core/hub.c:5198
[] process_one_work+0x78b/0x1540 kernel/workqueue.c:2113
[] worker_thread+0xe7/0xff0 kernel/workqueue.c:2247
[] kthread+0x33c/0x410 kernel/kthread.c:231
[] ret_from_fork+0x2a/0x40 arch/x86/entry/entry_64.S:431
[] 0x

Messages printed to kernel log:

[  244.451821] asix 1-1:0.0 (unnamed net_device) (uninitialized):
Failed to enable software MII access
[  244.470152] asix 1-1:0.0 (unnamed net_device) (uninitialized):
Failed to read reg index 0x: -71
[  244.490199] asix 1-1:0.0 (unnamed net_device) (uninitialized):
Failed to read reg index 0x: -71
[  244.510193] asix 1-1:0.0 (unnamed net_device) (uninitialized):
Failed to write reg index 0x: -71
[  244.511992] asix 1-1:0.0 (unnamed net_device) (uninitialized):
Failed to enable hardware MII access
[  244.530191] asix 1-1:0.0 (unnamed net_device) (uninitialized):
Failed to write reg index 0x: -71
[  244.532024] asix 1-1:0.0 (unnamed net_device) (uninitialized):
Failed to enable software MII access
[  244.550197] asix 1-1:0.0 (unnamed net_device) (uninitialized):
Failed to read reg index 0x: -71
[  244.570198] asix 1-1:0.0 (unnamed net_device) (uninitialized):
Failed to read reg index 0x: -71
[  244.590194] asix 1-1:0.0 (unnamed net_device) (uninitialized):
Failed to write reg index 0x: -71
[  244.591960] asix 1-1:0.0 (unnamed net_device) (uninitialized):
Failed to enable hardware MII access
[  244.610193] asix 1-1:0.0 (unnamed net_device) (uninitialized):
Failed to write reg index 0x: -71
[  244.611978] asix 1-1:0.0 (unnamed net_device) (uninitialized):
Failed to enable software MII access
[  244.630224] asix 1-1:0.0 (unnamed net_device) (uninitialized):
Failed to read reg index 0x: -71
[  244.650197] asix 1-1:0.0 (unnamed net_device) (uninitialized):
Failed to read reg index 0x: -71
[  244.670193] asix 1-1:0.0 (unnamed net_device) (uninitialized):
Failed to write reg index 0x: -71
[  244.671991] asix 1-1:0.0 (unnamed net_device) (uninitialized):
Failed to enable hardware MII access
[  244.690170] asix 1-1:0.0 (unnamed net_device) (uninitialized):
Failed to write reg index 0x: -71
[  244.691907] asix 1-1:0.0 

usb/net/asix: null-ptr-deref in asix_suspend

[Andrey Konovalov]

Hi!

I've got the following report while fuzzing the kernel with syzkaller.

On commit 8a5776a5f49812d29fe4b2d0a2d71675c3facf3f (4.14-rc4).

It seems that priv ends up being NULL.

usb 1-1: New USB device found, idVendor=0557, idProduct=2009
usb 1-1: New USB device strings: Mfr=204, Product=1, SerialNumber=0
usb 1-1: Product: a
usb 1-1: Manufacturer: a
gadgetfs: configuration #4
hub 1-1:4.2: bad descriptor, ignoring hub
hub: probe of 1-1:4.2 failed with error -5
asix 1-1:4.2 (unnamed net_device) (uninitialized): Failed to read reg
index 0x: -75
asix 1-1:4.2 eth1: register 'asix' at usb-dummy_hcd.0-1, ASIX AX8817x
USB 2.0 Ethernet, 08:d1:8e:63:00:88
asix 1-1:4.185 eth2: register 'asix' at usb-dummy_hcd.0-1, ASIX
AX8817x USB 2.0 Ethernet, 08:8f:0a:63:00:88
kasan: CONFIG_KASAN_INLINE enabled
kasan: GPF could be caused by NULL-ptr deref or user memory access
general protection fault:  [#1] PREEMPT SMP KASAN
Modules linked in:
CPU: 0 PID: 24 Comm: kworker/0:1 Not tainted 4.14.0-rc4-43422-geccacdd69a8c #400
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011
Workqueue: usb_hub_wq hub_event
task: 88006bb36300 task.stack: 88006bba8000
RIP: 0010:asix_suspend+0x76/0xc0 drivers/net/usb/asix_devices.c:629
RSP: 0018:88006bbae718 EFLAGS: 00010202
RAX: dc00 RBX: 880061ba3b80 RCX: 11000c34d644
RDX: 0001 RSI: 0402 RDI: 0008
RBP: 88006bbae738 R08: 11000d775cad R09: 
R10:  R11:  R12: 8800630a8b40
R13:  R14: 0402 R15: 880061ba3b80
FS:  () GS:88006c60() knlGS:
CS:  0010 DS:  ES:  CR0: 80050033
CR2: 7ff33cf89000 CR3: 61c0a000 CR4: 06f0
Call Trace:
 usb_suspend_interface drivers/usb/core/driver.c:1209
 usb_suspend_both+0x27f/0x7e0 drivers/usb/core/driver.c:1314
 usb_runtime_suspend+0x41/0x120 drivers/usb/core/driver.c:1852
 __rpm_callback+0x339/0xb60 drivers/base/power/runtime.c:334
 rpm_callback+0x106/0x220 drivers/base/power/runtime.c:461
 rpm_suspend+0x465/0x1980 drivers/base/power/runtime.c:596
 __pm_runtime_suspend+0x11e/0x230 drivers/base/power/runtime.c:1009
 pm_runtime_put_sync_autosuspend ./include/linux/pm_runtime.h:251
 usb_new_device+0xa37/0x1020 drivers/usb/core/hub.c:2487
 hub_port_connect drivers/usb/core/hub.c:4903
 hub_port_connect_change drivers/usb/core/hub.c:5009
 port_event drivers/usb/core/hub.c:5115
 hub_event+0x194d/0x3740 drivers/usb/core/hub.c:5195
 process_one_work+0xc7f/0x1db0 kernel/workqueue.c:2119
 worker_thread+0x221/0x1850 kernel/workqueue.c:2253
 kthread+0x3a1/0x470 kernel/kthread.c:231
 ret_from_fork+0x2a/0x40 arch/x86/entry/entry_64.S:431
Code: 8d 7c 24 20 48 89 fa 48 c1 ea 03 80 3c 02 00 75 5b 48 b8 00 00
00 00 00 fc ff df 4d 8b 6c 24 20 49 8d 7d 08 48 89 fa 48 c1 ea 03 <80>
3c 02 00 75 34 4d 8b 6d 08 4d 85 ed 74 0b e8 26 2b 51 fd 4c
RIP: asix_suspend+0x76/0xc0 RSP: 88006bbae718
---[ end trace dfc4f5649284342c ]---

usb/net/ar5523: warning in ar5523_submit_rx_cmd/usb_submit_urb

[Andrey Konovalov]

Hi!

I've got the following report while fuzzing the kernel with syzkaller.

On commit 8a5776a5f49812d29fe4b2d0a2d71675c3facf3f (4.14-rc4).

It seems that the driver doesn't check the endpoint type provided in
the USB descriptor.

usb 1-1: BOGUS urb xfer, pipe 3 != type 1
[ cut here ]
WARNING: CPU: 1 PID: 2265 at drivers/usb/core/urb.c:449
usb_submit_urb+0xf8a/0x11d0
Modules linked in:
CPU: 1 PID: 2265 Comm: kworker/1:2 Not tainted
4.14.0-rc4-43418-g43a3f84d2109 #379
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011
Workqueue: usb_hub_wq hub_event
task: 88006abc8000 task.stack: 880063e08000
RIP: 0010:usb_submit_urb+0xf8a/0x11d0 drivers/usb/core/urb.c:448
RSP: :880063e0ded0 EFLAGS: 00010286
RAX: 0029 RBX: 8800694cbf00 RCX: 
RDX: 0029 RSI: 86a76d40 RDI: ed000c7c1bcc
RBP: 880063e0dfd0 R08: 11000c7c1a72 R09: 
R10:  R11:  R12: 11000c7c1be1
R13: 0001 R14: 0003 R15: 88006bb47e10
FS:  () GS:88006c50() knlGS:
CS:  0010 DS:  ES:  CR0: 80050033
CR2: 7f43b3d37000 CR3: 695d4000 CR4: 06e0
Call Trace:
 ar5523_submit_rx_cmd+0x20a/0x320 drivers/net/wireless/ath/ar5523/ar5523.c:208
 ar5523_probe+0x1683/0x3af0 drivers/net/wireless/ath/ar5523/ar5523.c:1643
 usb_probe_interface+0x35d/0x8e0 drivers/usb/core/driver.c:361
 really_probe drivers/base/dd.c:413
 driver_probe_device+0x610/0xa00 drivers/base/dd.c:557
 __device_attach_driver+0x230/0x290 drivers/base/dd.c:653
 bus_for_each_drv+0x161/0x210 drivers/base/bus.c:463
 __device_attach+0x26e/0x3d0 drivers/base/dd.c:710
 device_initial_probe+0x1f/0x30 drivers/base/dd.c:757
 bus_probe_device+0x1eb/0x290 drivers/base/bus.c:523
 device_add+0xd0b/0x1660 drivers/base/core.c:1835
 usb_set_configuration+0x104e/0x1870 drivers/usb/core/message.c:1932
 generic_probe+0x73/0xe0 drivers/usb/core/generic.c:174
 usb_probe_device+0xaf/0xe0 drivers/usb/core/driver.c:266
 really_probe drivers/base/dd.c:413
 driver_probe_device+0x610/0xa00 drivers/base/dd.c:557
 __device_attach_driver+0x230/0x290 drivers/base/dd.c:653
 bus_for_each_drv+0x161/0x210 drivers/base/bus.c:463
 __device_attach+0x26e/0x3d0 drivers/base/dd.c:710
 device_initial_probe+0x1f/0x30 drivers/base/dd.c:757
 bus_probe_device+0x1eb/0x290 drivers/base/bus.c:523
 device_add+0xd0b/0x1660 drivers/base/core.c:1835
 usb_new_device+0x7b8/0x1020 drivers/usb/core/hub.c:2457
 hub_port_connect drivers/usb/core/hub.c:4903
 hub_port_connect_change drivers/usb/core/hub.c:5009
 port_event drivers/usb/core/hub.c:5115
 hub_event+0x194d/0x3740 drivers/usb/core/hub.c:5195
 process_one_work+0xc7f/0x1db0 kernel/workqueue.c:2119
 worker_thread+0x221/0x1850 kernel/workqueue.c:2253
 kthread+0x3a1/0x470 kernel/kthread.c:231
 ret_from_fork+0x2a/0x40 arch/x86/entry/entry_64.S:431
Code: 48 8b 85 30 ff ff ff 48 8d b8 98 00 00 00 e8 6e df c7 fe 45 89
e8 44 89 f1 4c 89 fa 48 89 c6 48 c7 c7 c0 ce 04 87 e8 50 6d 16 fd <0f>
ff e9 9b f7 ff ff e8 9a f1 5f fd e9 80 f7 ff ff e8 60 c4 2d
---[ end trace 4ec8ea7915652acc ]---

usb/net/ath6kl: GPF in ath6kl_usb_alloc_urb_from_pipe

[Andrey Konovalov]

Hi!

I've got the following report while fuzzing the kernel with syzkaller.

On commit 8a5776a5f49812d29fe4b2d0a2d71675c3facf3f (4.14-rc4).

usb 1-1: New USB device found, idVendor=0cf3, idProduct=9375
usb 1-1: New USB device strings: Mfr=2, Product=255, SerialNumber=8
usb 1-1: Product: a
usb 1-1: Manufacturer: a
usb 1-1: SerialNumber: a
gadgetfs: configuration #9
kasan: CONFIG_KASAN_INLINE enabled
kasan: GPF could be caused by NULL-ptr deref or user memory access
general protection fault:  [#1] PREEMPT SMP KASAN
Modules linked in:
CPU: 1 PID: 1494 Comm: kworker/1:1 Not tainted
4.14.0-rc4-43418-g43a3f84d2109 #379
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011
Workqueue: usb_hub_wq hub_event
task: 880068e9ca40 task.stack: 880068948000
RIP: 0010:__lock_acquire+0xe18/0x4550 kernel/locking/lockdep.c:3376
RSP: 0018:88006894d788 EFLAGS: 00010006
RAX: dc00 RBX: dc00 RCX: 
RDX: 0003 RSI:  RDI: 11000d129b3c
RBP: 88006894dd08 R08: 0001 R09: 0001
R10:  R11: 89789760 R12: 880068e9ca40
R13: dc00 R14: 0001 R15: 0018
FS:  () GS:88006c50() knlGS:
CS:  0010 DS:  ES:  CR0: 80050033
CR2: 7f9558dca000 CR3: 66dc4000 CR4: 06e0
Call Trace:
 lock_acquire+0x259/0x620 kernel/locking/lockdep.c:4002
 __raw_spin_lock_irqsave ./include/linux/spinlock_api_smp.h:110
 _raw_spin_lock_irqsave+0xcc/0x110 kernel/locking/spinlock.c:159
 ath6kl_usb_alloc_urb_from_pipe+0x103/0x4c0
drivers/net/wireless/ath/ath6kl/usb.c:135
 ath6kl_usb_post_recv_transfers.constprop.10+0x228/0x420
drivers/net/wireless/ath/ath6kl/usb.c:410
 ath6kl_usb_start_recv_pipes drivers/net/wireless/ath/ath6kl/usb.c:484
 hif_start drivers/net/wireless/ath/ath6kl/usb.c:682
 ath6kl_usb_power_on+0x8a/0x120 drivers/net/wireless/ath/ath6kl/usb.c:1041
 ath6kl_hif_power_on drivers/net/wireless/ath/ath6kl/hif-ops.h:136
 ath6kl_core_init+0x180/0x1190 drivers/net/wireless/ath/ath6kl/core.c:97
 ath6kl_usb_probe+0xdf4/0x1420 drivers/net/wireless/ath/ath6kl/usb.c:1147
 usb_probe_interface+0x35d/0x8e0 drivers/usb/core/driver.c:361
 really_probe drivers/base/dd.c:413
 driver_probe_device+0x610/0xa00 drivers/base/dd.c:557
 __device_attach_driver+0x230/0x290 drivers/base/dd.c:653
 bus_for_each_drv+0x161/0x210 drivers/base/bus.c:463
 __device_attach+0x26e/0x3d0 drivers/base/dd.c:710
 device_initial_probe+0x1f/0x30 drivers/base/dd.c:757
 bus_probe_device+0x1eb/0x290 drivers/base/bus.c:523
 device_add+0xd0b/0x1660 drivers/base/core.c:1835
 usb_set_configuration+0x104e/0x1870 drivers/usb/core/message.c:1932
 generic_probe+0x73/0xe0 drivers/usb/core/generic.c:174
 usb_probe_device+0xaf/0xe0 drivers/usb/core/driver.c:266
 really_probe drivers/base/dd.c:413
 driver_probe_device+0x610/0xa00 drivers/base/dd.c:557
 __device_attach_driver+0x230/0x290 drivers/base/dd.c:653
 bus_for_each_drv+0x161/0x210 drivers/base/bus.c:463
 __device_attach+0x26e/0x3d0 drivers/base/dd.c:710
 device_initial_probe+0x1f/0x30 drivers/base/dd.c:757
 bus_probe_device+0x1eb/0x290 drivers/base/bus.c:523
 device_add+0xd0b/0x1660 drivers/base/core.c:1835
 usb_new_device+0x7b8/0x1020 drivers/usb/core/hub.c:2457
 hub_port_connect drivers/usb/core/hub.c:4903
 hub_port_connect_change drivers/usb/core/hub.c:5009
 port_event drivers/usb/core/hub.c:5115
 hub_event+0x194d/0x3740 drivers/usb/core/hub.c:5195
 process_one_work+0xc7f/0x1db0 kernel/workqueue.c:2119
 worker_thread+0x221/0x1850 kernel/workqueue.c:2253
 kthread+0x3a1/0x470 kernel/kthread.c:231
 ret_from_fork+0x2a/0x40 arch/x86/entry/entry_64.S:431
Code: 89 f0 c7 07 00 00 00 00 48 81 c4 58 05 00 00 5b 41 5c 41 5d 41
5e 41 5f 5d c3 48 b8 00 00 00 00 00 fc ff df 4c 89 fa 48 c1 ea 03 <80>
3c 02 00 0f 85 b2 36 00 00 49 81 3f 00 52 bb 88 41 be 00 00
RIP: __lock_acquire+0xe18/0x4550 RSP: 88006894d788
---[ end trace 56dead20dbd7b387 ]---

usb/net/rtlwifi: trying to register non-static key in rtl_c2hcmd_launcher

[Andrey Konovalov]

Hi!

I've got the following report while fuzzing the kernel with syzkaller.

On commit 8a5776a5f49812d29fe4b2d0a2d71675c3facf3f (4.14-rc4).

INFO: trying to register non-static key.
the code is fine but needs lockdep annotation.
turning off the locking correctness validator.
CPU: 0 PID: 24 Comm: kworker/0:1 Not tainted
4.14.0-rc4-43418-g43a3f84d2109-dirty #391
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011
Workqueue: usb_hub_wq hub_event
Call Trace:
 __dump_stack lib/dump_stack.c:16
 dump_stack+0x292/0x395 lib/dump_stack.c:52
 register_lock_class+0x6c4/0x1a00 kernel/locking/lockdep.c:769
 __lock_acquire+0x27e/0x4550 kernel/locking/lockdep.c:3385
 lock_acquire+0x259/0x620 kernel/locking/lockdep.c:4002
 __raw_spin_lock_irqsave ./include/linux/spinlock_api_smp.h:110
 _raw_spin_lock_irqsave+0xcc/0x110 kernel/locking/spinlock.c:159
 rtl_c2hcmd_launcher+0x3ca/0x5d0
drivers/net/wireless/realtek/rtlwifi/base.c:2052
 rtl_deinit_core+0x79/0x350 drivers/net/wireless/realtek/rtlwifi/base.c:590
 rtl_usb_probe+0x1ca3/0x2470 drivers/net/wireless/realtek/rtlwifi/usb.c:1128
 rtl8192cu_probe+0x29/0x30
drivers/net/wireless/realtek/rtlwifi/rtl8192cu/sw.c:398
 usb_probe_interface+0x35d/0x8e0 drivers/usb/core/driver.c:361
 really_probe drivers/base/dd.c:413
 driver_probe_device+0x610/0xa00 drivers/base/dd.c:557
 __device_attach_driver+0x230/0x290 drivers/base/dd.c:653
 bus_for_each_drv+0x161/0x210 drivers/base/bus.c:463
 __device_attach+0x26e/0x3d0 drivers/base/dd.c:710
 device_initial_probe+0x1f/0x30 drivers/base/dd.c:757
 bus_probe_device+0x1eb/0x290 drivers/base/bus.c:523
 device_add+0xd0b/0x1660 drivers/base/core.c:1835
 usb_set_configuration+0x104e/0x1870 drivers/usb/core/message.c:1932
 generic_probe+0x73/0xe0 drivers/usb/core/generic.c:174
 usb_probe_device+0xaf/0xe0 drivers/usb/core/driver.c:266
 really_probe drivers/base/dd.c:413
 driver_probe_device+0x610/0xa00 drivers/base/dd.c:557
 __device_attach_driver+0x230/0x290 drivers/base/dd.c:653
 bus_for_each_drv+0x161/0x210 drivers/base/bus.c:463
 __device_attach+0x26e/0x3d0 drivers/base/dd.c:710
 device_initial_probe+0x1f/0x30 drivers/base/dd.c:757
 bus_probe_device+0x1eb/0x290 drivers/base/bus.c:523
 device_add+0xd0b/0x1660 drivers/base/core.c:1835
 usb_new_device+0x7b8/0x1020 drivers/usb/core/hub.c:2457
 hub_port_connect drivers/usb/core/hub.c:4903
 hub_port_connect_change drivers/usb/core/hub.c:5009
 port_event drivers/usb/core/hub.c:5115
 hub_event+0x194d/0x3740 drivers/usb/core/hub.c:5195
 process_one_work+0xc7f/0x1db0 kernel/workqueue.c:2119
 worker_thread+0x221/0x1850 kernel/workqueue.c:2253
 kthread+0x3a1/0x470 kernel/kthread.c:231
 ret_from_fork+0x2a/0x40 arch/x86/entry/entry_64.S:431

usb/irda: global-out-of-bounds in irda_qos_bits_to_value

[Andrey Konovalov]

Hi!

I've got the following report while fuzzing the kernel with syzkaller.

On commit 8a5776a5f49812d29fe4b2d0a2d71675c3facf3f (4.14-rc4).

It seems that qos->baud_rate.bits value is taken from USB descriptor
and then used as a array index without any checks.

==
BUG: KASAN: global-out-of-bounds in irda_qos_bits_to_value+0x55a/0x5a0
Read of size 4 at addr 881f655c by task syz-executor/5582

CPU: 1 PID: 5582 Comm: syz-executor Not tainted
4.14.0-rc4-43423-g7263a3720c3f #392
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011
Call Trace:
 __dump_stack lib/dump_stack.c:16
 dump_stack+0x292/0x395 lib/dump_stack.c:52
 print_address_description+0x1d9/0x280 mm/kasan/report.c:252
 kasan_report_error mm/kasan/report.c:351
 kasan_report+0x23d/0x350 mm/kasan/report.c:409
 __asan_report_load4_noabort+0x19/0x20 mm/kasan/report.c:429
 irda_qos_bits_to_value+0x55a/0x5a0 drivers/staging/irda/net/qos.c:751
 irda_usb_init_qos drivers/staging/irda/drivers/irda-usb.c:1389
 irda_usb_open drivers/staging/irda/drivers/irda-usb.c:1411
 irda_usb_probe+0x14ea/0x2ca0 drivers/staging/irda/drivers/irda-usb.c:1736
 usb_probe_interface+0x35d/0x8e0 drivers/usb/core/driver.c:361
 really_probe drivers/base/dd.c:413
 driver_probe_device+0x610/0xa00 drivers/base/dd.c:557
 __device_attach_driver+0x230/0x290 drivers/base/dd.c:653
 bus_for_each_drv+0x161/0x210 drivers/base/bus.c:463
 __device_attach+0x26e/0x3d0 drivers/base/dd.c:710
 device_initial_probe+0x1f/0x30 drivers/base/dd.c:757
 bus_probe_device+0x1eb/0x290 drivers/base/bus.c:523
 device_add+0xd0b/0x1660 drivers/base/core.c:1835
 usb_set_configuration+0x104e/0x1870 drivers/usb/core/message.c:1932
 generic_probe+0x73/0xe0 drivers/usb/core/generic.c:174
 usb_probe_device+0xaf/0xe0 drivers/usb/core/driver.c:266
 really_probe drivers/base/dd.c:413
 driver_probe_device+0x610/0xa00 drivers/base/dd.c:557
 __device_attach_driver+0x230/0x290 drivers/base/dd.c:653
 bus_for_each_drv+0x161/0x210 drivers/base/bus.c:463
 __device_attach+0x26e/0x3d0 drivers/base/dd.c:710
 device_initial_probe+0x1f/0x30 drivers/base/dd.c:757
 bus_probe_device+0x1eb/0x290 drivers/base/bus.c:523
 device_add+0xd0b/0x1660 drivers/base/core.c:1835
 usb_new_device+0x7b8/0x1020 drivers/usb/core/hub.c:2538
 hub_port_connect drivers/usb/core/hub.c:4984
 hub_port_connect_change drivers/usb/core/hub.c:5090
 port_event drivers/usb/core/hub.c:5196
 hub_event_impl+0x1971/0x3760 drivers/usb/core/hub.c:5310
 gfs_hub_events_handle+0x881/0xae0 drivers/usb/core/hub.c:1853
 hub_ioctl+0x53d/0x680 drivers/usb/core/hub.c:1903
 proc_ioctl+0x435/0x680 drivers/usb/core/devio.c:2175
 proc_ioctl_default drivers/usb/core/devio.c:2198
 usbdev_do_ioctl+0xee9/0x3790 drivers/usb/core/devio.c:2512
 usbdev_ioctl+0x2a/0x40 drivers/usb/core/devio.c:2556
 vfs_ioctl fs/ioctl.c:45
 do_vfs_ioctl+0x1c4/0x15c0 fs/ioctl.c:685
 SYSC_ioctl fs/ioctl.c:700
 SyS_ioctl+0x94/0xc0 fs/ioctl.c:691
 entry_SYSCALL_64_fastpath+0x23/0xc2 arch/x86/entry/entry_64.S:202

RIP: 0033:0x447707
RSP: 002b:7ffd24fe61a8 EFLAGS: 0202 ORIG_RAX: 0010
RAX: ffda RBX:  RCX: 00447707
RDX: 7ffd24fe61c0 RSI: c0105512 RDI: 0015
RBP: 0005 R08: 0265c940 R09: 0265c940
R10: 004a8e59 R11: 0202 R12: 0015
R13:  R14: 7ffd24fe6078 R15: 7ffd24fe60e8

The buggy address belongs to the variable:
 baud_rates+0x3c/0x60

Memory state around the buggy address:
 881f6400: 00 00 00 00 00 00 00 fa fa fa fa fa 00 00 00 00
 881f6480: fa fa fa fa 00 00 fa fa fa fa fa fa 00 00 00 fa
>881f6500: fa fa fa fa 00 00 00 00 00 fa fa fa fa fa fa fa
^
 881f6580: 00 00 00 00 fa fa fa fa 04 fa fa fa fa fa fa fa
 881f6600: 04 fa fa fa fa fa fa fa 04 fa fa fa fa fa fa fa
==

usb/net/rt2x00: warning in rt2800_eeprom_word_index

[Andrey Konovalov]

Hi!

I've got the following report while fuzzing the kernel with syzkaller.

On commit 8a5776a5f49812d29fe4b2d0a2d71675c3facf3f (4.14-rc4).

I'm not sure whether this is a bug in the driver, or just a way to
report misbehaving device. In the latter case this shouldn't be a
WARN() call, since WARN() means bug in the kernel.

phy2: invalid access of EEPROM word 39
[ cut here ]
WARNING: CPU: 1 PID: 5591 at
drivers/net/wireless/ralink/rt2x00/rt2800lib.c:399
rt2800_eeprom_word_index.isra.15+0x149/0x1c0
Modules linked in:
CPU: 1 PID: 5591 Comm: syz-executor Not tainted
4.14.0-rc4-43423-g7263a3720c3f #392
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011
task: 880069933180 task.stack: 88005aee8000
RIP: 0010:rt2800_eeprom_word_index.isra.15+0x149/0x1c0
drivers/net/wireless/ralink/rt2x00/rt2800lib.c:397
RSP: 0018:88005aeed960 EFLAGS: 00010282
RAX: 0026 RBX: 88005af0c5c0 RCX: 
RDX: 0026 RSI: 813292c9 RDI: ed000b5ddb1e
RBP: 88005aeed978 R08: 88005aeecd90 R09: 
R10:  R11:  R12: 0027
R13: 880068631018 R14: 0052 R15: 
FS:  01c60940() GS:88006c70() knlGS:
CS:  0010 DS:  ES:  CR0: 80050033
CR2: 01967000 CR3: 68089000 CR4: 06e0
Call Trace:
 rt2800_eeprom_addr drivers/net/wireless/ralink/rt2x00/rt2800lib.c:409
 rt2800_probe_hw_mode drivers/net/wireless/ralink/rt2x00/rt2800lib.c:9321
 rt2800_probe_hw+0x19ef/0x27b0
drivers/net/wireless/ralink/rt2x00/rt2800lib.c:9456
 rt2800usb_probe_hw+0x6e/0x200
drivers/net/wireless/ralink/rt2x00/rt2800usb.c:768
 rt2x00lib_probe_dev+0x9e5/0x2800
drivers/net/wireless/ralink/rt2x00/rt2x00dev.c:1427
 rt2x00usb_probe+0x67b/0x990 drivers/net/wireless/ralink/rt2x00/rt2x00usb.c:837
 rt2800usb_probe+0x21/0x30 drivers/net/wireless/ralink/rt2x00/rt2800usb.c:1410
 usb_probe_interface+0x35d/0x8e0 drivers/usb/core/driver.c:361
 really_probe drivers/base/dd.c:413
 driver_probe_device+0x610/0xa00 drivers/base/dd.c:557
 __device_attach_driver+0x230/0x290 drivers/base/dd.c:653
 bus_for_each_drv+0x161/0x210 drivers/base/bus.c:463
 __device_attach+0x26e/0x3d0 drivers/base/dd.c:710
 device_initial_probe+0x1f/0x30 drivers/base/dd.c:757
 bus_probe_device+0x1eb/0x290 drivers/base/bus.c:523
 device_add+0xd0b/0x1660 drivers/base/core.c:1835
 usb_set_configuration+0x104e/0x1870 drivers/usb/core/message.c:1932
 generic_probe+0x73/0xe0 drivers/usb/core/generic.c:174
 usb_probe_device+0xaf/0xe0 drivers/usb/core/driver.c:266
 really_probe drivers/base/dd.c:413
 driver_probe_device+0x610/0xa00 drivers/base/dd.c:557
 __device_attach_driver+0x230/0x290 drivers/base/dd.c:653
 bus_for_each_drv+0x161/0x210 drivers/base/bus.c:463
 __device_attach+0x26e/0x3d0 drivers/base/dd.c:710
 device_initial_probe+0x1f/0x30 drivers/base/dd.c:757
 bus_probe_device+0x1eb/0x290 drivers/base/bus.c:523
 device_add+0xd0b/0x1660 drivers/base/core.c:1835
 usb_new_device+0x7b8/0x1020 drivers/usb/core/hub.c:2538
 hub_port_connect drivers/usb/core/hub.c:4984
 hub_port_connect_change drivers/usb/core/hub.c:5090
 port_event drivers/usb/core/hub.c:5196
 hub_event_impl+0x1971/0x3760 drivers/usb/core/hub.c:5310
 gfs_hub_events_handle+0x881/0xae0 drivers/usb/core/hub.c:1853
 hub_ioctl+0x53d/0x680 drivers/usb/core/hub.c:1903
 proc_ioctl+0x435/0x680 drivers/usb/core/devio.c:2175
 proc_ioctl_default drivers/usb/core/devio.c:2198
 usbdev_do_ioctl+0xee9/0x3790 drivers/usb/core/devio.c:2512
 usbdev_ioctl+0x2a/0x40 drivers/usb/core/devio.c:2556
 vfs_ioctl fs/ioctl.c:45
 do_vfs_ioctl+0x1c4/0x15c0 fs/ioctl.c:685
 SYSC_ioctl fs/ioctl.c:700
 SyS_ioctl+0x94/0xc0 fs/ioctl.c:691
 entry_SYSCALL_64_fastpath+0x23/0xc2 arch/x86/entry/entry_64.S:202
RIP: 0033:0x447707
RSP: 002b:7ffd565109b8 EFLAGS: 0206 ORIG_RAX: 0010
RAX: ffda RBX:  RCX: 00447707
RDX: 7ffd565109d0 RSI: c0105512 RDI: 0015
RBP: 0005 R08: 01c60940 R09: 01c60940
R10: 004a8e59 R11: 0206 R12: 0015
R13:  R14: 7ffd56510888 R15: 7ffd565108f8
Code: ea 03 80 3c 02 00 75 72 4c 8b ab 70 01 00 00 4d 85 ed 74 3a e8
29 c5 9b fd 44 89 e2 4c 89 ee 48 c7 c7 e0 4d d5 86 e8 f1 6d 84 fd <0f>
ff 31 db e9 4c ff ff ff 48 89 df e8 36 f2 cd fd e9 34 ff ff
---[ end trace a71f41162bce05c3 ]---

Re: [RFT] lan78xx: FIX use-after-free in lan78xx_write_reg

[Andrey Konovalov]

On Wed, Sep 27, 2017 at 2:06 PM, Andrey Konovalov <andreyk...@google.com> wrote:
> On Wed, Sep 27, 2017 at 1:18 PM, Arvind Yadav <arvind.yadav...@gmail.com> 
> wrote:
>> We are not releasing 'buf' memory on failure or disconnect a device.
>>
>> Adding 'u8 *buf' as part of 'lan78xx_net' structure to make proper
>> handle for 'buf'.
>> Now releasing 'buf' memory on failure. It's allocate first in
>> lan78xx_probe() and it should be freed last in lan78xx_disconnect().
>>
>> Signed-off-by: Arvind Yadav <arvind.yadav...@gmail.com>
>
> Hi Arvind,
>
> I've tried your patch and still see a crash.
>
> Thanks!
>
> lan78xx 1-1:90.0 (unnamed net_device) (uninitialized): can't register MDIO bus
> lan78xx: probe of 1-1:90.0 failed with error -5
> usb 1-1: USB disconnect, device number 2
> ==
> BUG: KASAN: use-after-free in lan78xx_write_reg.isra.21+0x1a8/0x1b0
> Read of size 8 at addr 880063dfac40 by task kworker/1:1/1152

It seems that the bug is caused by the fact that the
lan78xx_deferred_multicast_write() work is not shut down on
lan78xx_probe() failure.

>
> CPU: 1 PID: 1152 Comm: kworker/1:1 Not tainted
> 4.14.0-rc2-42660-g24b7bd59eec0-dirty #274
> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011
> Workqueue: events lan78xx_deferred_multicast_write
> Call Trace:
>  __dump_stack lib/dump_stack.c:16
>  dump_stack+0x292/0x395 lib/dump_stack.c:52
>  print_address_description+0x78/0x280 mm/kasan/report.c:252
>  kasan_report_error mm/kasan/report.c:351
>  kasan_report+0x23d/0x350 mm/kasan/report.c:409
>  __asan_report_load8_noabort+0x19/0x20 mm/kasan/report.c:430
>  lan78xx_write_reg.isra.21+0x1a8/0x1b0 drivers/net/usb/lan78xx.c:459
>  lan78xx_deferred_multicast_write+0x10d/0x1a0 drivers/net/usb/lan78xx.c:1043
>  process_one_work+0xc7f/0x1db0 kernel/workqueue.c:2119
>  worker_thread+0x221/0x1850 kernel/workqueue.c:2253
>  kthread+0x3a1/0x470 kernel/kthread.c:231
>  ret_from_fork+0x2a/0x40 arch/x86/entry/entry_64.S:431
>
> Allocated by task 1848:
>  save_stack_trace+0x1b/0x20 arch/x86/kernel/stacktrace.c:59
>  save_stack+0x43/0xd0 mm/kasan/kasan.c:447
>  set_track mm/kasan/kasan.c:459
>  kasan_kmalloc+0xad/0xe0 mm/kasan/kasan.c:551
>  __kmalloc_node+0x192/0x480 mm/slub.c:3827
>  kmalloc_node ./include/linux/slab.h:535
>  kvmalloc_node+0x69/0xd0 mm/util.c:397
>  kvmalloc ./include/linux/mm.h:529
>  kvzalloc ./include/linux/mm.h:537
>  alloc_netdev_mqs+0x173/0xea0 net/core/dev.c:8023
>  alloc_etherdev_mqs+0x38/0x40 net/ethernet/eth.c:391
>  lan78xx_probe+0x13a/0x3020 drivers/net/usb/lan78xx.c:3545
>  usb_probe_interface+0x35d/0x8e0 drivers/usb/core/driver.c:361
>  really_probe drivers/base/dd.c:413
>  driver_probe_device+0x610/0xa00 drivers/base/dd.c:557
>  __device_attach_driver+0x230/0x290 drivers/base/dd.c:653
>  bus_for_each_drv+0x161/0x210 drivers/base/bus.c:463
>  __device_attach+0x26e/0x3d0 drivers/base/dd.c:710
>  device_initial_probe+0x1f/0x30 drivers/base/dd.c:757
>  bus_probe_device+0x1eb/0x290 drivers/base/bus.c:523
>  device_add+0xd0b/0x1660 drivers/base/core.c:1835
>  usb_set_configuration+0x104e/0x1870 drivers/usb/core/message.c:1932
>  generic_probe+0x73/0xe0 drivers/usb/core/generic.c:174
>  usb_probe_device+0xaf/0xe0 drivers/usb/core/driver.c:266
>  really_probe drivers/base/dd.c:413
>  driver_probe_device+0x610/0xa00 drivers/base/dd.c:557
>  __device_attach_driver+0x230/0x290 drivers/base/dd.c:653
>  bus_for_each_drv+0x161/0x210 drivers/base/bus.c:463
>  __device_attach+0x26e/0x3d0 drivers/base/dd.c:710
>  device_initial_probe+0x1f/0x30 drivers/base/dd.c:757
>  bus_probe_device+0x1eb/0x290 drivers/base/bus.c:523
>  device_add+0xd0b/0x1660 drivers/base/core.c:1835
>  usb_new_device+0x7b8/0x1020 drivers/usb/core/hub.c:2457
>  hub_port_connect drivers/usb/core/hub.c:4903
>  hub_port_connect_change drivers/usb/core/hub.c:5009
>  port_event drivers/usb/core/hub.c:5115
>  hub_event+0x194d/0x3740 drivers/usb/core/hub.c:5195
>  process_one_work+0xc7f/0x1db0 kernel/workqueue.c:2119
>  worker_thread+0x221/0x1850 kernel/workqueue.c:2253
>  kthread+0x3a1/0x470 kernel/kthread.c:231
>  ret_from_fork+0x2a/0x40 arch/x86/entry/entry_64.S:431
>
> Freed by task 1848:
>  save_stack_trace+0x1b/0x20 arch/x86/kernel/stacktrace.c:59
>  save_stack+0x43/0xd0 mm/kasan/kasan.c:447
>  set_track mm/kasan/kasan.c:459
>  kasan_slab_free+0x72/0xc0 mm/kasan/kasan.c:524
>  slab_free_hook mm/slub.c:1390
>  slab_free_freelist_hook mm/slub.c:1412
>  slab_free mm/slub.c:2988
>  kfree+0xf6/0x2f0 mm/slub.c:3919
>  kvfree+0x3b/0x60 mm/util.c:416
>  netdev_freemem net/core/dev.c:7975
>  free_netdev+0x304/0x3c0 net/core/dev.

Re: [RFT] lan78xx: FIX use-after-free in lan78xx_write_reg

[Andrey Konovalov]

On Wed, Sep 27, 2017 at 1:18 PM, Arvind Yadav  wrote:
> We are not releasing 'buf' memory on failure or disconnect a device.
>
> Adding 'u8 *buf' as part of 'lan78xx_net' structure to make proper
> handle for 'buf'.
> Now releasing 'buf' memory on failure. It's allocate first in
> lan78xx_probe() and it should be freed last in lan78xx_disconnect().
>
> Signed-off-by: Arvind Yadav 

Hi Arvind,

I've tried your patch and still see a crash.

Thanks!

lan78xx 1-1:90.0 (unnamed net_device) (uninitialized): can't register MDIO bus
lan78xx: probe of 1-1:90.0 failed with error -5
usb 1-1: USB disconnect, device number 2
==
BUG: KASAN: use-after-free in lan78xx_write_reg.isra.21+0x1a8/0x1b0
Read of size 8 at addr 880063dfac40 by task kworker/1:1/1152

CPU: 1 PID: 1152 Comm: kworker/1:1 Not tainted
4.14.0-rc2-42660-g24b7bd59eec0-dirty #274
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011
Workqueue: events lan78xx_deferred_multicast_write
Call Trace:
 __dump_stack lib/dump_stack.c:16
 dump_stack+0x292/0x395 lib/dump_stack.c:52
 print_address_description+0x78/0x280 mm/kasan/report.c:252
 kasan_report_error mm/kasan/report.c:351
 kasan_report+0x23d/0x350 mm/kasan/report.c:409
 __asan_report_load8_noabort+0x19/0x20 mm/kasan/report.c:430
 lan78xx_write_reg.isra.21+0x1a8/0x1b0 drivers/net/usb/lan78xx.c:459
 lan78xx_deferred_multicast_write+0x10d/0x1a0 drivers/net/usb/lan78xx.c:1043
 process_one_work+0xc7f/0x1db0 kernel/workqueue.c:2119
 worker_thread+0x221/0x1850 kernel/workqueue.c:2253
 kthread+0x3a1/0x470 kernel/kthread.c:231
 ret_from_fork+0x2a/0x40 arch/x86/entry/entry_64.S:431

Allocated by task 1848:
 save_stack_trace+0x1b/0x20 arch/x86/kernel/stacktrace.c:59
 save_stack+0x43/0xd0 mm/kasan/kasan.c:447
 set_track mm/kasan/kasan.c:459
 kasan_kmalloc+0xad/0xe0 mm/kasan/kasan.c:551
 __kmalloc_node+0x192/0x480 mm/slub.c:3827
 kmalloc_node ./include/linux/slab.h:535
 kvmalloc_node+0x69/0xd0 mm/util.c:397
 kvmalloc ./include/linux/mm.h:529
 kvzalloc ./include/linux/mm.h:537
 alloc_netdev_mqs+0x173/0xea0 net/core/dev.c:8023
 alloc_etherdev_mqs+0x38/0x40 net/ethernet/eth.c:391
 lan78xx_probe+0x13a/0x3020 drivers/net/usb/lan78xx.c:3545
 usb_probe_interface+0x35d/0x8e0 drivers/usb/core/driver.c:361
 really_probe drivers/base/dd.c:413
 driver_probe_device+0x610/0xa00 drivers/base/dd.c:557
 __device_attach_driver+0x230/0x290 drivers/base/dd.c:653
 bus_for_each_drv+0x161/0x210 drivers/base/bus.c:463
 __device_attach+0x26e/0x3d0 drivers/base/dd.c:710
 device_initial_probe+0x1f/0x30 drivers/base/dd.c:757
 bus_probe_device+0x1eb/0x290 drivers/base/bus.c:523
 device_add+0xd0b/0x1660 drivers/base/core.c:1835
 usb_set_configuration+0x104e/0x1870 drivers/usb/core/message.c:1932
 generic_probe+0x73/0xe0 drivers/usb/core/generic.c:174
 usb_probe_device+0xaf/0xe0 drivers/usb/core/driver.c:266
 really_probe drivers/base/dd.c:413
 driver_probe_device+0x610/0xa00 drivers/base/dd.c:557
 __device_attach_driver+0x230/0x290 drivers/base/dd.c:653
 bus_for_each_drv+0x161/0x210 drivers/base/bus.c:463
 __device_attach+0x26e/0x3d0 drivers/base/dd.c:710
 device_initial_probe+0x1f/0x30 drivers/base/dd.c:757
 bus_probe_device+0x1eb/0x290 drivers/base/bus.c:523
 device_add+0xd0b/0x1660 drivers/base/core.c:1835
 usb_new_device+0x7b8/0x1020 drivers/usb/core/hub.c:2457
 hub_port_connect drivers/usb/core/hub.c:4903
 hub_port_connect_change drivers/usb/core/hub.c:5009
 port_event drivers/usb/core/hub.c:5115
 hub_event+0x194d/0x3740 drivers/usb/core/hub.c:5195
 process_one_work+0xc7f/0x1db0 kernel/workqueue.c:2119
 worker_thread+0x221/0x1850 kernel/workqueue.c:2253
 kthread+0x3a1/0x470 kernel/kthread.c:231
 ret_from_fork+0x2a/0x40 arch/x86/entry/entry_64.S:431

Freed by task 1848:
 save_stack_trace+0x1b/0x20 arch/x86/kernel/stacktrace.c:59
 save_stack+0x43/0xd0 mm/kasan/kasan.c:447
 set_track mm/kasan/kasan.c:459
 kasan_slab_free+0x72/0xc0 mm/kasan/kasan.c:524
 slab_free_hook mm/slub.c:1390
 slab_free_freelist_hook mm/slub.c:1412
 slab_free mm/slub.c:2988
 kfree+0xf6/0x2f0 mm/slub.c:3919
 kvfree+0x3b/0x60 mm/util.c:416
 netdev_freemem net/core/dev.c:7975
 free_netdev+0x304/0x3c0 net/core/dev.c:8137
 lan78xx_probe+0x21a4/0x3020 drivers/net/usb/lan78xx.c:3649
 usb_probe_interface+0x35d/0x8e0 drivers/usb/core/driver.c:361
 really_probe drivers/base/dd.c:413
 driver_probe_device+0x610/0xa00 drivers/base/dd.c:557
 __device_attach_driver+0x230/0x290 drivers/base/dd.c:653
 bus_for_each_drv+0x161/0x210 drivers/base/bus.c:463
 __device_attach+0x26e/0x3d0 drivers/base/dd.c:710
 device_initial_probe+0x1f/0x30 drivers/base/dd.c:757
 bus_probe_device+0x1eb/0x290 drivers/base/bus.c:523
 device_add+0xd0b/0x1660 drivers/base/core.c:1835
 usb_set_configuration+0x104e/0x1870 drivers/usb/core/message.c:1932
 generic_probe+0x73/0xe0 drivers/usb/core/generic.c:174
 usb_probe_device+0xaf/0xe0 drivers/usb/core/driver.c:266
 

Re: [PATCH] p54: don't unregister leds when they are inited

[Andrey Konovalov]

On Tue, Sep 26, 2017 at 5:08 PM, Johannes Berg
 wrote:
> Subject should say *not* initialized?

Yes, sent v2.

>
> johannes

[PATCH v2] p54: don't unregister leds when they are not initialized

[Andrey Konovalov]

ieee80211_register_hw() in p54_register_common() may fail and leds won't
get initialized. Currently p54_unregister_common() doesn't check that and
always calls p54_unregister_leds(). The fix is to check priv->registered
flag before calling p54_unregister_leds().

Found by syzkaller.

INFO: trying to register non-static key.
the code is fine but needs lockdep annotation.
turning off the locking correctness validator.
CPU: 1 PID: 1404 Comm: kworker/1:1 Not tainted
4.14.0-rc1-42251-gebb2c2437d80-dirty #205
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011
Workqueue: usb_hub_wq hub_event
Call Trace:
 __dump_stack lib/dump_stack.c:16
 dump_stack+0x292/0x395 lib/dump_stack.c:52
 register_lock_class+0x6c4/0x1a00 kernel/locking/lockdep.c:769
 __lock_acquire+0x27e/0x4550 kernel/locking/lockdep.c:3385
 lock_acquire+0x259/0x620 kernel/locking/lockdep.c:4002
 flush_work+0xf0/0x8c0 kernel/workqueue.c:2886
 __cancel_work_timer+0x51d/0x870 kernel/workqueue.c:2961
 cancel_delayed_work_sync+0x1f/0x30 kernel/workqueue.c:3081
 p54_unregister_leds+0x6c/0xc0 drivers/net/wireless/intersil/p54/led.c:160
 p54_unregister_common+0x3d/0xb0 drivers/net/wireless/intersil/p54/main.c:856
 p54u_disconnect+0x86/0x120 drivers/net/wireless/intersil/p54/p54usb.c:1073
 usb_unbind_interface+0x21c/0xa90 drivers/usb/core/driver.c:423
 __device_release_driver drivers/base/dd.c:861
 device_release_driver_internal+0x4f4/0x5c0 drivers/base/dd.c:893
 device_release_driver+0x1e/0x30 drivers/base/dd.c:918
 bus_remove_device+0x2f4/0x4b0 drivers/base/bus.c:565
 device_del+0x5c4/0xab0 drivers/base/core.c:1985
 usb_disable_device+0x1e9/0x680 drivers/usb/core/message.c:1170
 usb_disconnect+0x260/0x7a0 drivers/usb/core/hub.c:2124
 hub_port_connect drivers/usb/core/hub.c:4754
 hub_port_connect_change drivers/usb/core/hub.c:5009
 port_event drivers/usb/core/hub.c:5115
 hub_event+0x1318/0x3740 drivers/usb/core/hub.c:5195
 process_one_work+0xc7f/0x1db0 kernel/workqueue.c:2119
 process_scheduled_works kernel/workqueue.c:2179
 worker_thread+0xb2b/0x1850 kernel/workqueue.c:2255
 kthread+0x3a1/0x470 kernel/kthread.c:231
 ret_from_fork+0x2a/0x40 arch/x86/entry/entry_64.S:431

Signed-off-by: Andrey Konovalov <andreyk...@google.com>
---

changes in v2:
- fixed typo in patch subject

---
 drivers/net/wireless/intersil/p54/main.c | 7 +++
 1 file changed, 3 insertions(+), 4 deletions(-)

diff --git a/drivers/net/wireless/intersil/p54/main.c 
b/drivers/net/wireless/intersil/p54/main.c
index d5a3bf91a03e..ab6d39e12069 100644
--- a/drivers/net/wireless/intersil/p54/main.c
+++ b/drivers/net/wireless/intersil/p54/main.c
@@ -852,12 +852,11 @@ void p54_unregister_common(struct ieee80211_hw *dev)
 {
struct p54_common *priv = dev->priv;
 
-#ifdef CONFIG_P54_LEDS
-   p54_unregister_leds(priv);
-#endif /* CONFIG_P54_LEDS */
-
if (priv->registered) {
priv->registered = false;
+#ifdef CONFIG_P54_LEDS
+   p54_unregister_leds(priv);
+#endif /* CONFIG_P54_LEDS */
ieee80211_unregister_hw(dev);
}
 
-- 
2.14.1.821.g8fa685d3b7-goog

Re: [RESEND] Re: usb/net/p54: trying to register non-static key in p54_unregister_leds

[Andrey Konovalov]

On Sat, Sep 23, 2017 at 9:37 PM, 'Christian Lamparter' via syzkaller
<syzkal...@googlegroups.com> wrote:
> This got rejected by gmail once. Let's see if it works now.
>
> On Thursday, September 21, 2017 8:22:45 PM CEST Andrey Konovalov wrote:
>> On Wed, Sep 20, 2017 at 9:55 PM, Johannes Berg
>> <johan...@sipsolutions.net> wrote:
>> > On Wed, 2017-09-20 at 21:27 +0200, Christian Lamparter wrote:
>> >
>> >> It seems this is caused as a result of:
>> >> -> lock_map_acquire(>lockdep_map);
>> >>   lock_map_release(>lockdep_map);
>> >>
>> >> in flush_work() [0]
>> >
>> > Agree.
>> >
>> >> This was added by:
>> >>
>> >>   commit 0976dfc1d0cd80a4e9dfaf87bd8744612bde475a
>> >>   Author: Stephen Boyd <sb...@codeaurora.org>
>> >>   Date:   Fri Apr 20 17:28:50 2012 -0700
>> >>
>> >>   workqueue: Catch more locking problems with flush_work()
>> >
>> > Yes, but that doesn't matter.
>> >
>> >> Looking at the Stephen's patch, it's clear that it was made
>> >> with "static DECLARE_WORK(work, my_work)" in mind. However
>> >> p54's led_work is "per-device", hence it is stored in the
>> >> devices context p54_common, which is dynamically allocated.
>> >> So, maybe revert Stephen's patch?
>> >
>> > I disagree - as the lockdep warning says:
>> >
>> >> > INFO: trying to register non-static key.
>> >> > the code is fine but needs lockdep annotation.
>> >> > turning off the locking correctness validator.
>> >
>> > What it needs is to actually correctly go through initializing the work
>> > at least once.
>> >
>> > Without more information, I can't really say what's going on, but I
>> > assume that something is failing and p54_unregister_leds() is getting
>> > invoked without p54_init_leds() having been invoked, so essentially
>> > it's trying to flush a work that was never initialized?
>> >
>> > INIT_DELAYED_WORK() does, after all, initialize the lockdep map
>> > properly via __INIT_WORK().
>
> Ok, thanks. This does indeed explain it.
>
> But this also begs the question: Is this really working then?
> From what I can tell, if CONFIG_LOCKDEP is not set then there's no BUG
> no WARN, no other splat or any other odd system behaviour. Does
> [cancel | flush]_[delayed_]work[_sync] really "just work" by *accident*,
> as long the delayed_work | work_struct is zeroed out?
> And should it work in the future as well?
>
>> Since I'm able to reproduce this, please let me know if you need me to
>> collect some debug traces to help with the triage.
>
> Do you want to take a shot at making a patch too? At a quick glance, it
> should be enough to move the [#ifdef CONFIG_P54_LEDS ... #endif] block
> in p54_unregister_common() into the if (priv->registered) { block
> (preferably before the ieee80211_unregister_hw(dev).

Just mailed a patch.

>
> Regards,
> Christian
>
> --
> You received this message because you are subscribed to the Google Groups 
> "syzkaller" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to syzkaller+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

[PATCH] p54: don't unregister leds when they are inited

[Andrey Konovalov]

ieee80211_register_hw() in p54_register_common() may fail and leds won't
get initialized. Currently p54_unregister_common() doesn't check that and
always calls p54_unregister_leds(). The fix is to check priv->registered
flag before calling p54_unregister_leds().

Found by syzkaller.

INFO: trying to register non-static key.
the code is fine but needs lockdep annotation.
turning off the locking correctness validator.
CPU: 1 PID: 1404 Comm: kworker/1:1 Not tainted
4.14.0-rc1-42251-gebb2c2437d80-dirty #205
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011
Workqueue: usb_hub_wq hub_event
Call Trace:
 __dump_stack lib/dump_stack.c:16
 dump_stack+0x292/0x395 lib/dump_stack.c:52
 register_lock_class+0x6c4/0x1a00 kernel/locking/lockdep.c:769
 __lock_acquire+0x27e/0x4550 kernel/locking/lockdep.c:3385
 lock_acquire+0x259/0x620 kernel/locking/lockdep.c:4002
 flush_work+0xf0/0x8c0 kernel/workqueue.c:2886
 __cancel_work_timer+0x51d/0x870 kernel/workqueue.c:2961
 cancel_delayed_work_sync+0x1f/0x30 kernel/workqueue.c:3081
 p54_unregister_leds+0x6c/0xc0 drivers/net/wireless/intersil/p54/led.c:160
 p54_unregister_common+0x3d/0xb0 drivers/net/wireless/intersil/p54/main.c:856
 p54u_disconnect+0x86/0x120 drivers/net/wireless/intersil/p54/p54usb.c:1073
 usb_unbind_interface+0x21c/0xa90 drivers/usb/core/driver.c:423
 __device_release_driver drivers/base/dd.c:861
 device_release_driver_internal+0x4f4/0x5c0 drivers/base/dd.c:893
 device_release_driver+0x1e/0x30 drivers/base/dd.c:918
 bus_remove_device+0x2f4/0x4b0 drivers/base/bus.c:565
 device_del+0x5c4/0xab0 drivers/base/core.c:1985
 usb_disable_device+0x1e9/0x680 drivers/usb/core/message.c:1170
 usb_disconnect+0x260/0x7a0 drivers/usb/core/hub.c:2124
 hub_port_connect drivers/usb/core/hub.c:4754
 hub_port_connect_change drivers/usb/core/hub.c:5009
 port_event drivers/usb/core/hub.c:5115
 hub_event+0x1318/0x3740 drivers/usb/core/hub.c:5195
 process_one_work+0xc7f/0x1db0 kernel/workqueue.c:2119
 process_scheduled_works kernel/workqueue.c:2179
 worker_thread+0xb2b/0x1850 kernel/workqueue.c:2255
 kthread+0x3a1/0x470 kernel/kthread.c:231
 ret_from_fork+0x2a/0x40 arch/x86/entry/entry_64.S:431

Signed-off-by: Andrey Konovalov <andreyk...@google.com>
---
 drivers/net/wireless/intersil/p54/main.c | 7 +++
 1 file changed, 3 insertions(+), 4 deletions(-)

diff --git a/drivers/net/wireless/intersil/p54/main.c 
b/drivers/net/wireless/intersil/p54/main.c
index d5a3bf91a03e..ab6d39e12069 100644
--- a/drivers/net/wireless/intersil/p54/main.c
+++ b/drivers/net/wireless/intersil/p54/main.c
@@ -852,12 +852,11 @@ void p54_unregister_common(struct ieee80211_hw *dev)
 {
struct p54_common *priv = dev->priv;
 
-#ifdef CONFIG_P54_LEDS
-   p54_unregister_leds(priv);
-#endif /* CONFIG_P54_LEDS */
-
if (priv->registered) {
priv->registered = false;
+#ifdef CONFIG_P54_LEDS
+   p54_unregister_leds(priv);
+#endif /* CONFIG_P54_LEDS */
ieee80211_unregister_hw(dev);
}
 
-- 
2.14.1.821.g8fa685d3b7-goog

usb/net/lan78xx: use-after-free in lan78xx_write_reg

[Andrey Konovalov]

Hi!

I've got the following report while fuzzing the kernel with syzkaller.

On commit e19b205be43d11bff638cad4487008c48d21c103 (4.14-rc2).

==
BUG: KASAN: use-after-free in lan78xx_write_reg.isra.21+0x1a8/0x1b0
Read of size 8 at addr 8800683e2c40 by task kworker/0:3/2551

CPU: 0 PID: 2551 Comm: kworker/0:3 Not tainted
4.14.0-rc2-42613-g1488251d1a98 #256
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011
Workqueue: events lan78xx_deferred_multicast_write
Call Trace:
 __dump_stack lib/dump_stack.c:16
 dump_stack+0x292/0x395 lib/dump_stack.c:52
 print_address_description+0x78/0x280 mm/kasan/report.c:252
 kasan_report_error mm/kasan/report.c:351
 kasan_report+0x23d/0x350 mm/kasan/report.c:409
 __asan_report_load8_noabort+0x19/0x20 mm/kasan/report.c:430
 lan78xx_write_reg.isra.21+0x1a8/0x1b0 drivers/net/usb/lan78xx.c:458
 lan78xx_deferred_multicast_write+0x10d/0x1a0 drivers/net/usb/lan78xx.c:1042
 process_one_work+0xc7f/0x1db0 kernel/workqueue.c:2119
 worker_thread+0x221/0x1850 kernel/workqueue.c:2253
 kthread+0x3a1/0x470 kernel/kthread.c:231
 ret_from_fork+0x2a/0x40 arch/x86/entry/entry_64.S:431

Allocated by task 24:
 save_stack_trace+0x1b/0x20 arch/x86/kernel/stacktrace.c:59
 save_stack+0x43/0xd0 mm/kasan/kasan.c:447
 set_track mm/kasan/kasan.c:459
 kasan_kmalloc+0xad/0xe0 mm/kasan/kasan.c:551
 __kmalloc_node+0x192/0x480 mm/slub.c:3827
 kmalloc_node ./include/linux/slab.h:535
 kvmalloc_node+0x69/0xd0 mm/util.c:397
 kvmalloc ./include/linux/mm.h:529
 kvzalloc ./include/linux/mm.h:537
 alloc_netdev_mqs+0x173/0xea0 net/core/dev.c:8023
 alloc_etherdev_mqs+0x38/0x40 net/ethernet/eth.c:391
 lan78xx_probe+0x13a/0x2f10 drivers/net/usb/lan78xx.c:3542
 usb_probe_interface+0x35d/0x8e0 drivers/usb/core/driver.c:361
 really_probe drivers/base/dd.c:413
 driver_probe_device+0x610/0xa00 drivers/base/dd.c:557
 __device_attach_driver+0x230/0x290 drivers/base/dd.c:653
 bus_for_each_drv+0x161/0x210 drivers/base/bus.c:463
 __device_attach+0x26e/0x3d0 drivers/base/dd.c:710
 device_initial_probe+0x1f/0x30 drivers/base/dd.c:757
 bus_probe_device+0x1eb/0x290 drivers/base/bus.c:523
 device_add+0xd0b/0x1660 drivers/base/core.c:1835
 usb_set_configuration+0x104e/0x1870 drivers/usb/core/message.c:1932
 generic_probe+0x73/0xe0 drivers/usb/core/generic.c:174
 usb_probe_device+0xaf/0xe0 drivers/usb/core/driver.c:266
 really_probe drivers/base/dd.c:413
 driver_probe_device+0x610/0xa00 drivers/base/dd.c:557
 __device_attach_driver+0x230/0x290 drivers/base/dd.c:653
 bus_for_each_drv+0x161/0x210 drivers/base/bus.c:463
 __device_attach+0x26e/0x3d0 drivers/base/dd.c:710
 device_initial_probe+0x1f/0x30 drivers/base/dd.c:757
 bus_probe_device+0x1eb/0x290 drivers/base/bus.c:523
 device_add+0xd0b/0x1660 drivers/base/core.c:1835
 usb_new_device+0x7b8/0x1020 drivers/usb/core/hub.c:2457
 hub_port_connect drivers/usb/core/hub.c:4903
 hub_port_connect_change drivers/usb/core/hub.c:5009
 port_event drivers/usb/core/hub.c:5115
 hub_event+0x194d/0x3740 drivers/usb/core/hub.c:5195
 process_one_work+0xc7f/0x1db0 kernel/workqueue.c:2119
 worker_thread+0x221/0x1850 kernel/workqueue.c:2253
 kthread+0x3a1/0x470 kernel/kthread.c:231
 ret_from_fork+0x2a/0x40 arch/x86/entry/entry_64.S:431

Freed by task 24:
 save_stack_trace+0x1b/0x20 arch/x86/kernel/stacktrace.c:59
 save_stack+0x43/0xd0 mm/kasan/kasan.c:447
 set_track mm/kasan/kasan.c:459
 kasan_slab_free+0x72/0xc0 mm/kasan/kasan.c:524
 slab_free_hook mm/slub.c:1390
 slab_free_freelist_hook mm/slub.c:1412
 slab_free mm/slub.c:2988
 kfree+0xf6/0x2f0 mm/slub.c:3919
 kvfree+0x3b/0x60 mm/util.c:416
 netdev_freemem net/core/dev.c:7975
 free_netdev+0x304/0x3c0 net/core/dev.c:8137
 lan78xx_probe+0x20cc/0x2f10 drivers/net/usb/lan78xx.c:3645
 usb_probe_interface+0x35d/0x8e0 drivers/usb/core/driver.c:361
 really_probe drivers/base/dd.c:413
 driver_probe_device+0x610/0xa00 drivers/base/dd.c:557
 __device_attach_driver+0x230/0x290 drivers/base/dd.c:653
 bus_for_each_drv+0x161/0x210 drivers/base/bus.c:463
 __device_attach+0x26e/0x3d0 drivers/base/dd.c:710
 device_initial_probe+0x1f/0x30 drivers/base/dd.c:757
 bus_probe_device+0x1eb/0x290 drivers/base/bus.c:523
 device_add+0xd0b/0x1660 drivers/base/core.c:1835
 usb_set_configuration+0x104e/0x1870 drivers/usb/core/message.c:1932
 generic_probe+0x73/0xe0 drivers/usb/core/generic.c:174
 usb_probe_device+0xaf/0xe0 drivers/usb/core/driver.c:266
 really_probe drivers/base/dd.c:413
 driver_probe_device+0x610/0xa00 drivers/base/dd.c:557
 __device_attach_driver+0x230/0x290 drivers/base/dd.c:653
 bus_for_each_drv+0x161/0x210 drivers/base/bus.c:463
 __device_attach+0x26e/0x3d0 drivers/base/dd.c:710
 device_initial_probe+0x1f/0x30 drivers/base/dd.c:757
 bus_probe_device+0x1eb/0x290 drivers/base/bus.c:523
 device_add+0xd0b/0x1660 drivers/base/core.c:1835
 usb_new_device+0x7b8/0x1020 drivers/usb/core/hub.c:2457
 hub_port_connect drivers/usb/core/hub.c:4903
 hub_port_connect_change 

Re: usb/wireless/rsi_91x: use-after-free write in __run_timers

[Andrey Konovalov]

On Mon, Sep 25, 2017 at 6:26 AM, Kalle Valo <kv...@codeaurora.org> wrote:
> Andrey Konovalov <andreyk...@google.com> writes:
>
>> I've got the following report while fuzzing the kernel with syzkaller.
>>
>> On commit 6e80ecdddf4ea6f3cd84e83720f3d852e6624a68 (Sep 21).
>>
>> ==
>> BUG: KASAN: use-after-free in __run_timers+0xc0e/0xd40
>> Write of size 8 at addr 880069f701b8 by task swapper/0/0
>>
>> CPU: 0 PID: 0 Comm: swapper/0 Not tainted 4.14.0-rc1-42311-g6e80ecdddf4e #234
>> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011
>
> [...]
>
>> Allocated by task 1845:
>>  save_stack_trace+0x1b/0x20 arch/x86/kernel/stacktrace.c:59
>>  save_stack+0x43/0xd0 mm/kasan/kasan.c:447
>>  set_track mm/kasan/kasan.c:459
>>  kasan_kmalloc+0xad/0xe0 mm/kasan/kasan.c:551
>>  kmem_cache_alloc_trace+0x11e/0x2d0 mm/slub.c:2772
>>  kmalloc ./include/linux/slab.h:493
>>  kzalloc ./include/linux/slab.h:666
>>  rsi_91x_init+0x98/0x510 drivers/net/wireless/rsi/rsi_91x_main.c:203
>>  rsi_probe+0xb6/0x13b0 drivers/net/wireless/rsi/rsi_91x_usb.c:665
>>  usb_probe_interface+0x35d/0x8e0 drivers/usb/core/driver.c:361
>
> I'm curious about your setup. Apparently you are running syzkaller on
> QEMU but what I don't understand is how the rsi device comes into the
> picture. Did you have a rsi usb device connected to the virtual machine
> or what? Or does syzkaller do some kind of magic here?

I use dummy_hcd and gadgetfs to connect random USB devices to the
kernel from a userspace application. This happens inside a QEMU
instance. This simplifies fuzzing, since everything is virtualized,
but the found bugs can be triggered on a real machine by connecting a
malicious USB device.

>
> --
> Kalle Valo
>
> --
> You received this message because you are subscribed to the Google Groups 
> "syzkaller" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to syzkaller+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

usb/wireless/rsi_91x: use-after-free write in __run_timers

[Andrey Konovalov]

Hi!

I've got the following report while fuzzing the kernel with syzkaller.

On commit 6e80ecdddf4ea6f3cd84e83720f3d852e6624a68 (Sep 21).

==
BUG: KASAN: use-after-free in __run_timers+0xc0e/0xd40
Write of size 8 at addr 880069f701b8 by task swapper/0/0

CPU: 0 PID: 0 Comm: swapper/0 Not tainted 4.14.0-rc1-42311-g6e80ecdddf4e #234
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011
Call Trace:
 
 __dump_stack lib/dump_stack.c:16
 dump_stack+0x292/0x395 lib/dump_stack.c:52
 print_address_description+0x78/0x280 mm/kasan/report.c:252
 kasan_report_error mm/kasan/report.c:351
 kasan_report+0x22f/0x340 mm/kasan/report.c:409
 __asan_report_store8_noabort+0x1c/0x20 mm/kasan/report.c:435
 collect_expired_timers ./include/linux/list.h:729
 __run_timers+0xc0e/0xd40 kernel/time/timer.c:1616
 run_timer_softirq+0x83/0x140 kernel/time/timer.c:1646
 __do_softirq+0x305/0xc2d kernel/softirq.c:284
 invoke_softirq kernel/softirq.c:364
 irq_exit+0x171/0x1a0 kernel/softirq.c:405
 exiting_irq ./arch/x86/include/asm/apic.h:638
 smp_apic_timer_interrupt+0x2b9/0x8d0 arch/x86/kernel/apic/apic.c:1048
 apic_timer_interrupt+0x9d/0xb0
 
RIP: 0010:native_safe_halt+0x6/0x10 ./arch/x86/include/asm/irqflags.h:53
RSP: 0018:86607958 EFLAGS: 0282 ORIG_RAX: ff10
RAX: dc20 RBX: 10cc0f2f RCX: 
RDX:  RSI: 0001 RDI: 8662ea64
RBP: 86607958 R08: 813d3501 R09: 
R10:  R11:  R12: 10cc0f3b
R13: 86607a98 R14: 86fc1628 R15: 
 arch_safe_halt ./arch/x86/include/asm/paravirt.h:93
 default_idle+0x127/0x690 arch/x86/kernel/process.c:341
 arch_cpu_idle+0xf/0x20 arch/x86/kernel/process.c:332
 default_idle_call+0x3b/0x60 kernel/sched/idle.c:98
 cpuidle_idle_call kernel/sched/idle.c:156
 do_idle+0x35c/0x440 kernel/sched/idle.c:246
 cpu_startup_entry+0x1d/0x20 kernel/sched/idle.c:351
 rest_init+0xf3/0x100 init/main.c:435
 start_kernel+0x782/0x7b0 init/main.c:710
 x86_64_start_reservations+0x2a/0x2c arch/x86/kernel/head64.c:377
 x86_64_start_kernel+0x77/0x7a arch/x86/kernel/head64.c:358
 secondary_startup_64+0xa5/0xa5 arch/x86/kernel/head_64.S:235

Allocated by task 1845:
 save_stack_trace+0x1b/0x20 arch/x86/kernel/stacktrace.c:59
 save_stack+0x43/0xd0 mm/kasan/kasan.c:447
 set_track mm/kasan/kasan.c:459
 kasan_kmalloc+0xad/0xe0 mm/kasan/kasan.c:551
 kmem_cache_alloc_trace+0x11e/0x2d0 mm/slub.c:2772
 kmalloc ./include/linux/slab.h:493
 kzalloc ./include/linux/slab.h:666
 rsi_91x_init+0x98/0x510 drivers/net/wireless/rsi/rsi_91x_main.c:203
 rsi_probe+0xb6/0x13b0 drivers/net/wireless/rsi/rsi_91x_usb.c:665
 usb_probe_interface+0x35d/0x8e0 drivers/usb/core/driver.c:361
 really_probe drivers/base/dd.c:413
 driver_probe_device+0x610/0xa00 drivers/base/dd.c:557
 __device_attach_driver+0x230/0x290 drivers/base/dd.c:653
 bus_for_each_drv+0x161/0x210 drivers/base/bus.c:463
 __device_attach+0x26e/0x3d0 drivers/base/dd.c:710
 device_initial_probe+0x1f/0x30 drivers/base/dd.c:757
 bus_probe_device+0x1eb/0x290 drivers/base/bus.c:523
 device_add+0xd0b/0x1660 drivers/base/core.c:1835
 usb_set_configuration+0x104e/0x1870 drivers/usb/core/message.c:1932
 generic_probe+0x73/0xe0 drivers/usb/core/generic.c:174
 usb_probe_device+0xaf/0xe0 drivers/usb/core/driver.c:266
 really_probe drivers/base/dd.c:413
 driver_probe_device+0x610/0xa00 drivers/base/dd.c:557
 __device_attach_driver+0x230/0x290 drivers/base/dd.c:653
 bus_for_each_drv+0x161/0x210 drivers/base/bus.c:463
 __device_attach+0x26e/0x3d0 drivers/base/dd.c:710
 device_initial_probe+0x1f/0x30 drivers/base/dd.c:757
 bus_probe_device+0x1eb/0x290 drivers/base/bus.c:523
 device_add+0xd0b/0x1660 drivers/base/core.c:1835
 usb_new_device+0x7b8/0x1020 drivers/usb/core/hub.c:2457
 hub_port_connect drivers/usb/core/hub.c:4903
 hub_port_connect_change drivers/usb/core/hub.c:5009
 port_event drivers/usb/core/hub.c:5115
 hub_event+0x194d/0x3740 drivers/usb/core/hub.c:5195
 process_one_work+0xc7f/0x1db0 kernel/workqueue.c:2119
 worker_thread+0x221/0x1850 kernel/workqueue.c:2253
 kthread+0x3a1/0x470 kernel/kthread.c:231
 ret_from_fork+0x2a/0x40 arch/x86/entry/entry_64.S:431

Freed by task 1845:
 save_stack_trace+0x1b/0x20 arch/x86/kernel/stacktrace.c:59
 save_stack+0x43/0xd0 mm/kasan/kasan.c:447
 set_track mm/kasan/kasan.c:459
 kasan_slab_free+0x72/0xc0 mm/kasan/kasan.c:524
 slab_free_hook mm/slub.c:1390
 slab_free_freelist_hook mm/slub.c:1412
 slab_free mm/slub.c:2988
 kfree+0xf6/0x2f0 mm/slub.c:3919
 rsi_91x_deinit+0x1e8/0x250 drivers/net/wireless/rsi/rsi_91x_main.c:268
 rsi_probe+0xed1/0x13b0 drivers/net/wireless/rsi/rsi_91x_usb.c:709
 usb_probe_interface+0x35d/0x8e0 drivers/usb/core/driver.c:361
 really_probe drivers/base/dd.c:413
 driver_probe_device+0x610/0xa00 drivers/base/dd.c:557
 __device_attach_driver+0x230/0x290 drivers/base/dd.c:653
 

Re: usb/net/p54: trying to register non-static key in p54_unregister_leds

[Andrey Konovalov]

On Wed, Sep 20, 2017 at 9:55 PM, Johannes Berg
 wrote:
> On Wed, 2017-09-20 at 21:27 +0200, Christian Lamparter wrote:
>
>> It seems this is caused as a result of:
>> -> lock_map_acquire(>lockdep_map);
>>   lock_map_release(>lockdep_map);
>>
>> in flush_work() [0]
>
> Agree.
>
>> This was added by:
>>
>>   commit 0976dfc1d0cd80a4e9dfaf87bd8744612bde475a
>>   Author: Stephen Boyd 
>>   Date:   Fri Apr 20 17:28:50 2012 -0700
>>
>>   workqueue: Catch more locking problems with flush_work()
>
> Yes, but that doesn't matter.
>
>> Looking at the Stephen's patch, it's clear that it was made
>> with "static DECLARE_WORK(work, my_work)" in mind. However
>> p54's led_work is "per-device", hence it is stored in the
>> devices context p54_common, which is dynamically allocated.
>> So, maybe revert Stephen's patch?
>
> I disagree - as the lockdep warning says:
>
>> > INFO: trying to register non-static key.
>> > the code is fine but needs lockdep annotation.
>> > turning off the locking correctness validator.
>
> What it needs is to actually correctly go through initializing the work
> at least once.
>
> Without more information, I can't really say what's going on, but I
> assume that something is failing and p54_unregister_leds() is getting
> invoked without p54_init_leds() having been invoked, so essentially
> it's trying to flush a work that was never initialized?
>
> INIT_DELAYED_WORK() does, after all, initialize the lockdep map
> properly via __INIT_WORK().

Since I'm able to reproduce this, please let me know if you need me to
collect some debug traces to help with the triage.

Thanks!

>
> johannes
>
> --
> You received this message because you are subscribed to the Google Groups 
> "syzkaller" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to syzkaller+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

usb/net/hso: global-out-of-bounds in hso_probe

[Andrey Konovalov]

Hi!

I've got the following report while fuzzing the kernel with syzkaller.

On commit ebb2c2437d8008d46796902ff390653822af6cc4 (Sep 18).

Is seems there's no check on the if_num value when it's used in ((u32
*)(id->driver_info))[if_num].

==
BUG: KASAN: global-out-of-bounds in hso_probe+0x1379/0x1b70
Read of size 4 at addr 85c582f8 by task kworker/1:2/1846

CPU: 1 PID: 1846 Comm: kworker/1:2 Not tainted
4.14.0-rc1-42251-gebb2c2437d80 #215
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011
Workqueue: usb_hub_wq hub_event
Call Trace:
 __dump_stack lib/dump_stack.c:16
 dump_stack+0x292/0x395 lib/dump_stack.c:52
 print_address_description+0x1d9/0x280 mm/kasan/report.c:252
 kasan_report_error mm/kasan/report.c:351
 kasan_report+0x22f/0x340 mm/kasan/report.c:409
 __asan_report_load4_noabort+0x19/0x20 mm/kasan/report.c:429
 hso_probe+0x1379/0x1b70 drivers/net/usb/hso.c:2880
 usb_probe_interface+0x35d/0x8e0 drivers/usb/core/driver.c:361
 really_probe drivers/base/dd.c:413
 driver_probe_device+0x610/0xa00 drivers/base/dd.c:557
 __device_attach_driver+0x230/0x290 drivers/base/dd.c:653
 bus_for_each_drv+0x161/0x210 drivers/base/bus.c:463
 __device_attach+0x26e/0x3d0 drivers/base/dd.c:710
 device_initial_probe+0x1f/0x30 drivers/base/dd.c:757
 bus_probe_device+0x1eb/0x290 drivers/base/bus.c:523
 device_add+0xd0b/0x1660 drivers/base/core.c:1835
 usb_set_configuration+0x104e/0x1870 drivers/usb/core/message.c:1932
 generic_probe+0x73/0xe0 drivers/usb/core/generic.c:174
 usb_probe_device+0xaf/0xe0 drivers/usb/core/driver.c:266
 really_probe drivers/base/dd.c:413
 driver_probe_device+0x610/0xa00 drivers/base/dd.c:557
 __device_attach_driver+0x230/0x290 drivers/base/dd.c:653
 bus_for_each_drv+0x161/0x210 drivers/base/bus.c:463
 __device_attach+0x26e/0x3d0 drivers/base/dd.c:710
 device_initial_probe+0x1f/0x30 drivers/base/dd.c:757
 bus_probe_device+0x1eb/0x290 drivers/base/bus.c:523
 device_add+0xd0b/0x1660 drivers/base/core.c:1835
 usb_new_device+0x7b8/0x1020 drivers/usb/core/hub.c:2457
 hub_port_connect drivers/usb/core/hub.c:4903
 hub_port_connect_change drivers/usb/core/hub.c:5009
 port_event drivers/usb/core/hub.c:5115
 hub_event+0x194d/0x3740 drivers/usb/core/hub.c:5195
 process_one_work+0xc7f/0x1db0 kernel/workqueue.c:2119
 worker_thread+0x221/0x1850 kernel/workqueue.c:2253
 kthread+0x3a1/0x470 kernel/kthread.c:231
 ret_from_fork+0x2a/0x40 arch/x86/entry/entry_64.S:431

The buggy address belongs to the variable:
 driver_name+0xb8/0xee0

Memory state around the buggy address:
 85c58180: 00 00 04 fa fa fa fa fa 00 00 fa fa fa fa fa fa
 85c58200: 06 fa fa fa fa fa fa fa 04 fa fa fa fa fa fa fa
>85c58280: 00 fa fa fa fa fa fa fa 06 fa fa fa fa fa fa fa
^
 85c58300: 00 02 fa fa fa fa fa fa 00 00 00 00 00 07 fa fa
 85c58380: fa fa fa fa 00 07 fa fa fa fa fa fa 00 00 00 06
==

usb/net/hso: warning in hso_free_net_device

[Andrey Konovalov]

Hi!

I've got the following report while fuzzing the kernel with syzkaller.

On commit ebb2c2437d8008d46796902ff390653822af6cc4 (Sep 18).

Looks like hso_create_net_device() can do goto exit before registering
network device.

hso 1-1:4.0: Can't find BULK IN endpoint
[ cut here ]
WARNING: CPU: 0 PID: 24 at net/core/dev.c:7117
rollback_registered_many+0x235/0xd90
Modules linked in:
CPU: 0 PID: 24 Comm: kworker/0:1 Not tainted 4.14.0-rc1-42251-gebb2c2437d80 #215
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011
Workqueue: usb_hub_wq hub_event
task: 88006befe300 task.stack: 88006bf8
RIP: 0010:rollback_registered_many+0x235/0xd90 net/core/dev.c:7117
RSP: 0018:88006bf86058 EFLAGS: 00010297
RAX: 88006befe300 RBX:  RCX: 11000d40644e
RDX:  RSI:  RDI: 88006a032778
RBP: 88006bf86210 R08: 88006befe300 R09: 849e79cc
R10: 88006bf86450 R11: 11000d7dfefb R12: 88006a032200
R13: 88006a032270 R14: 88006bf86258 R15: dc00
FS:  () GS:88006c80() knlGS:
CS:  0010 DS:  ES:  CR0: 80050033
CR2: 7f1c4eebb000 CR3: 69b63000 CR4: 06f0
Call Trace:
 rollback_registered+0x1ac/0x3c0 net/core/dev.c:7192
 unregister_netdevice_queue+0x2f3/0x580 net/core/dev.c:8180
 unregister_netdevice ./include/linux/netdevice.h:2427
 unregister_netdev+0x21/0x30 net/core/dev.c:8221
 hso_free_net_device+0xf2/0x2e0 drivers/net/usb/hso.c:2379
 hso_create_net_device+0x3f9/0x9d0 drivers/net/usb/hso.c:2567
 hso_probe+0xaa7/0x1b70 drivers/net/usb/hso.c:2896
 usb_probe_interface+0x35d/0x8e0 drivers/usb/core/driver.c:361
 really_probe drivers/base/dd.c:413
 driver_probe_device+0x610/0xa00 drivers/base/dd.c:557
 __device_attach_driver+0x230/0x290 drivers/base/dd.c:653
 bus_for_each_drv+0x161/0x210 drivers/base/bus.c:463
 __device_attach+0x26e/0x3d0 drivers/base/dd.c:710
 device_initial_probe+0x1f/0x30 drivers/base/dd.c:757
 bus_probe_device+0x1eb/0x290 drivers/base/bus.c:523
 device_add+0xd0b/0x1660 drivers/base/core.c:1835
 usb_set_configuration+0x104e/0x1870 drivers/usb/core/message.c:1932
 generic_probe+0x73/0xe0 drivers/usb/core/generic.c:174
 usb_probe_device+0xaf/0xe0 drivers/usb/core/driver.c:266
 really_probe drivers/base/dd.c:413
 driver_probe_device+0x610/0xa00 drivers/base/dd.c:557
 __device_attach_driver+0x230/0x290 drivers/base/dd.c:653
 bus_for_each_drv+0x161/0x210 drivers/base/bus.c:463
 __device_attach+0x26e/0x3d0 drivers/base/dd.c:710
 device_initial_probe+0x1f/0x30 drivers/base/dd.c:757
 bus_probe_device+0x1eb/0x290 drivers/base/bus.c:523
 device_add+0xd0b/0x1660 drivers/base/core.c:1835
 usb_new_device+0x7b8/0x1020 drivers/usb/core/hub.c:2457
 hub_port_connect drivers/usb/core/hub.c:4903
 hub_port_connect_change drivers/usb/core/hub.c:5009
 port_event drivers/usb/core/hub.c:5115
 hub_event+0x194d/0x3740 drivers/usb/core/hub.c:5195
 process_one_work+0xc7f/0x1db0 kernel/workqueue.c:2119
 worker_thread+0x221/0x1850 kernel/workqueue.c:2253
 kthread+0x3a1/0x470 kernel/kthread.c:231
 ret_from_fork+0x2a/0x40 arch/x86/entry/entry_64.S:431
Code: 48 c1 e8 03 42 0f b6 04 38 84 c0 74 08 84 c0 0f 8e e7 09 00 00
41 0f b6 9c 24 78 05 00 00 84 db 0f 85 57 ff ff ff e8 0b 92 b0 fc <0f>
ff 4c 89 ef e8 21 15 b7 fd 84 c0 0f 84 e1 00 00 00 e8 f4 91
---[ end trace 94e5147be32b2d45 ]---

usb/net/p54: trying to register non-static key in p54_unregister_leds

[Andrey Konovalov]

Hi!

I've got the following report while fuzzing the kernel with syzkaller.

On commit ebb2c2437d8008d46796902ff390653822af6cc4 (Sep 18).

INFO: trying to register non-static key.
the code is fine but needs lockdep annotation.
turning off the locking correctness validator.
CPU: 1 PID: 1404 Comm: kworker/1:1 Not tainted
4.14.0-rc1-42251-gebb2c2437d80-dirty #205
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011
Workqueue: usb_hub_wq hub_event
Call Trace:
 __dump_stack lib/dump_stack.c:16
 dump_stack+0x292/0x395 lib/dump_stack.c:52
 register_lock_class+0x6c4/0x1a00 kernel/locking/lockdep.c:769
 __lock_acquire+0x27e/0x4550 kernel/locking/lockdep.c:3385
 lock_acquire+0x259/0x620 kernel/locking/lockdep.c:4002
 flush_work+0xf0/0x8c0 kernel/workqueue.c:2886
 __cancel_work_timer+0x51d/0x870 kernel/workqueue.c:2961
 cancel_delayed_work_sync+0x1f/0x30 kernel/workqueue.c:3081
 p54_unregister_leds+0x6c/0xc0 drivers/net/wireless/intersil/p54/led.c:160
 p54_unregister_common+0x3d/0xb0 drivers/net/wireless/intersil/p54/main.c:856
 p54u_disconnect+0x86/0x120 drivers/net/wireless/intersil/p54/p54usb.c:1073
 usb_unbind_interface+0x21c/0xa90 drivers/usb/core/driver.c:423
 __device_release_driver drivers/base/dd.c:861
 device_release_driver_internal+0x4f4/0x5c0 drivers/base/dd.c:893
 device_release_driver+0x1e/0x30 drivers/base/dd.c:918
 bus_remove_device+0x2f4/0x4b0 drivers/base/bus.c:565
 device_del+0x5c4/0xab0 drivers/base/core.c:1985
 usb_disable_device+0x1e9/0x680 drivers/usb/core/message.c:1170
 usb_disconnect+0x260/0x7a0 drivers/usb/core/hub.c:2124
 hub_port_connect drivers/usb/core/hub.c:4754
 hub_port_connect_change drivers/usb/core/hub.c:5009
 port_event drivers/usb/core/hub.c:5115
 hub_event+0x1318/0x3740 drivers/usb/core/hub.c:5195
 process_one_work+0xc7f/0x1db0 kernel/workqueue.c:2119
 process_scheduled_works kernel/workqueue.c:2179
 worker_thread+0xb2b/0x1850 kernel/workqueue.c:2255
 kthread+0x3a1/0x470 kernel/kthread.c:231
 ret_from_fork+0x2a/0x40 arch/x86/entry/entry_64.S:431

Re: [Patch net] sit: use __GFP_NOWARN for user controlled allocation

[Andrey Konovalov]

On Fri, Jun 23, 2017 at 2:21 PM, Andrey Konovalov <andreyk...@google.com> wrote:
> On Fri, Jun 23, 2017 at 12:29 AM, Cong Wang <xiyou.wangc...@gmail.com> wrote:
>> The memory allocation size is controlled by user-space,
>> if it is too large just fail silently and return NULL,
>> not to mention there is a fallback allocation later.
>
> Thanks!
>
> Tested-by: Andrey Konovalov 

Should be:
Tested-by: Andrey Konovalov <andreyk...@google.com>

>
>>
>> Reported-by: Andrey Konovalov <andreyk...@google.com>
>> Cc: Andrey Konovalov <andreyk...@google.com>
>> Signed-off-by: Cong Wang <xiyou.wangc...@gmail.com>
>> ---
>>  net/ipv6/sit.c | 2 +-
>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/net/ipv6/sit.c b/net/ipv6/sit.c
>> index 2378503..f8ad158 100644
>> --- a/net/ipv6/sit.c
>> +++ b/net/ipv6/sit.c
>> @@ -305,7 +305,7 @@ static int ipip6_tunnel_get_prl(struct ip_tunnel *t,
>>  * we try harder to allocate.
>>  */
>> kp = (cmax <= 1 || capable(CAP_NET_ADMIN)) ?
>> -   kcalloc(cmax, sizeof(*kp), GFP_KERNEL) :
>> +   kcalloc(cmax, sizeof(*kp), GFP_KERNEL | __GFP_NOWARN) :
>> NULL;
>>
>> rcu_read_lock();
>> --
>> 2.5.5
>>

Re: [Patch net] sit: use __GFP_NOWARN for user controlled allocation

[Andrey Konovalov]

On Fri, Jun 23, 2017 at 12:29 AM, Cong Wang <xiyou.wangc...@gmail.com> wrote:
> The memory allocation size is controlled by user-space,
> if it is too large just fail silently and return NULL,
> not to mention there is a fallback allocation later.

Thanks!

Tested-by: Andrey Konovalov 

>
> Reported-by: Andrey Konovalov <andreyk...@google.com>
> Cc: Andrey Konovalov <andreyk...@google.com>
> Signed-off-by: Cong Wang <xiyou.wangc...@gmail.com>
> ---
>  net/ipv6/sit.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/net/ipv6/sit.c b/net/ipv6/sit.c
> index 2378503..f8ad158 100644
> --- a/net/ipv6/sit.c
> +++ b/net/ipv6/sit.c
> @@ -305,7 +305,7 @@ static int ipip6_tunnel_get_prl(struct ip_tunnel *t,
>  * we try harder to allocate.
>  */
> kp = (cmax <= 1 || capable(CAP_NET_ADMIN)) ?
> -   kcalloc(cmax, sizeof(*kp), GFP_KERNEL) :
> +   kcalloc(cmax, sizeof(*kp), GFP_KERNEL | __GFP_NOWARN) :
> NULL;
>
> rcu_read_lock();
> --
> 2.5.5
>

Re: [Patch net] ipv6: avoid unregistering inet6_dev for loopback

[Andrey Konovalov]

On Wed, Jun 21, 2017 at 11:34 PM, Cong Wang <xiyou.wangc...@gmail.com> wrote:
> The per netns loopback_dev->ip6_ptr is unregistered and set to
> NULL when its mtu is set to smaller than IPV6_MIN_MTU, this
> leads to that we could set rt->rt6i_idev NULL after a
> rt6_uncached_list_flush_dev() and then crash after another
> call.
>
> In this case we should just bring its inet6_dev down, rather
> than unregistering it, at least prior to commit 176c39af29bc
> ("netns: fix addrconf_ifdown kernel panic") we always
> override the case for loopback.
>
> Thanks a lot to Andrey for finding a reliable reproducer.

Thanks! This fixes the bug for me.

Tested-by: Andrey Konovalov <andreyk...@google.com>

>
> Fixes: 176c39af29bc ("netns: fix addrconf_ifdown kernel panic")
> Reported-by: Andrey Konovalov <andreyk...@google.com>
> Cc: Andrey Konovalov <andreyk...@google.com>
> Cc: Daniel Lezcano <dlezc...@fr.ibm.com>
> Cc: David Ahern <dsah...@gmail.com>
> Signed-off-by: Cong Wang <xiyou.wangc...@gmail.com>
> ---
>  net/ipv6/addrconf.c | 5 +++--
>  1 file changed, 3 insertions(+), 2 deletions(-)
>
> diff --git a/net/ipv6/addrconf.c b/net/ipv6/addrconf.c
> index 686c923..1d2dbac 100644
> --- a/net/ipv6/addrconf.c
> +++ b/net/ipv6/addrconf.c
> @@ -3369,6 +3369,7 @@ static int addrconf_notify(struct notifier_block *this, 
> unsigned long event,
> struct net_device *dev = netdev_notifier_info_to_dev(ptr);
> struct netdev_notifier_changeupper_info *info;
> struct inet6_dev *idev = __in6_dev_get(dev);
> +   struct net *net = dev_net(dev);
> int run_pending = 0;
> int err;
>
> @@ -3384,7 +3385,7 @@ static int addrconf_notify(struct notifier_block *this, 
> unsigned long event,
> case NETDEV_CHANGEMTU:
> /* if MTU under IPV6_MIN_MTU stop IPv6 on this interface. */
> if (dev->mtu < IPV6_MIN_MTU) {
> -   addrconf_ifdown(dev, 1);
> +   addrconf_ifdown(dev, dev != net->loopback_dev);
> break;
> }
>
> @@ -3500,7 +3501,7 @@ static int addrconf_notify(struct notifier_block *this, 
> unsigned long event,
>  * IPV6_MIN_MTU stop IPv6 on this interface.
>  */
> if (dev->mtu < IPV6_MIN_MTU)
> -   addrconf_ifdown(dev, 1);
> +   addrconf_ifdown(dev, dev != 
> net->loopback_dev);
> }
> break;
>
> --
> 2.5.5
>

Re: net/ipv6: GPF in rt6_ifdown

[Andrey Konovalov]

On Wed, Jun 21, 2017 at 3:09 PM, Andrey Konovalov <andreyk...@google.com> wrote:
> On Wed, Jun 21, 2017 at 2:08 PM, Andrey Konovalov <andreyk...@google.com> 
> wrote:
>> Hi,
>>
>> I've got the following error report while fuzzing the kernel with syzkaller.
>>
>> On commit 9705596d08ac87c18aee32cc97f2783b7d14624e (4.12-rc6+).
>>
>> It might be related to:
>> https://groups.google.com/forum/#!topic/syzkaller/ZJaqAiFLe3k
>>
>> I only have a reproducer in the form of a syzkaller program, attached
>> together with my .config.
>
> I now have a C reproducer as well, attached.

And here's a much simpler reproducer.

>
>>
>> It can be executed as described here:
>> https://github.com/google/syzkaller/blob/master/docs/executing_syzkaller_programs.md
>>
>> With the following flags:
>> ./syz-execprog -repeat=0 -procs=8 -sandbox=namespace ./log
>>
>> Since I'm able to reproduce it, I can apply debug patches and test
>> with them if required.
>>
>> kasan: CONFIG_KASAN_INLINE enabled
>> kasan: GPF could be caused by NULL-ptr deref or user memory access
>> general protection fault:  [#1] SMP KASAN
>> Modules linked in:
>> CPU: 1 PID: 4499 Comm: syz-executor Not tainted 4.12.0-rc6+ #10
>> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011
>> task: 880068e88000 task.stack: 88005e0a
>> RIP: 0010:rt6_uncached_list_flush_dev net/ipv6/route.c:167
>> RIP: 0010:rt6_ifdown+0x3d4/0x910 net/ipv6/route.c:2824
>> RSP: 0018:88005e0a6e38 EFLAGS: 00010246
>> RAX:  RBX:  RCX: c900029a2000
>> RDX: 2dce RSI: 83ea9ee8 RDI: 88006ca25444
>> RBP: 88005e0a6f98 R08: 0001 R09: c9811a8e
>> R10: 880068e88810 R11: dc00 R12: 88005e0ad518
>> R13: 88005e0ad500 R14: 88006200b300 R15: dc00
>> FS:  7f4ccaad9700() GS:88006cb0() knlGS:
>> CS:  0010 DS:  ES:  CR0: 80050033
>> CR2: 2000f000 CR3: 672e8000 CR4: 06e0
>> Call Trace:
>>  addrconf_ifdown+0x1a8/0x1a30 net/ipv6/addrconf.c:3588
>>  addrconf_notify+0x1cf/0x2630 net/ipv6/addrconf.c:3512
>>  notifier_call_chain+0x14a/0x2e0 kernel/notifier.c:93
>>  __raw_notifier_call_chain kernel/notifier.c:394
>>  raw_notifier_call_chain+0x32/0x40 kernel/notifier.c:401
>>  call_netdevice_notifiers_info+0x56/0x90 net/core/dev.c:1650
>>  call_netdevice_notifiers net/core/dev.c:1666
>>  __dev_notify_flags+0x202/0x330 net/core/dev.c:6647
>>  dev_change_flags+0xfa/0x150 net/core/dev.c:6678
>>  dev_ifsioc+0x62f/0x9f0 net/core/dev_ioctl.c:254
>>  dev_ioctl+0x24e/0x1160 net/core/dev_ioctl.c:532
>>  sock_do_ioctl+0x99/0xb0 net/socket.c:913
>>  sock_ioctl+0x294/0x440 net/socket.c:1004
>>  vfs_ioctl fs/ioctl.c:45
>>  do_vfs_ioctl+0x1c4/0x1660 fs/ioctl.c:685
>>  SYSC_ioctl fs/ioctl.c:700
>>  SyS_ioctl+0x94/0xc0 fs/ioctl.c:691
>>  entry_SYSCALL_64_fastpath+0x1f/0xbe arch/x86/entry/entry_64.S:203
>> RIP: 0033:0x446349
>> RSP: 002b:7f4ccaad8c08 EFLAGS: 0282 ORIG_RAX: 0010
>> RAX: ffda RBX: 3210 RCX: 00446349
>> RDX: 208befe0 RSI: 8914 RDI: 0018
>> RBP:  R08:  R09: 
>> R10:  R11: 0282 R12: 0018
>> R13: 3210 R14: 006e42d0 R15: 8914
>> Code: 49 8b 9d 58 01 00 00 4c 89 e0 48 c1 e8 03 42 80 3c 38 00 0f 85
>> 6d 04 00 00 49 8b 45 18 48 89 85 f0 fe ff ff 48 89 d8 48 c1 e8 03 <42>
>> 80 3c 38 00 0f 85 5d 04 00 00 4c 3b 33 0f 84 d7 01 00 00 e8
>> RIP: rt6_ifdown+0x3d4/0x910 RSP: 88005e0a6e38
>> ---[ end trace f2e889448df70bb4 ]---
>> Kernel panic - not syncing: Fatal exception in interrupt
>> Kernel Offset: disabled
>> ---[ end Kernel panic - not syncing: Fatal exception in interrupt
// autogenerated by syzkaller (http://github.com/google/syzkaller)

#ifndef __NR_sendmmsg
#define __NR_sendmmsg 307
#endif
#ifndef __NR_mmap
#define __NR_mmap 9
#endif
#ifndef __NR_socket
#define __NR_socket 41
#endif
#ifndef __NR_ioctl
#define __NR_ioctl 16
#endif
#ifndef __NR_connect
#define __NR_connect 42
#endif

#define _GNU_SOURCE

#include 
#include 
#include 
#include 

static void test();

void loop()
{
  while (1) {
test();
  }
}

long r[81];
void test()
{
  memset(r, -1, sizeof(r));
  r[0] = syscall(__NR_mmap, 0x2000ul, 0xfff000ul, 0x3ul, 0x32ul,
 0xul, 0x0ul);
  r[1] = syscall(__NR_socket, 0xaul, 0x

Re: net/ipv6: GPF in rt6_ifdown

[Andrey Konovalov]

On Wed, Jun 21, 2017 at 2:08 PM, Andrey Konovalov <andreyk...@google.com> wrote:
> Hi,
>
> I've got the following error report while fuzzing the kernel with syzkaller.
>
> On commit 9705596d08ac87c18aee32cc97f2783b7d14624e (4.12-rc6+).
>
> It might be related to:
> https://groups.google.com/forum/#!topic/syzkaller/ZJaqAiFLe3k
>
> I only have a reproducer in the form of a syzkaller program, attached
> together with my .config.

I now have a C reproducer as well, attached.

>
> It can be executed as described here:
> https://github.com/google/syzkaller/blob/master/docs/executing_syzkaller_programs.md
>
> With the following flags:
> ./syz-execprog -repeat=0 -procs=8 -sandbox=namespace ./log
>
> Since I'm able to reproduce it, I can apply debug patches and test
> with them if required.
>
> kasan: CONFIG_KASAN_INLINE enabled
> kasan: GPF could be caused by NULL-ptr deref or user memory access
> general protection fault:  [#1] SMP KASAN
> Modules linked in:
> CPU: 1 PID: 4499 Comm: syz-executor Not tainted 4.12.0-rc6+ #10
> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011
> task: 880068e88000 task.stack: 88005e0a
> RIP: 0010:rt6_uncached_list_flush_dev net/ipv6/route.c:167
> RIP: 0010:rt6_ifdown+0x3d4/0x910 net/ipv6/route.c:2824
> RSP: 0018:88005e0a6e38 EFLAGS: 00010246
> RAX:  RBX:  RCX: c900029a2000
> RDX: 2dce RSI: 83ea9ee8 RDI: 88006ca25444
> RBP: 88005e0a6f98 R08: 0001 R09: c9811a8e
> R10: 880068e88810 R11: dc00 R12: 88005e0ad518
> R13: 88005e0ad500 R14: 88006200b300 R15: dc00
> FS:  7f4ccaad9700() GS:88006cb0() knlGS:
> CS:  0010 DS:  ES:  CR0: 80050033
> CR2: 2000f000 CR3: 672e8000 CR4: 06e0
> Call Trace:
>  addrconf_ifdown+0x1a8/0x1a30 net/ipv6/addrconf.c:3588
>  addrconf_notify+0x1cf/0x2630 net/ipv6/addrconf.c:3512
>  notifier_call_chain+0x14a/0x2e0 kernel/notifier.c:93
>  __raw_notifier_call_chain kernel/notifier.c:394
>  raw_notifier_call_chain+0x32/0x40 kernel/notifier.c:401
>  call_netdevice_notifiers_info+0x56/0x90 net/core/dev.c:1650
>  call_netdevice_notifiers net/core/dev.c:1666
>  __dev_notify_flags+0x202/0x330 net/core/dev.c:6647
>  dev_change_flags+0xfa/0x150 net/core/dev.c:6678
>  dev_ifsioc+0x62f/0x9f0 net/core/dev_ioctl.c:254
>  dev_ioctl+0x24e/0x1160 net/core/dev_ioctl.c:532
>  sock_do_ioctl+0x99/0xb0 net/socket.c:913
>  sock_ioctl+0x294/0x440 net/socket.c:1004
>  vfs_ioctl fs/ioctl.c:45
>  do_vfs_ioctl+0x1c4/0x1660 fs/ioctl.c:685
>  SYSC_ioctl fs/ioctl.c:700
>  SyS_ioctl+0x94/0xc0 fs/ioctl.c:691
>  entry_SYSCALL_64_fastpath+0x1f/0xbe arch/x86/entry/entry_64.S:203
> RIP: 0033:0x446349
> RSP: 002b:7f4ccaad8c08 EFLAGS: 0282 ORIG_RAX: 0010
> RAX: ffda RBX: 3210 RCX: 00446349
> RDX: 208befe0 RSI: 8914 RDI: 0018
> RBP:  R08:  R09: 
> R10:  R11: 0282 R12: 0018
> R13: 3210 R14: 006e42d0 R15: 8914
> Code: 49 8b 9d 58 01 00 00 4c 89 e0 48 c1 e8 03 42 80 3c 38 00 0f 85
> 6d 04 00 00 49 8b 45 18 48 89 85 f0 fe ff ff 48 89 d8 48 c1 e8 03 <42>
> 80 3c 38 00 0f 85 5d 04 00 00 4c 3b 33 0f 84 d7 01 00 00 e8
> RIP: rt6_ifdown+0x3d4/0x910 RSP: 88005e0a6e38
> ---[ end trace f2e889448df70bb4 ]---
> Kernel panic - not syncing: Fatal exception in interrupt
> Kernel Offset: disabled
> ---[ end Kernel panic - not syncing: Fatal exception in interrupt
// autogenerated by syzkaller (http://github.com/google/syzkaller)

#ifndef __NR_socket
#define __NR_socket 41
#endif
#ifndef __NR_ioctl
#define __NR_ioctl 16
#endif
#ifndef __NR_syz_emit_ethernet
#define __NR_syz_emit_ethernet 106
#endif
#ifndef __NR_connect
#define __NR_connect 42
#endif
#ifndef __NR_sendmmsg
#define __NR_sendmmsg 307
#endif
#ifndef __NR_mmap
#define __NR_mmap 9
#endif

#define _GNU_SOURCE

#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 

const int kFailStatus = 67;
const int kRetryStatus = 69;

__attribute__((noreturn)) static void doexit(int status)
{
  volatile unsigned i;
  syscall(__NR_exit_group, status);
  for (i = 0;; i++) {
  }
}

__attribute__((noreturn)) static void fail(const char* msg, ...)
{
  int e = errno;
  fflush(stdout);
  va_list args;
  va_start(args, msg);
  vfprintf(stderr, msg, args);
  va_e

Re: net/can: trying to register non-static key in can_rx_register

[Andrey Konovalov]

On Thu, Jun 8, 2017 at 5:20 PM, Marc Kleine-Budde <m...@pengutronix.de> wrote:
> On 06/08/2017 05:16 PM, Andrey Konovalov wrote:
>> Hi,
>>
>> I've got the following error report while fuzzing the kernel with syzkaller.
>>
>> On commit b29794ec95c6856b316c2295904208bf11ffddd9 (4.12-rc4+).
>>
>> INFO: trying to register non-static key.
>> the code is fine but needs lockdep annotation.
>> turning off the locking correctness validator.
>
> I've posted a patch for this problem earlier today:
> https://marc.info/?l=linux-can=149691617012069=2
>
> I'll send a pull request to David soon.

Great, thanks!

>
> regards,
> Marc
>
> --
> Pengutronix e.K.  | Marc Kleine-Budde   |
> Industrial Linux Solutions| Phone: +49-231-2826-924 |
> Vertretung West/Dortmund  | Fax:   +49-5121-206917- |
> Amtsgericht Hildesheim, HRA 2686  | http://www.pengutronix.de   |
>

net/can: trying to register non-static key in can_rx_register

[Andrey Konovalov]

Hi,

I've got the following error report while fuzzing the kernel with syzkaller.

On commit b29794ec95c6856b316c2295904208bf11ffddd9 (4.12-rc4+).

INFO: trying to register non-static key.
the code is fine but needs lockdep annotation.
turning off the locking correctness validator.
CPU: 2 PID: 17404 Comm: syz-executor1 Not tainted 4.12.0-rc4+ #15
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011
Call Trace:
 __dump_stack lib/dump_stack.c:16 [inline]
 dump_stack+0x292/0x395 lib/dump_stack.c:52
 register_lock_class+0x717/0x1aa0 kernel/locking/lockdep.c:755
 __lock_acquire+0x269/0x3690 kernel/locking/lockdep.c:3255
 ? 0xa000
 lock_acquire+0x22d/0x560 kernel/locking/lockdep.c:3855
 __raw_spin_lock include/linux/spinlock_api_smp.h:142 [inline]
 _raw_spin_lock+0x2f/0x40 kernel/locking/spinlock.c:151
 spin_lock include/linux/spinlock.h:299 [inline]
 can_rx_register+0x4f3/0x700 net/can/af_can.c:483
 raw_enable_filters+0xd7/0x1e0 net/can/raw.c:192
 raw_enable_allfilters+0x8a/0x1e0 net/can/raw.c:258
 raw_bind+0x244/0x830 net/can/raw.c:435
 SYSC_bind+0x20e/0x4c0 net/socket.c:1422
 SyS_bind+0x29/0x30 net/socket.c:1408
 entry_SYSCALL_64_fastpath+0x1f/0xbe
RIP: 0033:0x446389
RSP: 002b:7fa1efda2c08 EFLAGS: 0292 ORIG_RAX: 0031
RAX: ffda RBX: 0220 RCX: 00446389
RDX: 0060 RSI: 20001fa0 RDI: 0017
RBP:  R08:  R09: 
R10:  R11: 0292 R12: 0017
R13: 3770 R14: 006e4830 R15: 00c13000

Re: general protection fault in deactivate_slab

[Andrey Konovalov]

On Tue, Jun 6, 2017 at 1:00 PM, Andrey Konovalov <andreyk...@google.com> wrote:
> On Tue, Jun 6, 2017 at 12:30 PM, Gene Blue <geneblue.m...@gmail.com> wrote:
>> Hi:
>>   I got this crash when fuzzing the kernel with syzkaller.
>>
>>   My kernel version is  4.11.0-rc1 directly download from kernel.org.
>>
>>   And this crash is reproducible. Three times in total during the period of
>> fuzzing.
>
> Hi!
>
> This has already been reported and fixed:
> https://groups.google.com/forum/#!topic/syzkaller/e3I2c8X2oWo
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=232cd35d0804cc241eb887bb8d4d9b3b9881c64a

Apparently I was wrong, this is actually a different bug, the stack
trace just looks similar. I got the same report once on 4.12-rc3 which
has "ipv6: fix out of bound writes in __ip6_append_data()".

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: 1 PID: 32220 Comm: syz-executor6 Not tainted 4.12.0-rc3+ #3
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011
task: 880037009700 task.stack: 880026ae
RIP: 0010:get_freepointer mm/slub.c:243 [inline]
RIP: 0010:deactivate_slab+0x63/0x5f0 mm/slub.c:2020
RSP: 0018:880026ae6f40 EFLAGS: 00010006
RAX:  RBX: eae09400 RCX: 
RDX: 00e906298e83888b RSI: eae09400 RDI: 88003e80cf40
RBP: 880026ae7000 R08: 880038253818 R09: 880038254018
R10: 880026ae7020 R11: 0001 R12: 
R13: 00e906298e83888b R14: 88003e80cf40 R15: 88003e80cf40
FS:  7f34fa033700() GS:88003ed0() knlGS:
CS:  0010 DS:  ES:  CR0: 80050033
CR2: 7f34fa032db8 CR3: 388b2000 CR4: 06e0
Call Trace:
 ___slab_alloc+0x4f0/0x550 mm/slub.c:2595
 __slab_alloc+0x51/0x90 mm/slub.c:2621
 slab_alloc_node mm/slub.c:2684 [inline]
 __kmalloc_node_track_caller+0x179/0x360 mm/slub.c:4303
 __kmalloc_reserve.isra.32+0x46/0xe0 net/core/skbuff.c:138
 __alloc_skb+0x15c/0x770 net/core/skbuff.c:231
 alloc_skb include/linux/skbuff.h:936 [inline]
 sock_wmalloc+0x156/0x1f0 net/core/sock.c:1879
 __ip_append_data.isra.48+0x1e43/0x2d80 net/ipv4/ip_output.c:1041
bond0: bcsf0 ether type (3) is different from other slaves (1), can
not enslave it
 ip_append_data.part.49+0xe3/0x160 net/ipv4/ip_output.c:1235
 ip_append_data+0x5f/0x80 net/ipv4/ip_output.c:1224
 udp_sendmsg+0x10ae/0x2ce0 net/ipv4/udp.c:1073
 inet_sendmsg+0x169/0x5c0 net/ipv4/af_inet.c:762
 sock_sendmsg_nosec net/socket.c:633 [inline]
 sock_sendmsg+0xcf/0x110 net/socket.c:643
 ___sys_sendmsg+0x98a/0xa90 net/socket.c:1997
bond0: bcsf0 ether type (3) is different from other slaves (1), can
not enslave it
 __sys_sendmsg+0x13d/0x320 net/socket.c:2031
sctp: [Deprecated]: syz-executor7 (pid 32255) Use of struct
sctp_assoc_value in delayed_ack socket option.
Use struct sctp_sack_info instead
 SYSC_sendmsg net/socket.c:2042 [inline]
 SyS_sendmsg+0x32/0x50 net/socket.c:2038
sctp: [Deprecated]: syz-executor7 (pid 32255) Use of struct
sctp_assoc_value in delayed_ack socket option.
Use struct sctp_sack_info instead
 entry_SYSCALL_64_fastpath+0x1f/0xbe
RIP: 0033:0x446179
RSP: 002b:7f34fa032c08 EFLAGS: 0282 ORIG_RAX: 002e
RAX: ffda RBX: 42a0 RCX: 00446179
RDX: 0800 RSI: 2076 RDI: 0005
RBP:  R08:  R09: 
R10:  R11: 0282 R12: 0005
R13:  R14: 7f34fa0339c0 R15: 7f34fa033700
Code: 3a 48 8b 84 c7 d0 00 00 00 48 89 45 88 31 c0 4d 85 e4 0f 95 c0
83 c0 0f 48 85 d2 89 45 80 0f 84 7a 05 00 00 48 63 47 20 49 89 d5 <4c>
8b 34 02 4c 89 e2 4d 85 f6 0f 84 6b 05 00 00 48 8b 4b 18 49
RIP: get_freepointer mm/slub.c:243 [inline] RSP: 880026ae6f40
RIP: deactivate_slab+0x63/0x5f0 mm/slub.c:2020 RSP: 880026ae6f40
sctp: [Deprecated]: syz-executor7 (pid 32258) Use of struct
sctp_assoc_value in delayed_ack socket option.
Use struct sctp_sack_info instead
---[ end trace 743c7af6619c952b ]---
Kernel panic - not syncing: Fatal exception
sctp: [Deprecated]: syz-executor7 (pid 32258) Use of struct
sctp_assoc_value in delayed_ack socket option.
Use struct sctp_sack_info instead
Dumping ftrace buffer:
   (ftrace buffer empty)
Kernel Offset: disabled
Rebooting in 86400 seconds..


>
> I've added a note about checking whether the bug was reported
> previously to syzkaller wiki:
> https://github.com/google/syzkaller/wiki/Reporting-kernel-bugs
>
> Thanks!
>
>>
>>
>> **
>> kasan: GPF could be caused by NULL-ptr deref or user memory access
>> general p

Re: general protection fault in deactivate_slab

[Andrey Konovalov]

On Tue, Jun 6, 2017 at 12:30 PM, Gene Blue  wrote:
> Hi:
>   I got this crash when fuzzing the kernel with syzkaller.
>
>   My kernel version is  4.11.0-rc1 directly download from kernel.org.
>
>   And this crash is reproducible. Three times in total during the period of
> fuzzing.

Hi!

This has already been reported and fixed:
https://groups.google.com/forum/#!topic/syzkaller/e3I2c8X2oWo
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=232cd35d0804cc241eb887bb8d4d9b3b9881c64a

I've added a note about checking whether the bug was reported
previously to syzkaller wiki:
https://github.com/google/syzkaller/wiki/Reporting-kernel-bugs

Thanks!

>
>
> **
> 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: 3 PID: 5291 Comm: syz-executor3 Not tainted 4.11.0-rc1 #7
> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011
> task: 88003cc82dc0 task.stack: 88003df1
> RIP: 0010:get_freepointer mm/slub.c:243 [inline]
> RIP: 0010:deactivate_slab+0xa8/0x550 mm/slub.c:2020
> RSP: 0018:88003df17250 EFLAGS: 00010002
> RAX: 0001 RBX: 88003e80ed40 RCX: 
> RDX: 88006d66d6c0 RSI:  RDI: ea0001b59a00
> RBP: 88003df17348 R08: 8000 R09: 8007
> R10: 88006d66b410 R11: 88006d669018 R12: 88003e80ed48
> R13: 2bcbe23c521cd9a5 R14: 2bcbe23c521cd9a5 R15: ea0001b59a00
> FS:  7fb559210700() GS:88006e30() knlGS:
> CS:  0010 DS:  ES:  CR0: 80050033
> CR2: 20e76fc8 CR3: 3c2c CR4: 06e0
> Call Trace:
>  ___slab_alloc+0x199/0x5d0 mm/slub.c:2595
>  __slab_alloc+0x4c/0x90 mm/slub.c:2621
>  slab_alloc_node mm/slub.c:2684 [inline]
>  __kmalloc_node_track_caller+0xa7/0x3a0 mm/slub.c:4303
>  __kmalloc_reserve.isra.37+0x41/0xe0 net/core/skbuff.c:138
>  __alloc_skb+0xf0/0x590 net/core/skbuff.c:231
>  alloc_skb include/linux/skbuff.h:933 [inline]
>  alloc_skb_with_frags+0xae/0x510 net/core/skbuff.c:4661
>  sock_alloc_send_pskb+0x5e5/0x750 net/core/sock.c:1892
>  sock_alloc_send_skb+0x32/0x40 net/core/sock.c:1909
>  __ip6_append_data.isra.43+0x2058/0x3560 net/ipv6/ip6_output.c:1462
>  ip6_append_data+0x1d1/0x310 net/ipv6/ip6_output.c:1628
>  udpv6_sendmsg+0x1339/0x2550 net/ipv6/udp.c:1264
>  inet_sendmsg+0x129/0x530 net/ipv4/af_inet.c:761
>  sock_sendmsg_nosec net/socket.c:633 [inline]
>  sock_sendmsg+0xcc/0x110 net/socket.c:643
>  SYSC_sendto+0x211/0x340 net/socket.c:1685
>  SyS_sendto+0x40/0x50 net/socket.c:1653
>  entry_SYSCALL_64_fastpath+0x1f/0xc2
> RIP: 0033:0x4458d9
> RSP: 002b:7fb55920fb58 EFLAGS: 0282 ORIG_RAX: 002c
> RAX: ffda RBX: 00708000 RCX: 004458d9
> RDX: 0746 RSI: 20e7a8ba RDI: 0006
> RBP: 0046 R08: 20e78000 R09: 001c
> R10: 8800 R11: 0282 R12: 006df570
> R13: 0006 R14: 0005 R15: 
> Code: 8b 57 10 49 8b 4f 18 49 89 54 35 00 48 89 4c 24 68 66 83 6c 24 68 01
> 80 7c 24 6b 00 78 c6 0f 0b 48 63 73 20 49 8b 57 10 4d 89 f5 <49> 8b 3c 36 48
> 85 ff 74 05 49 89 fe eb ca 4c 8b 5c 24 48 4d 8d
> RIP: get_freepointer mm/slub.c:243 [inline] RSP: 88003df17250
> RIP: deactivate_slab+0xa8/0x550 mm/slub.c:2020 RSP: 88003df17250
> ---[ end trace d549158f7aadbc1f ]---
> Kernel panic - not syncing: Fatal exception
> [ cut here ]
> WARNING: CPU: 2 PID: 5279 at arch/x86/kernel/smp.c:127
> native_smp_send_reschedule+0x80/0xa0 arch/x86/kernel/smp.c:127
> Shutting down cpus with NMI
> Dumping ftrace buffer:
>(ftrace buffer empty)
> Kernel Offset: disabled
> Rebooting in 86400 seconds..
>

Re: net/ipv4: use-after-free in add_grec

[Andrey Konovalov]

On Thu, Jun 1, 2017 at 2:13 AM, Eric Dumazet  wrote:
> On Wed, 2017-05-31 at 16:55 -0700, Eric Dumazet wrote:
>
>> The issue here is the timer firing while ip_mc_clear_src() has been
>> already called.
>>
>> My patch should fix the problem.
>>
>> Or another one using del_timer_sync() instead of del_timer() in
>> igmp_stop_timer(), but such a change would be more invasive,
>> since the del_timer_sync() would need to happen while im->lock
>> spinlock is not held.
>
> BTW, I guess that Andrey could try to add a delay to trigger the bug
> more often.

Applied, now testing with your patch.

Thanks!

>
> diff --git a/net/ipv4/igmp.c b/net/ipv4/igmp.c
> index 
> 44fd86de2823dd17de16276a8ec01b190e69b8b4..84fff17daab0832c470a613b29b2aaade07cec0a
>  100644
> --- a/net/ipv4/igmp.c
> +++ b/net/ipv4/igmp.c
> @@ -798,7 +798,7 @@ static void igmp_timer_expire(unsigned long data)
> }
> im->reporter = 1;
> spin_unlock(>lock);
> -
> +   udelay(1);
> if (IGMP_V1_SEEN(in_dev))
> igmp_send_report(in_dev, im, IGMP_HOST_MEMBERSHIP_REPORT);
> else if (IGMP_V2_SEEN(in_dev))
>
>
> --
> You received this message because you are subscribed to the Google Groups 
> "syzkaller" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to syzkaller+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

Re: net/ipv6: use-after-free in ip6_dst_ifdown

[Andrey Konovalov]

On Thu, Jun 1, 2017 at 3:17 AM, David Ahern  wrote:
> On 5/31/17 4:49 PM, Cong Wang wrote:
> ==
> BUG: KASAN: use-after-free in ip6_dst_ifdown+0x3cc/0x400 
> net/ipv6/route.c:422
> Read of size 8 at addr 88006afa4ad8 by task syz-executor6/23554


 This one is very interesting.

 Here we are at:

 if (dev != loopback_dev) {
 if (idev && idev->dev == dev) {
 struct inet6_dev *loopback_idev =
 in6_dev_get(loopback_dev);
 if (loopback_idev) {
 rt->rt6i_idev = loopback_idev;
 in6_dev_put(idev);
 }
 }
 }

 clearly no skb involved, it looks like idev is the one used-after-free.

 But below it is actually skb which is allocated and freed...

>>>
>>> skb->head was a kmalloc(X)   with X = 1024 in this case.
>>>
>>> So it is very possible the two different objects (skb->head and idev )
>>>  were accidentally using the same slab (1024 bytes).
>>>
>>> KASAN only remember the last pair of alloc/free for a particular memory 
>>> zone.
>>
>> I see. So that memory area was freed for idev and then allocated
>> and freed again for skb->head, this happened so quick that the
>> use-after-free happened after it... Therefore we lost the track on where
>> we free the idev.
>>
>
> Andrey: can you add this to your runs? If it triggers again, we can see
> if this use-after-free is another problem where the dst hit the gc list
> and came back into the IPv6 FIB. The location of the idev entry in
> rt6_info is after the size of rtable so if this is an IPv4 dst on the
> IPv6 list it could trigger that warning.

Done, now testing with your patch.

BTW, I've also been getting the report below, which looks related.
However it's a null-ptr-deref, so much less useful info is present.
This one is being triggered much more often, I'll see if I'm able to
extract a reproducer.

kasan: CONFIG_KASAN_INLINE enabled
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: 26651 Comm: syz-executor1 Not tainted 4.12.0-rc3+ #373
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011
task: 88003bcdc480 task.stack: 880028ff
RIP: 0010:rt6_uncached_list_flush_dev net/ipv6/route.c:167 [inline]
RIP: 0010:rt6_ifdown+0x3cf/0x910 net/ipv6/route.c:2824
RSP: 0018:880028ff6e38 EFLAGS: 00010246
RAX:  RBX:  RCX: c900033c6000
RDX: 0001 RSI: 83e4d153 RDI: 88003ec25444
RBP: 880028ff6f98 R08: 0001 R09: 43743c8b
R10: 88003bcdcc90 R11: dc00 R12: 88003dc1aa98
R13: 88003dc1aa80 R14: 88003a7d R15: dc00
FS:  7fb818f8a700() GS:88003ec0() knlGS:
CS:  0010 DS:  ES:  CR0: 80050033
CR2: 00705dcc CR3: 68757000 CR4: 06f0
Call Trace:
 addrconf_ifdown+0x1a3/0x1a30 net/ipv6/addrconf.c:3588
 addrconf_notify+0x1ca/0x2630 net/ipv6/addrconf.c:3512
 notifier_call_chain+0x145/0x2e0 kernel/notifier.c:93
 __raw_notifier_call_chain kernel/notifier.c:394 [inline]
 raw_notifier_call_chain+0x2d/0x40 kernel/notifier.c:401
 call_netdevice_notifiers_info+0x51/0x90 net/core/dev.c:1649
 call_netdevice_notifiers net/core/dev.c:1665 [inline]
 __dev_notify_flags+0x1fd/0x320 net/core/dev.c:6640
 dev_change_flags+0xf5/0x140 net/core/dev.c:6671
 dev_ifsioc+0x62a/0x9f0 net/core/dev_ioctl.c:254
 dev_ioctl+0x249/0x1160 net/core/dev_ioctl.c:532
 sock_do_ioctl+0x94/0xb0 net/socket.c:913
 sock_ioctl+0x28f/0x440 net/socket.c:1004
 vfs_ioctl fs/ioctl.c:45 [inline]
 do_vfs_ioctl+0x1bf/0x1660 fs/ioctl.c:685
 SYSC_ioctl fs/ioctl.c:700 [inline]
 SyS_ioctl+0x8f/0xc0 fs/ioctl.c:691
 entry_SYSCALL_64_fastpath+0x1f/0xbe
RIP: 0033:0x446179
RSP: 002b:7fb818f89c08 EFLAGS: 0282 ORIG_RAX: 0010
RAX: ffda RBX: 3220 RCX: 00446179
RDX: 206fe000 RSI: 8914 RDI: 0005
RBP:  R08:  R09: 
R10:  R11: 0282 R12: 0005
R13:  R14: 7fb818f8a9c0 R15: 7fb818f8a700
Code: 49 8b 9d 58 01 00 00 4c 89 e0 48 c1 e8 03 42 80 3c 38 00 0f 85
6d 04 00 00 49 8b 45 18 48 89 85 f0 fe ff ff 48 89 d8 48 c1 e8 03 <42>
80 3c 38 00 0f 85 5d 04 00 00 4c 3b 33 0f 84 d7 01 00 00 e8
RIP: rt6_uncached_list_flush_dev net/ipv6/route.c:167 [inline] RSP:
880028ff6e38
RIP: rt6_ifdown+0x3cf/0x910 net/ipv6/route.c:2824 RSP: 880028ff6e38
---[ end trace 9e62f05a0ea34b53 ]---


>
> diff --git a/net/ipv6/route.c 

net/ipv4: use-after-free in add_grec

[Andrey Konovalov]

Hi,

I've got the following error report while fuzzing the kernel with syzkaller.

On commit 5ed02dbb497422bf225783f46e6eadd237d23d6b (4.12-rc3).

Unfortunately it's not reproducible.

==
BUG: KASAN: use-after-free in add_grec+0x101e/0x1090 net/ipv4/igmp.c:473
Read of size 8 at addr 88003053c1a0 by task swapper/0/0

CPU: 0 PID: 0 Comm: swapper/0 Not tainted 4.12.0-rc3+ #370
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011
Call Trace:
 
 __dump_stack lib/dump_stack.c:16 [inline]
 dump_stack+0x292/0x395 lib/dump_stack.c:52
 print_address_description+0x73/0x280 mm/kasan/report.c:252
 kasan_report_error mm/kasan/report.c:351 [inline]
 kasan_report+0x22b/0x340 mm/kasan/report.c:408
 __asan_report_load8_noabort+0x14/0x20 mm/kasan/report.c:429
 add_grec+0x101e/0x1090 net/ipv4/igmp.c:473
 igmpv3_send_cr net/ipv4/igmp.c:663 [inline]
 igmp_ifc_timer_expire+0x46d/0xa80 net/ipv4/igmp.c:768
IPVS: length: 51 != 8
 call_timer_fn+0x23f/0x800 kernel/time/timer.c:1268
 expire_timers kernel/time/timer.c:1307 [inline]
 __run_timers+0x94e/0xcd0 kernel/time/timer.c:1601
 run_timer_softirq+0x21/0x80 kernel/time/timer.c:1614
 __do_softirq+0x2fb/0xb99 kernel/softirq.c:284
 invoke_softirq kernel/softirq.c:364 [inline]
 irq_exit+0x19e/0x1d0 kernel/softirq.c:405
 exiting_irq arch/x86/include/asm/apic.h:652 [inline]
 smp_apic_timer_interrupt+0x76/0xa0 arch/x86/kernel/apic/apic.c:966
 apic_timer_interrupt+0x93/0xa0 arch/x86/entry/entry_64.S:481
RIP: 0010:native_safe_halt+0x6/0x10 arch/x86/include/asm/irqflags.h:53
RSP: 0018:85a079a8 EFLAGS: 0282 ORIG_RAX: ff10
RAX: dc20 RBX: 10b40f38 RCX: 
RDX:  RSI: 0001 RDI: 85a2a9e4
RBP: 85a079a8 R08:  R09: 
R10:  R11:  R12: dc00
R13: 85a07a60 R14: 86171338 R15: 10b40f5b
 
 arch_safe_halt arch/x86/include/asm/paravirt.h:98 [inline]
 default_idle+0x8f/0x440 arch/x86/kernel/process.c:341
 arch_cpu_idle+0xa/0x10 arch/x86/kernel/process.c:332
 default_idle_call+0x36/0x60 kernel/sched/idle.c:98
 cpuidle_idle_call kernel/sched/idle.c:156 [inline]
 do_idle+0x348/0x420 kernel/sched/idle.c:245
 cpu_startup_entry+0x18/0x20 kernel/sched/idle.c:350
 rest_init+0x18d/0x1a0 init/main.c:415
 start_kernel+0x747/0x779 init/main.c:679
 x86_64_start_reservations+0x2a/0x2c arch/x86/kernel/head64.c:196
 x86_64_start_kernel+0x132/0x141 arch/x86/kernel/head64.c:177
 secondary_startup_64+0x9f/0x9f arch/x86/kernel/head_64.S:304

Allocated by task 30543:
 save_stack_trace+0x16/0x20 arch/x86/kernel/stacktrace.c:59
 save_stack+0x43/0xd0 mm/kasan/kasan.c:513
 set_track mm/kasan/kasan.c:525 [inline]
 kasan_kmalloc+0xad/0xe0 mm/kasan/kasan.c:617
 kmem_cache_alloc_trace+0x82/0x270 mm/slub.c:2745
 kmalloc include/linux/slab.h:492 [inline]
 kzalloc include/linux/slab.h:665 [inline]
 ip_mc_add1_src net/ipv4/igmp.c:1909 [inline]
 ip_mc_add_src+0x6cd/0x1020 net/ipv4/igmp.c:2033
 ip_mc_msfilter+0x5e5/0xcf0 net/ipv4/igmp.c:2403
 do_ip_setsockopt.isra.12+0x2d47/0x38c0 net/ipv4/ip_sockglue.c:959
 ip_setsockopt+0x3a/0xb0 net/ipv4/ip_sockglue.c:1256
 tcp_setsockopt+0x82/0xd0 net/ipv4/tcp.c:2740
 sock_common_setsockopt+0x95/0xd0 net/core/sock.c:2844
 SYSC_setsockopt net/socket.c:1798 [inline]
 SyS_setsockopt+0x270/0x3a0 net/socket.c:1777
 entry_SYSCALL_64_fastpath+0x1f/0xbe

Freed by task 30543:
 save_stack_trace+0x16/0x20 arch/x86/kernel/stacktrace.c:59
 save_stack+0x43/0xd0 mm/kasan/kasan.c:513
 set_track mm/kasan/kasan.c:525 [inline]
 kasan_slab_free+0x72/0xc0 mm/kasan/kasan.c:590
 slab_free_hook mm/slub.c:1357 [inline]
 slab_free_freelist_hook mm/slub.c:1379 [inline]
 slab_free mm/slub.c:2961 [inline]
 kfree+0xe8/0x2b0 mm/slub.c:3882
 ip_mc_clear_src+0x69/0x1c0 net/ipv4/igmp.c:2078
 ip_mc_dec_group+0x19a/0x470 net/ipv4/igmp.c:1618
 ip_mc_drop_socket+0x145/0x230 net/ipv4/igmp.c:2609
 inet_release+0x4e/0x1c0 net/ipv4/af_inet.c:411
 sock_release+0x8d/0x1e0 net/socket.c:597
 sock_close+0x16/0x20 net/socket.c:1072
 __fput+0x332/0x7f0 fs/file_table.c:209
 fput+0x15/0x20 fs/file_table.c:245
 task_work_run+0x19b/0x270 kernel/task_work.c:116
 exit_task_work include/linux/task_work.h:21 [inline]
 do_exit+0x18a3/0x2820 kernel/exit.c:878
 do_group_exit+0x149/0x420 kernel/exit.c:982
 get_signal+0x76d/0x1790 kernel/signal.c:2318
 do_signal+0xd2/0x2130 arch/x86/kernel/signal.c:808
 exit_to_usermode_loop+0x17a/0x210 arch/x86/entry/common.c:157
 prepare_exit_to_usermode arch/x86/entry/common.c:194 [inline]
 syscall_return_slowpath+0x3ba/0x410 arch/x86/entry/common.c:263
 entry_SYSCALL_64_fastpath+0xbc/0xbe

The buggy address belongs to the object at 88003053c1a0
 which belongs to the cache kmalloc-64 of size 64
The buggy address is located 0 bytes inside of
 64-byte region [88003053c1a0, 88003053c1e0)
The buggy address belongs to the page:

net/ipv6: use-after-free in ip6_dst_ifdown

[Andrey Konovalov]

Hi,

I've got the following error report while fuzzing the kernel with syzkaller.

On commit 5ed02dbb497422bf225783f46e6eadd237d23d6b (4.12-rc3).

Unfortunately it's not reproducible.

==
BUG: KASAN: use-after-free in ip6_dst_ifdown+0x3cc/0x400 net/ipv6/route.c:422
Read of size 8 at addr 88006afa4ad8 by task syz-executor6/23554

CPU: 3 PID: 23554 Comm: syz-executor6 Not tainted 4.12.0-rc3+ #370
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011
Call Trace:
 __dump_stack lib/dump_stack.c:16 [inline]
 dump_stack+0x292/0x395 lib/dump_stack.c:52
 print_address_description+0x73/0x280 mm/kasan/report.c:252
 kasan_report_error mm/kasan/report.c:351 [inline]
 kasan_report+0x22b/0x340 mm/kasan/report.c:408
 __asan_report_load8_noabort+0x14/0x20 mm/kasan/report.c:429
 ip6_dst_ifdown+0x3cc/0x400 net/ipv6/route.c:422
 dst_ifdown+0x75/0x230 net/core/dst.c:439
 dst_dev_event+0xb1/0x230 net/core/dst.c:466
 notifier_call_chain+0x145/0x2e0 kernel/notifier.c:93
 __raw_notifier_call_chain kernel/notifier.c:394 [inline]
 raw_notifier_call_chain+0x2d/0x40 kernel/notifier.c:401
 call_netdevice_notifiers_info+0x51/0x90 net/core/dev.c:1649
 call_netdevice_notifiers net/core/dev.c:1665 [inline]
 __dev_notify_flags+0x1fd/0x320 net/core/dev.c:6640
 dev_change_flags+0xf5/0x140 net/core/dev.c:6671
 dev_ifsioc+0x62a/0x9f0 net/core/dev_ioctl.c:254
 dev_ioctl+0x249/0x1160 net/core/dev_ioctl.c:532
 sock_do_ioctl+0x94/0xb0 net/socket.c:913
 sock_ioctl+0x28f/0x440 net/socket.c:1004
 vfs_ioctl fs/ioctl.c:45 [inline]
 do_vfs_ioctl+0x1bf/0x1660 fs/ioctl.c:685
 SYSC_ioctl fs/ioctl.c:700 [inline]
 SyS_ioctl+0x8f/0xc0 fs/ioctl.c:691
 entry_SYSCALL_64_fastpath+0x1f/0xbe
RIP: 0033:0x446179
RSP: 002b:7fd1da4bdc08 EFLAGS: 0282 ORIG_RAX: 0010
RAX: ffda RBX: 3220 RCX: 00446179
RDX: 20d34000 RSI: 8914 RDI: 0005
RBP:  R08:  R09: 
R10:  R11: 0282 R12: 0005
R13: 0390 R14: 006e1450 R15: 

Allocated by task 23235:
 save_stack_trace+0x16/0x20 arch/x86/kernel/stacktrace.c:59
 save_stack+0x43/0xd0 mm/kasan/kasan.c:513
 set_track mm/kasan/kasan.c:525 [inline]
 kasan_kmalloc+0xad/0xe0 mm/kasan/kasan.c:617
 kasan_slab_alloc+0x12/0x20 mm/kasan/kasan.c:555
 slab_post_alloc_hook mm/slab.h:456 [inline]
 slab_alloc_node mm/slub.c:2718 [inline]
 __kmalloc_node_track_caller+0x20d/0x350 mm/slub.c:4303
 __kmalloc_reserve.isra.32+0x41/0xd0 net/core/skbuff.c:138
 __alloc_skb+0x157/0x770 net/core/skbuff.c:231
 alloc_skb include/linux/skbuff.h:936 [inline]
 alloc_skb_with_frags+0x12e/0x780 net/core/skbuff.c:4690
 sock_alloc_send_pskb+0x804/0xa30 net/core/sock.c:2000
 tun_alloc_skb drivers/net/tun.c:1144 [inline]
 tun_get_user+0x91a/0x2e10 drivers/net/tun.c:1274
 tun_chr_write_iter+0xd8/0x190 drivers/net/tun.c:1365
 call_write_iter include/linux/fs.h:1734 [inline]
 new_sync_write fs/read_write.c:497 [inline]
 __vfs_write+0x483/0x760 fs/read_write.c:510
 vfs_write+0x187/0x500 fs/read_write.c:558
 SYSC_write fs/read_write.c:605 [inline]
 SyS_write+0xfb/0x230 fs/read_write.c:597
 entry_SYSCALL_64_fastpath+0x1f/0xbe

Freed by task 23235:
 save_stack_trace+0x16/0x20 arch/x86/kernel/stacktrace.c:59
 save_stack+0x43/0xd0 mm/kasan/kasan.c:513
 set_track mm/kasan/kasan.c:525 [inline]
 kasan_slab_free+0x72/0xc0 mm/kasan/kasan.c:590
 slab_free_hook mm/slub.c:1357 [inline]
 slab_free_freelist_hook mm/slub.c:1379 [inline]
 slab_free mm/slub.c:2961 [inline]
 kfree+0xe8/0x2b0 mm/slub.c:3882
 skb_free_head+0x74/0xb0 net/core/skbuff.c:579
 skb_release_data+0x3ce/0x4a0 net/core/skbuff.c:610
 skb_release_all+0x4a/0x60 net/core/skbuff.c:669
 __kfree_skb+0x15/0x20 net/core/skbuff.c:683
 kfree_skb+0x16e/0x4e0 net/core/skbuff.c:704
 llc_rcv+0x5c7/0xed0 net/llc/llc_input.c:214
 __netif_receive_skb_core+0x1ad1/0x3400 net/core/dev.c:4216
 __netif_receive_skb+0x2c/0x1b0 net/core/dev.c:4254
 netif_receive_skb_internal+0x240/0x1b20 net/core/dev.c:4416
 netif_receive_skb+0xae/0x3b0 net/core/dev.c:4440
 tun_rx_batched.isra.40+0x5e5/0x8c0 drivers/net/tun.c:1167
 tun_get_user+0x100d/0x2e10 drivers/net/tun.c:1339
 tun_chr_write_iter+0xd8/0x190 drivers/net/tun.c:1365
 call_write_iter include/linux/fs.h:1734 [inline]
 new_sync_write fs/read_write.c:497 [inline]
 __vfs_write+0x483/0x760 fs/read_write.c:510
 vfs_write+0x187/0x500 fs/read_write.c:558
 SYSC_write fs/read_write.c:605 [inline]
 SyS_write+0xfb/0x230 fs/read_write.c:597
 entry_SYSCALL_64_fastpath+0x1f/0xbe

The buggy address belongs to the object at 88006afa4ad8
 which belongs to the cache kmalloc-1024 of size 1024
The buggy address is located 0 bytes inside of
 1024-byte region [88006afa4ad8, 88006afa4ed8)
The buggy address belongs to the page:
page:ea0001abe800 count:1 mapcount:0 mapping:  (null)
index:0x0 compound_mapcount: 0

Re: general protection fault in skb_release_data

[Andrey Konovalov]

On Fri, May 19, 2017 at 4:36 PM, 'Eric Dumazet' via syzkaller
<syzkal...@googlegroups.com> wrote:
> On Fri, May 19, 2017 at 5:57 AM, Andrey Konovalov <andreyk...@google.com> 
> wrote:
>> On Fri, May 19, 2017 at 12:18 PM,  <idaif...@gmail.com> wrote:
>>> Hi,
>>>
>>> I've got the following bug report while fuzzing the
>>> kernel(master-f83246089ca) with syzkaller.
>>>
>>> program and config are attached.
>>
>> Hi!
>>
>> Thanks for the report!
>>
>> Adding kernel maintainers.
>>
>> I can confirm that we've hist this bug multiple times, but never been
>> able to reproduce it.
>>
>> I was able to reproduce it on 2ea659a9ef488125eb46da6eb571de5eae5c43f6
>> (4.12-rc1).
>>
>> Using the attached syzkaller program I was able to generate C
>> reproducer, attached. Sometimes I need to run it a few times to
>> trigger the bug.
>>
>> @idaifish If you find more bugs please run ./scripts/get_maintainer.pl
>> to get the list of subsystem maintainers and add them to the
>> recipients. I've updated instructions of how to report kernel bugs
>> found with syzkaller in README.
>>
>> Thanks!
>>
>>>
>>> ===
>>> 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: 2 PID: 21599 Comm: syz-executor3 Not tainted 4.11.0-rc8+ #1
>>> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS
>>> Ubuntu-1.8.2-1ubuntu1 04/01/2014
>>> task: 88006c16dec0 task.stack: 880058bb8000
>>> RIP: 0010:__read_once_size include/linux/compiler.h:254 [inline]
>>> RIP: 0010:compound_head include/linux/page-flags.h:146 [inline]
>>> RIP: 0010:put_page include/linux/mm.h:796 [inline]
>>> RIP: 0010:__skb_frag_unref include/linux/skbuff.h:2613 [inline]
>>> RIP: 0010:skb_release_data+0x201/0x3b0 net/core/skbuff.c:593
>>> RSP: 0018:880058bbf570 EFLAGS: 00010a02
>>> RAX: 11032b488bad1523 RBX: 88006c6e8ec8 RCX: c9000190e000
>>> RDX: 11000d8dd1df RSI: 8293d7e3 RDI: 88195a445d68a919
>>> RBP: 880058bbf5a8 R08: 7bdf27567b31597f R09: 
>>> R10: 00d2 R11: 7dc9ab6dec891f24 R12: 
>>> R13: dc00 R14: 88006a475940 R15: 88195a445d68a8f9
>>> FS:  7fbbc6a34700() GS:88006e40() knlGS:
>>> CS:  0010 DS:  ES:  CR0: 80050033
>>> CR2: 2004e000 CR3: 6b868000 CR4: 06e0
>>> Call Trace:
>>>  skb_release_all+0x4a/0x60 net/core/skbuff.c:669
>>>  __kfree_skb net/core/skbuff.c:683 [inline]
>>>  kfree_skb+0x85/0x1b0 net/core/skbuff.c:704
>>>  __ip6_append_data.isra.42+0x26ed/0x33b0 net/ipv6/ip6_output.c:1519
>>>  ip6_append_data+0x1a8/0x2f0 net/ipv6/ip6_output.c:1633
>>>  udpv6_sendmsg+0x7bd/0x2360 net/ipv6/udp.c:1264
>>>  inet_sendmsg+0x123/0x3a0 net/ipv4/af_inet.c:762
>>>  sock_sendmsg_nosec net/socket.c:633 [inline]
>>>  sock_sendmsg+0xca/0x110 net/socket.c:643
>>>  ___sys_sendmsg+0x79f/0x900 net/socket.c:1997
>>>  __sys_sendmsg+0xd1/0x170 net/socket.c:2031
>>>  SYSC_sendmsg net/socket.c:2042 [inline]
>>>  SyS_sendmsg+0x2d/0x50 net/socket.c:2038
>>>  entry_SYSCALL_64_fastpath+0x1a/0xa9
>>> RIP: 0033:0x44fb79
>>> RSP: 002b:7fbbc6a33b58 EFLAGS: 0212 ORIG_RAX: 002e
>>> RAX: ffda RBX: 00718000 RCX: 0044fb79
>>> RDX:  RSI: 2000afc8 RDI: 0005
>>> RBP: 03fb R08:  R09: 
>>> R10:  R11: 0212 R12: 0005
>>> R13: 20001000 R14: 00048000 R15: 
>>> Code: 48 83 c0 03 48 c1 e0 04 48 01 d8 48 89 c2 48 c1 ea 03 42 80 3c 2a 00
>>> 0f 85 92 01 00 00 4c 8b 38 49 8d 7f 20 48 89 f8 48 c1 e8 03 <42> 80 3c 28 00
>>> 0f 85 6f 01 00 00 49 8b 47 20 a8 01 0f 84 3b ff
>>> RIP: __read_once_size include/linux/compiler.h:254 [inline] RSP:
>>> 880058bbf570
>>> RIP: compound_head include/linux/page-flags.h:146 [inline] RSP:
>>> 880058bbf570
>>> RIP: put_page include/linux/mm.h:796 [inline] RSP: 880058bbf570
>>> RIP: __skb_frag_unref include/linux/skbuff.h:2613 [inline] RSP:
>>> ffff880058bbf570
>>

Re: [[PATCH v1]] hdlcdrv: fix divide error bug if bitrate is 0

[Andrey Konovalov]

On Thu, May 18, 2017 at 6:02 AM, Firo Yang  wrote:
> The divisor s->par.bitrate will always be 0 until initialized by
> ndo_open() and hdlcdrv_open().
>
> In order to fix this divide zero error, check whether the netdevice was
> opened by ndo_open() before performing divide.And we also check the the
> value of bitrate in case of bad setting of it.
>
> Reported-by: Dmitry Vyukov 
> Signed-off-by: Firo Yang 

Hi Firo,

Please reply to the original report thread when you send a fix, so
other people won't start working on the same patch.

BTW, it was reported by me, but I don't think it's important.

Thanks!

> ---
> v0->v1:
> Reviewed by walter harms .
> Return ENODEV instead of EPERM if !netif_running(dev)
> Check if s->par.bitrate > 0.
>
>  drivers/net/hamradio/hdlcdrv.c | 4 
>  1 file changed, 4 insertions(+)
>
> diff --git a/drivers/net/hamradio/hdlcdrv.c b/drivers/net/hamradio/hdlcdrv.c
> index 8c3633c..b0f417f 100644
> --- a/drivers/net/hamradio/hdlcdrv.c
> +++ b/drivers/net/hamradio/hdlcdrv.c
> @@ -576,6 +576,10 @@ static int hdlcdrv_ioctl(struct net_device *dev, struct 
> ifreq *ifr, int cmd)
> case HDLCDRVCTL_CALIBRATE:
> if(!capable(CAP_SYS_RAWIO))
> return -EPERM;
> +   if (!netif_running(dev))
> +   return -ENODEV;
> +   if (!(s->par.bitrate > 0))
> +   return -EINVAL;
> if (bi.data.calibrate > INT_MAX / s->par.bitrate)
> return -EINVAL;
> s->hdlctx.calibrate = bi.data.calibrate * s->par.bitrate / 16;
> --
> 2.7.4
>
> --
> You received this message because you are subscribed to the Google Groups 
> "syzkaller" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to syzkaller+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

Re: drivers/net/hamradio: divide error in hdlcdrv_ioctl

[Andrey Konovalov]

On Wed, May 17, 2017 at 10:07 PM, Alan Cox <gno...@lxorguk.ukuu.org.uk> wrote:
> On Tue, 16 May 2017 17:05:32 +0200
> Andrey Konovalov <andreyk...@google.com> wrote:
>
>> Hi,
>>
>> I've got the following error report while fuzzing the kernel with syzkaller.
>>
>> On commit 2ea659a9ef488125eb46da6eb571de5eae5c43f6 (4.12-rc1).
>>
>> A reproducer and .config are attached.
>
> This should fix it.

Hi Alan,

Someone else has already sent a couple of versions of a similar fix.

https://patchwork.ozlabs.org/patch/763832/

Thanks!

>
> commit 37b3fa4b617681f00cfa1f76d6d7716cc6d9f79a
> Author: Alan Cox <alan@llwyncelyn.cymru>
> Date:   Wed May 17 21:04:27 2017 +0100
>
> hdlcdrv: Fix division by zero when bitrate is unset
>
> The code attempts to check for out of range calibration. What it forgets 
> to do
> is check for the 0 bitrate case. As a result the range check itself 
> oopses the
> kernel.
>
> Found by Andrey Konovalov using Syzkaller.
>
> Signed-off-by: Alan Cox <a...@linux.intel.com>
>
> diff --git a/drivers/net/hamradio/hdlcdrv.c b/drivers/net/hamradio/hdlcdrv.c
> index 8c3633c..9f34a48 100644
> --- a/drivers/net/hamradio/hdlcdrv.c
> +++ b/drivers/net/hamradio/hdlcdrv.c
> @@ -576,7 +576,7 @@ static int hdlcdrv_ioctl(struct net_device *dev, struct 
> ifreq *ifr, int cmd)
> case HDLCDRVCTL_CALIBRATE:
> if(!capable(CAP_SYS_RAWIO))
> return -EPERM;
> -   if (bi.data.calibrate > INT_MAX / s->par.bitrate)
> +   if (!s->par.bitrate || bi.data.calibrate > INT_MAX / 
> s->par.bitrate)
> return -EINVAL;
> s->hdlctx.calibrate = bi.data.calibrate * s->par.bitrate / 16;
> return 0;

Re: drivers/net/hamradio: divide error in hdlcdrv_ioctl

[Andrey Konovalov]

On Tue, May 16, 2017 at 5:05 PM, Andrey Konovalov <andreyk...@google.com> wrote:
> Hi,
>
> I've got the following error report while fuzzing the kernel with syzkaller.
>
> On commit 2ea659a9ef488125eb46da6eb571de5eae5c43f6 (4.12-rc1).
>
> A reproducer and .config are attached.

+syzkaller

>
> divide error:  [#1] SMP KASAN
> Modules linked in:
> CPU: 1 PID: 4019 Comm: a.out Not tainted 4.12.0-rc1+ #363
> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011
> task: 88006b97c200 task.stack: 880062098000
> RIP: 0010:hdlcdrv_ioctl+0x8a3/0x1a50 drivers/net/hamradio/hdlcdrv.c:579
> RSP: 0018:88006209f898 EFLAGS: 00010246
> RAX: 7fff RBX: 88006209f8d0 RCX: 
> RDX:  RSI:  RDI: 88006888abd0
> RBP: 88006209f9b8 R08: 11000c413e8a R09: 11000c413e6a
> R10: 88006b97c200 R11: 0001 R12: 11000c413f16
> R13: 88006888a100 R14:  R15: 005b78f4
> FS:  7fb533884700() GS:88006cb0() knlGS:
> CS:  0010 DS:  ES:  CR0: 80050033
> CR2: 2026b000 CR3: 65576000 CR4: 06e0
> Call Trace:
>  dev_ifsioc+0x53f/0x9f0 net/core/dev_ioctl.c:338
>  dev_ioctl+0xc3c/0x1160 net/core/dev_ioctl.c:555
>  sock_ioctl+0x169/0x440 net/socket.c:944
>  vfs_ioctl fs/ioctl.c:45
>  do_vfs_ioctl+0x1bf/0x1660 fs/ioctl.c:685
>  SYSC_ioctl fs/ioctl.c:700
>  SyS_ioctl+0x8f/0xc0 fs/ioctl.c:691
>  entry_SYSCALL_64_fastpath+0x1f/0xbe arch/x86/entry/entry_64.S:204
> RIP: 0033:0x7fb532f96b79
> RSP: 002b:7fffac2839f8 EFLAGS: 0206 ORIG_RAX: 0010
> RAX: ffda RBX: 7fffac283b60 RCX: 7fb532f96b79
> RDX: 208f1fd8 RSI: 010089f0 RDI: 0003
> RBP: 004004e0 R08:  R09: 
> R10:  R11: 0206 R12: 
> R13: 7fffac283b60 R14:  R15: 
> Code: 45 8b be 48 ff ff ff 48 89 fa 48 c1 ea 03 0f b6 04 02 84 c0 74
> 08 3c 03 0f 8e 8b 0e 00 00 45 8b b5 d0 0a 00 00 b8 ff ff ff 7f 99 <41>
> f7 fe 41 39 c7 0f 87 89 0c 00 00 e8 ac e5 7e fe 49 8d bd d8
> RIP: hdlcdrv_ioctl+0x8a3/0x1a50 RSP: 88006209f898
> ---[ end trace 204af21e5cc80963 ]---
> qemu: terminating on signal 15 from pid 141905

Re: net/key: slab-out-of-bounds in pfkey_compile_policy

[Andrey Konovalov]

On Fri, May 5, 2017 at 11:11 AM, Steffen Klassert
<steffen.klass...@secunet.com> wrote:
> On Tue, May 02, 2017 at 06:45:03PM +0200, Andrey Konovalov wrote:
>> Hi,
>>
>> I've got the following error report while fuzzing the kernel with syzkaller.
>>
>> On commit d3b5d35290d729a2518af00feca867385a1b08fa (4.11).
>>
>> A reproducer and .config are attached.
>>
>> ==
>> BUG: KASAN: slab-out-of-bounds in pfkey_compile_policy+0x8e6/0xd40 at
>> addr 88006701f798
>> Read of size 1280 by task a.out/4181
>
>
> This bug was introduced twelve years ago...
>
> This patch is based just on code review, I don't have an option to
> function test this. But I see that we now exit with -EINVAL before the
> memcpy that causes the slab-out-of-bounds when using your reproducer,
> so it should at least fix the bug.

Hi Steffen,

This patch fixes the issue for me.

Thanks!

Tested-by: Andrey Konovalov <andreyk...@google.com>

>
> Subject: [PATCH RFC] af_key: Fix slab-out-of-bounds in pfkey_compile_policy.
>
> The sadb_x_sec_len is stored in the unit 'byte divided by eight'.
> So we have to multiply this value by eight before we can do
> size checks. Otherwise we may get a slab-out-of-bounds when
> we memcpy the user sec_ctx.
>
> Fixes: df71837d502 ("[LSM-IPSec]: Security association restriction.")
> Reported-by: Andrey Konovalov <andreyk...@google.com>
> Signed-off-by: Steffen Klassert <steffen.klass...@secunet.com>
> ---
>  net/key/af_key.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/net/key/af_key.c b/net/key/af_key.c
> index c1950bb..512dc43 100644
> --- a/net/key/af_key.c
> +++ b/net/key/af_key.c
> @@ -3285,7 +3285,7 @@ static struct xfrm_policy *pfkey_compile_policy(struct 
> sock *sk, int opt,
> p += pol->sadb_x_policy_len*8;
> sec_ctx = (struct sadb_x_sec_ctx *)p;
> if (len < pol->sadb_x_policy_len*8 +
> -   sec_ctx->sadb_x_sec_len) {
> +   sec_ctx->sadb_x_sec_len*8) {
> *dir = -EINVAL;
> goto out;
> }
> --
> 2.7.4
>
>

Re: net/ipv4: use-after-free in ip_queue_xmit

[Andrey Konovalov]

On Mon, Apr 10, 2017 at 7:46 PM, Andrey Konovalov <andreyk...@google.com> wrote:
> On Mon, Apr 10, 2017 at 7:42 PM, Cong Wang <xiyou.wangc...@gmail.com> wrote:
>> On Mon, Apr 10, 2017 at 7:40 AM, Andrey Konovalov <andreyk...@google.com> 
>> wrote:
>>> Hi,
>>>
>>> I've got the following error report while fuzzing the kernel with syzkaller.
>>>
>>> On commit 39da7c509acff13fc8cb12ec1bb20337c988ed36 (4.11-rc6).
>>>
>>> Unfortunately it's not reproducible.
>>>
>>> BUG: KASAN: use-after-free in ip_select_ttl include/net/dst.h:176
>>> [inline] at addr 88006ab3602c
>>> BUG: KASAN: use-after-free in ip_queue_xmit+0x1817/0x1a30
>>> net/ipv4/ip_output.c:485 at addr 88006ab3602c
>>> Read of size 4 by task syz-executor1/12627
>>> CPU: 3 PID: 12627 Comm: syz-executor1 Not tainted 4.11.0-rc6+ #206
>>> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011
>>> Call Trace:
>>>  __dump_stack lib/dump_stack.c:16 [inline]
>>>  dump_stack+0x292/0x398 lib/dump_stack.c:52
>>>  kasan_object_err+0x1c/0x70 mm/kasan/report.c:164
>>>  print_address_description mm/kasan/report.c:202 [inline]
>>>  kasan_report_error mm/kasan/report.c:291 [inline]
>>>  kasan_report+0x252/0x510 mm/kasan/report.c:347
>>>  __asan_report_load4_noabort+0x14/0x20 mm/kasan/report.c:367
>>>  ip_select_ttl include/net/dst.h:176 [inline]
>>
>> Probably same as the one you reported on ipv4_mtu(), it would
>> be nice if you could test the patch I proposed:
>>
>> https://patchwork.ozlabs.org/patch/747556/
>
> Applied your patch.
>
> The bug gets triggered very rarely (only twice so far), but I'll let
> you know if I see it again.

Hi Cong,

I haven't seen those report any more.

Could you mail the patch?

Thanks!

>
> Thanks!
>
>>
>>
>> Thanks!
>>
>>>  ip_queue_xmit+0x1817/0x1a30 net/ipv4/ip_output.c:485
>>>  sctp_v4_xmit+0x10d/0x140 net/sctp/protocol.c:994
>>>  sctp_packet_transmit+0x215c/0x3560 net/sctp/output.c:637
>>>  sctp_outq_flush+0xade/0x3f90 net/sctp/outqueue.c:885
>>>  sctp_outq_uncork+0x5a/0x70 net/sctp/outqueue.c:750
>>>  sctp_cmd_interpreter net/sctp/sm_sideeffect.c:1773 [inline]
>>>  sctp_side_effects net/sctp/sm_sideeffect.c:1175 [inline]
>>>  sctp_do_sm+0x5a0/0x6a50 net/sctp/sm_sideeffect.c:1147
>>>  sctp_primitive_ASSOCIATE+0x9d/0xd0 net/sctp/primitive.c:88
>>>  sctp_sendmsg+0x270d/0x3b50 net/sctp/socket.c:1954
>>>  inet_sendmsg+0x164/0x5b0 net/ipv4/af_inet.c:762
>>>  sock_sendmsg_nosec net/socket.c:633 [inline]
>>>  sock_sendmsg+0xca/0x110 net/socket.c:643
>>>  SYSC_sendto+0x660/0x810 net/socket.c:1696
>>>  SyS_sendto+0x40/0x50 net/socket.c:1664
>>>  entry_SYSCALL_64_fastpath+0x1f/0xc2
>>> RIP: 0033:0x4458d9
>>> RSP: 002b:7fdceca85b58 EFLAGS: 0282 ORIG_RAX: 002c
>>> RAX: ffda RBX: 0016 RCX: 004458d9
>>> RDX: 0087 RSI: 20003000 RDI: 0016
>>> RBP: 006e2fe0 R08: 20003000 R09: 0010
>>> R10: 00040841 R11: 0282 R12: 007080a8
>>> R13: 000a R14: 0005 R15: 0084
>>> Object at 88006ab36008, in cache kmalloc-64 size: 64
>>> Allocated:
>>> PID = 7243
>>>  save_stack_trace+0x16/0x20 arch/x86/kernel/stacktrace.c:59
>>>  save_stack+0x43/0xd0 mm/kasan/kasan.c:513
>>>  set_track mm/kasan/kasan.c:525 [inline]
>>>  kasan_kmalloc+0xad/0xe0 mm/kasan/kasan.c:616
>>>  kmem_cache_alloc_trace+0x82/0x270 mm/slub.c:2745
>>>  kmalloc include/linux/slab.h:490 [inline]
>>>  kzalloc include/linux/slab.h:663 [inline]
>>>  fib_create_info+0x8e0/0x3a30 net/ipv4/fib_semantics.c:1040
>>>  fib_table_insert+0x1a5/0x1550 net/ipv4/fib_trie.c:1221
>>>  ip_rt_ioctl+0xddc/0x1590 net/ipv4/fib_frontend.c:597
>>>  inet_ioctl+0xf2/0x1c0 net/ipv4/af_inet.c:882
>>>  sock_do_ioctl+0x65/0xb0 net/socket.c:906
>>>  sock_ioctl+0x28f/0x440 net/socket.c:1004
>>>  vfs_ioctl fs/ioctl.c:45 [inline]
>>>  do_vfs_ioctl+0x1bf/0x1780 fs/ioctl.c:685
>>>  SYSC_ioctl fs/ioctl.c:700 [inline]
>>>  SyS_ioctl+0x8f/0xc0 fs/ioctl.c:691
>>>  entry_SYSCALL_64_fastpath+0x1f/0xc2
>>> Freed:
>>> PID = 12622
>>>  save_stack_trace+0x16/0x20 arch/x86/kernel/stacktrace.c:59
>>>  save_stack+0x43/0xd0 mm/kasan/kasan.c:513
>>>  set_track mm/kasan/kasan.c:525 [inline]
&g

Re: net/dccp: dccp_create_openreq_child freed held lock

[Andrey Konovalov]

On Thu, May 4, 2017 at 3:53 PM, David Miller <da...@davemloft.net> wrote:
> From: Andrey Konovalov <andreyk...@google.com>
> Date: Thu, 4 May 2017 15:36:37 +0200
>
>> On Wed, Mar 1, 2017 at 4:40 PM, Arnaldo Carvalho de Melo
>> <a...@kernel.org> wrote:
>>> Em Wed, Mar 01, 2017 at 12:35:10PM -0300, Arnaldo Carvalho de Melo escreveu:
>>>> Em Wed, Mar 01, 2017 at 10:38:54AM +0100, Dmitry Vyukov escreveu:
>>>> > Hello,
>>>> >
>>>> > I've got the following report while running syzkaller fuzzer on
>>>> > 86292b33d4b79ee03e2f43ea0381ef85f077c760:
>>>> >
>>>> >
>>>> > It seems that dccp_create_openreq_child needs to unlock the sock if
>>>> > dccp_feat_activate_values fails.
>>>>
>>>> Yeah, can you please use the patch below, that mimics the error paths in
>>>> sk_clone_new(), from where I think even the comment about it being a raw
>>>
>>> Argh, s/sk_clone_new()/sk_clone_lock()/g
>>
>> Hi Arnaldo,
>>
>> Could you send the patch?
>>
>> We haven't seen these reports since we applied it.
>
> It isn't necessary in the current tree.
>
> Arnaldo created a helper sk_free_unlock_clone() which handles this situation
> properly, and calls it from dccp_create_openreq_child().

OK, great, thanks!

Re: net: possible deadlock in skb_queue_tail

[Andrey Konovalov]

On Fri, Feb 24, 2017 at 3:56 AM, Florian Westphal <f...@strlen.de> wrote:
> Andrey Konovalov <andreyk...@google.com> wrote:
>
> [ CC Paolo ]
>
>> I've got the following error report while fuzzing the kernel with syzkaller.
>>
>> On commit c470abd4fde40ea6a0846a2beab642a578c0b8cd (4.10).
>>
>> Unfortunately I can't reproduce it.
>
> This needs NETLINK_BROADCAST_ERROR enabled on a netlink socket
> that then subscribes to netfilter conntrack (ctnetlink) events.
> probably syzkaller did this by accident -- impressive.
>
> (one task is the ctnetlink event redelivery worker
>  which won't be scheduled otherwise).
>
>> ==
>> [ INFO: possible circular locking dependency detected ]
>> 4.10.0-rc8+ #201 Not tainted
>> ---
>> kworker/0:2/1404 is trying to acquire lock:
>>  (&(>lock)->rlock#3){+.-...}, at: []
>> skb_queue_tail+0xcf/0x2f0 net/core/skbuff.c:2478
>>
>> but task is already holding lock:
>>  (&(>lock)->rlock){+.-...}, at: [] spin_lock
>> include/linux/spinlock.h:302 [inline]
>>  (&(>lock)->rlock){+.-...}, at: []
>> ecache_work_evict_list+0xaf/0x590
>> net/netfilter/nf_conntrack_ecache.c:48
>>
>> which lock already depends on the new lock.
>
> Cong is correct, this is a false positive.
>
> However we should fix this splat.
>
> Paolo, this happens since 7c13f97ffde63cc792c49ec1513f3974f2f05229
> ('udp: do fwd memory scheduling on dequeue'), before this
> commit kfree_skb() was invoked outside of the locked section in
> first_packet_length().
>
> cpu 0 call chain:
> - first_packet_length (hold udp sk_receive_queue lock)
>- kfree_skb
>   - nf_conntrack_destroy
>  - spin_lock(net->ct.pcpu->lock)
>
> cpu 1 call chain:
> - ecache_work_evict_list
>   - spin_lock( net->ct.pcpu->lock)
>   - nf_conntrack_event
>  - aquire netlink socket sk_receive_queue
>
> So this could only ever deadlock if a netlink socket
> calls kfree_skb while holding its sk_receive_queue lock, but afaics
> this is never the case.
>
> There are two ways to avoid this splat (other than lockdep annotation):
>
> 1. re-add the list to first_packet_length() and free the
> skbs outside of locked section.
>
> 2. change ecache_work_evict_list to not call nf_conntrack_event()
> while holding the pcpu lock.
>
> doing #2 might be a good idea anyway to avoid potential deadlock
> when kfree_skb gets invoked while other cpu holds its sk_receive_queue
> lock, I'll have a look if this is feasible.

Hi!

Any updates on this?

I might have missed the patch if there was one.

Thanks!

Re: net/dccp: dccp_create_openreq_child freed held lock

[Andrey Konovalov]

On Wed, Mar 1, 2017 at 4:40 PM, Arnaldo Carvalho de Melo
 wrote:
> Em Wed, Mar 01, 2017 at 12:35:10PM -0300, Arnaldo Carvalho de Melo escreveu:
>> Em Wed, Mar 01, 2017 at 10:38:54AM +0100, Dmitry Vyukov escreveu:
>> > Hello,
>> >
>> > I've got the following report while running syzkaller fuzzer on
>> > 86292b33d4b79ee03e2f43ea0381ef85f077c760:
>> >
>> >
>> > It seems that dccp_create_openreq_child needs to unlock the sock if
>> > dccp_feat_activate_values fails.
>>
>> Yeah, can you please use the patch below, that mimics the error paths in
>> sk_clone_new(), from where I think even the comment about it being a raw
>
> Argh, s/sk_clone_new()/sk_clone_lock()/g

Hi Arnaldo,

Could you send the patch?

We haven't seen these reports since we applied it.

Thanks!

>
> - Arnaldo
>
>> copy came, but the bh_unlock_sock() didn't?
>>
>> - Arnaldo
>>
>> diff --git a/net/dccp/minisocks.c b/net/dccp/minisocks.c
>> index 53eddf99e4f6..d20d948a98ed 100644
>> --- a/net/dccp/minisocks.c
>> +++ b/net/dccp/minisocks.c
>> @@ -122,6 +122,7 @@ struct sock *dccp_create_openreq_child(const struct sock 
>> *sk,
>>   /* It is still raw copy of parent, so invalidate
>>* destructor and make plain sk_free() */
>>   newsk->sk_destruct = NULL;
>> + bh_unlock_sock(newsk);
>>   sk_free(newsk);
>>   return NULL;
>>   }
>
> --
> You received this message because you are subscribed to the Google Groups 
> "syzkaller" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to syzkaller+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

Re: x86: warning: kernel stack regs has bad 'bp' value

[Andrey Konovalov]

On Wed, May 3, 2017 at 5:50 PM, Andrey Konovalov <andreyk...@google.com> wrote:
> On Wed, May 3, 2017 at 3:30 PM, Josh Poimboeuf <jpoim...@redhat.com> wrote:
>> On Wed, May 03, 2017 at 02:48:28PM +0200, Andrey Konovalov wrote:
>>> Hi,
>>>
>>> I've got the following error report while fuzzing the kernel with syzkaller.
>>>
>>> On commit 89c9fea3c8034cdb2fd745f551cde0b507fd6893 (4.11.0+).
>>>
>>> A reproducer and .config are attached.
>>>
>>> The reproducer open SCTP sockets and sends data to it in a loop.
>>> I'm not sure whether this is an issue with SCTP or with something else.
>>>
>>> WARNING: kernel stack regs at 8800686869f8 in a.out:4933 has bad
>>> 'bp' value c3fc855a10167ec0
>>
>> Hi Andrey,
>>
>> Can you test this patch?
>
> Hi Josh,
>
> This seems to be fixing the reports caused by the reproducers.
>
> I'll keep fuzzing though with syzkaller to make sure.

Hi Josh

I didn't see any more reports over the night.

Could you mail the patch?

Thanks!

>
> Thanks!
>
>>
>>
>> diff --git a/arch/x86/lib/csum-copy_64.S b/arch/x86/lib/csum-copy_64.S
>> index 7e48807..45a53df 100644
>> --- a/arch/x86/lib/csum-copy_64.S
>> +++ b/arch/x86/lib/csum-copy_64.S
>> @@ -55,7 +55,7 @@ ENTRY(csum_partial_copy_generic)
>> movq  %r12, 3*8(%rsp)
>> movq  %r14, 4*8(%rsp)
>> movq  %r13, 5*8(%rsp)
>> -   movq  %rbp, 6*8(%rsp)
>> +   movq  %r15, 6*8(%rsp)
>>
>> movq  %r8, (%rsp)
>> movq  %r9, 1*8(%rsp)
>> @@ -74,7 +74,7 @@ ENTRY(csum_partial_copy_generic)
>> /* main loop. clear in 64 byte blocks */
>> /* r9: zero, r8: temp2, rbx: temp1, rax: sum, rcx: saved length */
>> /* r11: temp3, rdx: temp4, r12 loopcnt */
>> -   /* r10: temp5, rbp: temp6, r14 temp7, r13 temp8 */
>> +   /* r10: temp5, r15: temp6, r14 temp7, r13 temp8 */
>> .p2align 4
>>  .Lloop:
>> source
>> @@ -89,7 +89,7 @@ ENTRY(csum_partial_copy_generic)
>> source
>> movq  32(%rdi), %r10
>> source
>> -   movq  40(%rdi), %rbp
>> +   movq  40(%rdi), %r15
>> source
>> movq  48(%rdi), %r14
>> source
>> @@ -103,7 +103,7 @@ ENTRY(csum_partial_copy_generic)
>> adcq  %r11, %rax
>> adcq  %rdx, %rax
>> adcq  %r10, %rax
>> -   adcq  %rbp, %rax
>> +   adcq  %r15, %rax
>> adcq  %r14, %rax
>> adcq  %r13, %rax
>>
>> @@ -121,7 +121,7 @@ ENTRY(csum_partial_copy_generic)
>> dest
>> movq %r10, 32(%rsi)
>> dest
>> -   movq %rbp, 40(%rsi)
>> +   movq %r15, 40(%rsi)
>> dest
>> movq %r14, 48(%rsi)
>> dest
>> @@ -203,7 +203,7 @@ ENTRY(csum_partial_copy_generic)
>> movq 3*8(%rsp), %r12
>> movq 4*8(%rsp), %r14
>> movq 5*8(%rsp), %r13
>> -   movq 6*8(%rsp), %rbp
>> +   movq 6*8(%rsp), %r15
>> addq $7*8, %rsp
>> ret
>>

Re: [Patch net] ipv6: initialize route null entry in addrconf_init()

[Andrey Konovalov]

On Thu, May 4, 2017 at 7:07 AM, Cong Wang <xiyou.wangc...@gmail.com> wrote:
> Andrey reported a crash on init_net.ipv6.ip6_null_entry->rt6i_idev
> since it is always NULL.
>
> This is clearly wrong, we have code to initialize it to loopback_dev,
> unfortunately the order is still not correct.
>
> loopback_dev is registered very early during boot, we lose a chance
> to re-initialize it in notifier. addrconf_init() is called after
> ip6_route_init(), which means we have no chance to correct it.
>
> Fix it by moving this initialization explicitly after
> ipv6_add_dev(init_net.loopback_dev) in addrconf_init().
>
> Reported-by: Andrey Konovalov <andreyk...@google.com>
> Signed-off-by: Cong Wang <xiyou.wangc...@gmail.com>

Hi Cong,

This fixes the bug triggered by my reproducer.

Thanks!

Tested-by: Andrey Konovalov <andreyk...@google.com>

> ---
>  include/net/ip6_route.h |  1 +
>  net/ipv6/addrconf.c |  2 ++
>  net/ipv6/route.c| 26 +++---
>  3 files changed, 18 insertions(+), 11 deletions(-)
>
> diff --git a/include/net/ip6_route.h b/include/net/ip6_route.h
> index 9dc2c18..f5e625f 100644
> --- a/include/net/ip6_route.h
> +++ b/include/net/ip6_route.h
> @@ -84,6 +84,7 @@ struct dst_entry *ip6_route_lookup(struct net *net, struct 
> flowi6 *fl6,
>  struct rt6_info *ip6_pol_route(struct net *net, struct fib6_table *table,
>int ifindex, struct flowi6 *fl6, int flags);
>
> +void ip6_route_init_special_entries(void);
>  int ip6_route_init(void);
>  void ip6_route_cleanup(void);
>
> diff --git a/net/ipv6/addrconf.c b/net/ipv6/addrconf.c
> index a2a370b..77a4bd5 100644
> --- a/net/ipv6/addrconf.c
> +++ b/net/ipv6/addrconf.c
> @@ -6573,6 +6573,8 @@ int __init addrconf_init(void)
> goto errlo;
> }
>
> +   ip6_route_init_special_entries();
> +
> for (i = 0; i < IN6_ADDR_HSIZE; i++)
> INIT_HLIST_HEAD(_addr_lst[i]);
>
> diff --git a/net/ipv6/route.c b/net/ipv6/route.c
> index a1bf426..2f11366 100644
> --- a/net/ipv6/route.c
> +++ b/net/ipv6/route.c
> @@ -4027,6 +4027,21 @@ static struct notifier_block ip6_route_dev_notifier = {
> .priority = 0,
>  };
>
> +void __init ip6_route_init_special_entries(void)
> +{
> +   /* Registering of the loopback is done before this portion of code,
> +* the loopback reference in rt6_info will not be taken, do it
> +* manually for init_net */
> +   init_net.ipv6.ip6_null_entry->dst.dev = init_net.loopback_dev;
> +   init_net.ipv6.ip6_null_entry->rt6i_idev = 
> in6_dev_get(init_net.loopback_dev);
> +  #ifdef CONFIG_IPV6_MULTIPLE_TABLES
> +   init_net.ipv6.ip6_prohibit_entry->dst.dev = init_net.loopback_dev;
> +   init_net.ipv6.ip6_prohibit_entry->rt6i_idev = 
> in6_dev_get(init_net.loopback_dev);
> +   init_net.ipv6.ip6_blk_hole_entry->dst.dev = init_net.loopback_dev;
> +   init_net.ipv6.ip6_blk_hole_entry->rt6i_idev = 
> in6_dev_get(init_net.loopback_dev);
> +  #endif
> +}
> +
>  int __init ip6_route_init(void)
>  {
> int ret;
> @@ -4053,17 +4068,6 @@ int __init ip6_route_init(void)
>
> ip6_dst_blackhole_ops.kmem_cachep = ip6_dst_ops_template.kmem_cachep;
>
> -   /* Registering of the loopback is done before this portion of code,
> -* the loopback reference in rt6_info will not be taken, do it
> -* manually for init_net */
> -   init_net.ipv6.ip6_null_entry->dst.dev = init_net.loopback_dev;
> -   init_net.ipv6.ip6_null_entry->rt6i_idev = 
> in6_dev_get(init_net.loopback_dev);
> -  #ifdef CONFIG_IPV6_MULTIPLE_TABLES
> -   init_net.ipv6.ip6_prohibit_entry->dst.dev = init_net.loopback_dev;
> -   init_net.ipv6.ip6_prohibit_entry->rt6i_idev = 
> in6_dev_get(init_net.loopback_dev);
> -   init_net.ipv6.ip6_blk_hole_entry->dst.dev = init_net.loopback_dev;
> -   init_net.ipv6.ip6_blk_hole_entry->rt6i_idev = 
> in6_dev_get(init_net.loopback_dev);
> -  #endif
> ret = fib6_init();
> if (ret)
> goto out_register_subsys;
> --
> 2.5.5
>

Re: x86: warning: kernel stack regs has bad 'bp' value

[Andrey Konovalov]

On Wed, May 3, 2017 at 3:30 PM, Josh Poimboeuf <jpoim...@redhat.com> wrote:
> On Wed, May 03, 2017 at 02:48:28PM +0200, Andrey Konovalov wrote:
>> Hi,
>>
>> I've got the following error report while fuzzing the kernel with syzkaller.
>>
>> On commit 89c9fea3c8034cdb2fd745f551cde0b507fd6893 (4.11.0+).
>>
>> A reproducer and .config are attached.
>>
>> The reproducer open SCTP sockets and sends data to it in a loop.
>> I'm not sure whether this is an issue with SCTP or with something else.
>>
>> WARNING: kernel stack regs at 8800686869f8 in a.out:4933 has bad
>> 'bp' value c3fc855a10167ec0
>
> Hi Andrey,
>
> Can you test this patch?

Hi Josh,

This seems to be fixing the reports caused by the reproducers.

I'll keep fuzzing though with syzkaller to make sure.

Thanks!

>
>
> diff --git a/arch/x86/lib/csum-copy_64.S b/arch/x86/lib/csum-copy_64.S
> index 7e48807..45a53df 100644
> --- a/arch/x86/lib/csum-copy_64.S
> +++ b/arch/x86/lib/csum-copy_64.S
> @@ -55,7 +55,7 @@ ENTRY(csum_partial_copy_generic)
> movq  %r12, 3*8(%rsp)
> movq  %r14, 4*8(%rsp)
> movq  %r13, 5*8(%rsp)
> -   movq  %rbp, 6*8(%rsp)
> +   movq  %r15, 6*8(%rsp)
>
> movq  %r8, (%rsp)
> movq  %r9, 1*8(%rsp)
> @@ -74,7 +74,7 @@ ENTRY(csum_partial_copy_generic)
> /* main loop. clear in 64 byte blocks */
> /* r9: zero, r8: temp2, rbx: temp1, rax: sum, rcx: saved length */
> /* r11: temp3, rdx: temp4, r12 loopcnt */
> -   /* r10: temp5, rbp: temp6, r14 temp7, r13 temp8 */
> +   /* r10: temp5, r15: temp6, r14 temp7, r13 temp8 */
> .p2align 4
>  .Lloop:
> source
> @@ -89,7 +89,7 @@ ENTRY(csum_partial_copy_generic)
> source
> movq  32(%rdi), %r10
> source
> -   movq  40(%rdi), %rbp
> +   movq  40(%rdi), %r15
> source
> movq  48(%rdi), %r14
> source
> @@ -103,7 +103,7 @@ ENTRY(csum_partial_copy_generic)
> adcq  %r11, %rax
> adcq  %rdx, %rax
> adcq  %r10, %rax
> -   adcq  %rbp, %rax
> +   adcq  %r15, %rax
> adcq  %r14, %rax
> adcq  %r13, %rax
>
> @@ -121,7 +121,7 @@ ENTRY(csum_partial_copy_generic)
> dest
> movq %r10, 32(%rsi)
> dest
> -   movq %rbp, 40(%rsi)
> +   movq %r15, 40(%rsi)
> dest
> movq %r14, 48(%rsi)
> dest
> @@ -203,7 +203,7 @@ ENTRY(csum_partial_copy_generic)
> movq 3*8(%rsp), %r12
> movq 4*8(%rsp), %r14
> movq 5*8(%rsp), %r13
> -   movq 6*8(%rsp), %rbp
> +   movq 6*8(%rsp), %r15
> addq $7*8, %rsp
> ret
>

Re: [PATCH] net: ipv6: Fix warning of freeing alive inet6 address

[Andrey Konovalov]

On Wed, May 3, 2017 at 4:16 PM, Mike Manning <mmann...@brocade.com> wrote:
> On reflection, please put this on hold subject to testing with syzkaller. I 
> have not had a repro of the issue and so the fix even though harmless may not 
> be effective.

Hi Mike,

I didn't see your patch, you think you might have forgotten to add me
to recipients.

Did you try building the kernel with the provided config and then
running the reproducer?

Would you like me to test if this patch fixes the warning?

Thanks!

>
> Thanks
> Mike
>
> On 02/05/17 19:30, Mike Manning wrote:
>> While this is not reproducible manually, Andrey's syzkaller program hit
>> the warning "IPv6: Freeing alive inet6 address" with this part trace:
>>
>> inet6_ifa_finish_destroy+0x12e/0x190 c:894
>> in6_ifa_put ./include/net/addrconf.h:330
>> addrconf_dad_work+0x4e9/0x1040 net/ipv6/addrconf.c:3963
>>
>> The fix is to call in6_ifa_put() for the inet6_ifaddr before rather
>> than after calling addrconf_ifdown(), as the latter may remove it from
>> the address hash table.
>>
>> Fixes: 85b51b12115c ("net: ipv6: Remove addresses for failures with strict 
>> DAD")
>> Reported-by: Andrey Konovalov <andreyk...@google.com>
>> Signed-off-by: Mike Manning <mmann...@brocade.com>
>> ---
>>  net/ipv6/addrconf.c | 6 +-
>>  1 file changed, 5 insertions(+), 1 deletion(-)
>>
>> diff --git a/net/ipv6/addrconf.c b/net/ipv6/addrconf.c
>> index 80ce478..361993a 100644
>> --- a/net/ipv6/addrconf.c
>> +++ b/net/ipv6/addrconf.c
>> @@ -3902,8 +3902,11 @@ static void addrconf_dad_work(struct work_struct *w)
>>   } else if (action == DAD_ABORT) {
>>   in6_ifa_hold(ifp);
>>   addrconf_dad_stop(ifp, 1);
>> - if (disable_ipv6)
>> + if (disable_ipv6) {
>> + in6_ifa_put(ifp);
>>   addrconf_ifdown(idev->dev, 0);
>> + goto unlock;
>> + }
>>   goto out;
>>   }
>>
>> @@ -3950,6 +3953,7 @@ static void addrconf_dad_work(struct work_struct *w)
>> ifp->dad_nonce);
>>  out:
>>   in6_ifa_put(ifp);
>> +unlock:
>>   rtnl_unlock();
>>  }
>>
>>
>

Re: [PATCH net] net: ipv6: Do not duplicate DAD on link up

[Andrey Konovalov]

On Tue, May 2, 2017 at 11:43 PM, David Ahern <dsah...@gmail.com> wrote:
> Andrey reported a warning triggered by the rcu code:
>
> [ cut here ]
> WARNING: CPU: 1 PID: 5911 at lib/debugobjects.c:289
> debug_print_object+0x175/0x210
> ODEBUG: activate active (active state 1) object type: rcu_head hint:
> (null)
> Modules linked in:
> CPU: 1 PID: 5911 Comm: a.out Not tainted 4.11.0-rc8+ #271
> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011
> Call Trace:
>  __dump_stack lib/dump_stack.c:16
>  dump_stack+0x192/0x22d lib/dump_stack.c:52
>  __warn+0x19f/0x1e0 kernel/panic.c:549
>  warn_slowpath_fmt+0xe0/0x120 kernel/panic.c:564
>  debug_print_object+0x175/0x210 lib/debugobjects.c:286
>  debug_object_activate+0x574/0x7e0 lib/debugobjects.c:442
>  debug_rcu_head_queue kernel/rcu/rcu.h:75
>  __call_rcu.constprop.76+0xff/0x9c0 kernel/rcu/tree.c:3229
>  call_rcu_sched+0x12/0x20 kernel/rcu/tree.c:3288
>  rt6_rcu_free net/ipv6/ip6_fib.c:158
>  rt6_release+0x1ea/0x290 net/ipv6/ip6_fib.c:188
>  fib6_del_route net/ipv6/ip6_fib.c:1461
>  fib6_del+0xa42/0xdc0 net/ipv6/ip6_fib.c:1500
>  __ip6_del_rt+0x100/0x160 net/ipv6/route.c:2174
>  ip6_del_rt+0x140/0x1b0 net/ipv6/route.c:2187
>  __ipv6_ifa_notify+0x269/0x780 net/ipv6/addrconf.c:5520
>  addrconf_ifdown+0xe60/0x1a20 net/ipv6/addrconf.c:3672
> ...
>
> Andrey's reproducer program runs in a very tight loop, calling
> 'unshare -n' and then spawning 2 sets of 14 threads running random ioctl
> calls. The relevant networking sequence:
>
> 1. New network namespace created via unshare -n
> - ip6tnl0 device is created in down state
>
> 2. address added to ip6tnl0
> - equivalent to ip -6 addr add dev ip6tnl0 fd00::bb/1
> - DAD is started on the address and when it completes the host
>   route is inserted into the FIB
>
> 3. ip6tnl0 is brought up
> - the new fixup_permanent_addr function restarts DAD on the address
>
> 4. exit namespace
> - teardown / cleanup sequence starts
> - once in a blue moon, lo teardown appears to happen BEFORE teardown
>   of ip6tunl0
>   + down on 'lo' removes the host route from the FIB since the dst->dev
> for the route is loobback
>   + host route added to rcu callback list
> * rcu callback has not run yet, so rt is NOT on the gc list so it has
>   NOT been marked obsolete
>
> 5. in parallel to 4. worker_thread runs addrconf_dad_completed
> - DAD on the address on ip6tnl0 completes
> - calls ipv6_ifa_notify which inserts the host route
>
> All of that happens very quickly. The result is that a host route that
> has been deleted from the IPv6 FIB and added to the RCU list is re-inserted
> into the FIB.
>
> The exit namespace eventually gets to cleaning up ip6tnl0 which removes the
> host route from the FIB again, calls the rcu function for cleanup -- and
> triggers the double rcu trace.
>
> The root cause is duplicate DAD on the address -- steps 2 and 3. Arguably,
> DAD should not be started in step 2. The interface is in the down state,
> so it can not really send out requests for the address which makes starting
> DAD pointless.
>
> Since the second DAD was introduced by a recent change, seems appropriate
> to use it for the Fixes tag and have the fixup function only start DAD for
> addresses in the PREDAD state which occurs in addrconf_ifdown if the
> address is retained.

Hi David,

Your patch fixes the issue for me.

I'll keep testing to see if all the reports related to fib6 are gone.

Tested-by: Andrey Konovalov <andreyk...@google.com>

Thanks!

>
> Big thanks to Andrey for isolating a reliable reproducer for this problem.
> Fixes: f1705ec197e7 ("net: ipv6: Make address flushing on ifdown optional")
> Reported-by: Andrey Konovalov <andreyk...@google.com>
> Signed-off-by: David Ahern <dsah...@gmail.com>
> ---
>  net/ipv6/addrconf.c | 5 +++--
>  1 file changed, 3 insertions(+), 2 deletions(-)
>
> diff --git a/net/ipv6/addrconf.c b/net/ipv6/addrconf.c
> index 67ec87ea5fb6..4fc4e8634e65 100644
> --- a/net/ipv6/addrconf.c
> +++ b/net/ipv6/addrconf.c
> @@ -3306,7 +3306,8 @@ static int fixup_permanent_addr(struct inet6_dev *idev,
>   idev->dev, 0, 0);
> }
>
> -   addrconf_dad_start(ifp);
> +   if (ifp->state == INET6_IFADDR_STATE_PREDAD)
> +   addrconf_dad_start(ifp);
>
> return 0;
>  }
> @@ -3656,7 +3657,7 @@ static int addrconf_ifdown(struct net_device *dev, int 
> how)
> !addr_is_local(>addr)) {
> /* set state to skip the notifier below */
> state = INET6_IFADDR_STATE_DEAD;
> -   ifa->state = 0;
> +   ifa->state = INET6_IFADDR_STATE_PREDAD;
> if (!(ifa->flags & IFA_F_NODAD))
> ifa->flags |= IFA_F_TENTATIVE;
>
> --
> 2.1.4
>

Re: x86: warning: kernel stack regs has bad 'bp' value

[Andrey Konovalov]

On Wed, May 3, 2017 at 2:48 PM, Andrey Konovalov <andreyk...@google.com> wrote:
> Hi,
>
> I've got the following error report while fuzzing the kernel with syzkaller.
>
> On commit 89c9fea3c8034cdb2fd745f551cde0b507fd6893 (4.11.0+).
>
> A reproducer and .config are attached.
>
> The reproducer open SCTP sockets and sends data to it in a loop.
> I'm not sure whether this is an issue with SCTP or with something else.

It seems that I get a bunch of these warning all over the place.

Attached another reproducer related to IPv6 UDP.

>
> WARNING: kernel stack regs at 8800686869f8 in a.out:4933 has bad
> 'bp' value c3fc855a10167ec0
> unwind stack type:0 next_sp:  (null) mask:0x6 graph_idx:0
> 88006ca06fa8: 88006ca07030 (0x88006ca07030)
> 88006ca06fb0: 8120e50e (__save_stack_trace+0x6e/0xd0)
> 88006ca06fb8:  ...
> 88006ca06fc0: 88006868 (0x88006868)
> 88006ca06fc8: 880068688000 (0x880068688000)
> 88006ca06fd0:  ...
> 88006ca06fd8: 0006 (0x6)
> 88006ca06fe0: 8800641d4200 (0x8800641d4200)
> 88006ca06fe8: 0101 (0x101)
> 88006ca06ff0:  ...
> 88006ca06ff8: 88006ca06fa8 (0x88006ca06fa8)
> 88006ca07000: 8800686869f8 (0x8800686869f8)
> 88006ca07008: 84d876ac (csum_partial_copy_generic+0x6c/0x170)
> 88006ca07010: 0100 (0x100)
> 88006ca07018: 880066031c00 (0x880066031c00)
> 88006ca07020: 880066031db8 (0x880066031db8)
> 88006ca07028: 8189df1d (file_free_rcu+0x6d/0xa0)
> 88006ca07030: 88006ca07040 (0x88006ca07040)
> 88006ca07038: 8120e586 (save_stack_trace+0x16/0x20)
> 88006ca07040: 88006ca07270 (0x88006ca07270)
> 88006ca07048: 8187aac3 (save_stack+0x43/0xd0)
> 88006ca07050: 004c (0x4c)
> 88006ca07058: 88006ca07068 (0x88006ca07068)
> 88006ca07060:  (0x)
> 88006ca07068: 8120e586 (save_stack_trace+0x16/0x20)
> 88006ca07070: 8187aac3 (save_stack+0x43/0xd0)
> 88006ca07078: 8187b3d3 (kasan_slab_free+0x73/0xc0)
> 88006ca07080: 81877052 (kmem_cache_free+0xb2/0x2c0)
> 88006ca07088: 8189df1d (file_free_rcu+0x6d/0xa0)
> 88006ca07090: 81495eeb (rcu_do_batch.isra.62+0x95b/0xc60)
> 88006ca07098: 81497afc (rcu_process_callbacks+0x2cc/0xb50)
> 88006ca070a0: 84dab1bb (__do_softirq+0x2fb/0xb99)
> 88006ca070a8: 812e10be (irq_exit+0x19e/0x1d0)
> 88006ca070b0: 84da97a6 (smp_apic_timer_interrupt+0x76/0xa0)
> 88006ca070b8: 84da4f73 (apic_timer_interrupt+0x93/0xa0)
> 88006ca070c0: 84d876ac (csum_partial_copy_generic+0x6c/0x170)
> 88006ca070c8: 0003 (0x3)
> 88006ca070d0: 8800641d4200 (0x8800641d4200)
> 88006ca070d8: dc00 (0xdc00)
> 88006ca070e0: 8800641d49e8 (0x8800641d49e8)
> 88006ca070e8: 88006ca07130 (0x88006ca07130)
> 88006ca070f0: 8141f8ef (mark_held_locks+0xaf/0x100)
> 88006ca070f8: 88006ca072b0 (0x88006ca072b0)
> 88006ca07100: 8802 (0x8802)
> 88006ca07108: 11000d940e28 (0x11000d940e28)
> 88006ca07110: 8800641d4200 (0x8800641d4200)
> 88006ca07118: 8187703d (kmem_cache_free+0x9d/0x2c0)
> 88006ca07120: 11000d940e44 (0x11000d940e44)
> 88006ca07128: dc00 (0xdc00)
> 88006ca07130: 88006ca07288 (0x88006ca07288)
> 88006ca07138: 8141fc72 (trace_hardirqs_on_caller+0x332/0x6b0)
> 88006ca07140: 41b58ab3 (0x41b58ab3)
> 88006ca07148: 85618d30 (__func__.52646+0x242f90/0x2e8860)
> 88006ca07150: 8141f940 (mark_held_locks+0x100/0x100)
> 88006ca07158: 8802 (0x8802)
> 88006ca07160: 11000d940e33 (0x11000d940e33)
> 88006ca07168: 8800641d4200 (0x8800641d4200)
> 88006ca07170: 81495f29 (rcu_do_batch.isra.62+0x999/0xc60)
> 88006ca07178: 11000d940e4f (0x11000d940e4f)
> 88006ca07180: dc00 (0xdc00)
> 88006ca07188: 88006ca072e0 (0x88006ca072e0)
> 88006ca07190: 8141fc72 (trace_hardirqs_on_caller+0x332/0x6b0)
> 88006ca07198: 41b58ab3 (0x41b58ab3)
> 88006ca071a0: 85618d30 (__func__.52646+0x242f90/0x2e8860)
> 88006ca071a8: 8141f940 (mark_held_locks+0x100/0x100)
> 88006ca071b0: 0a02 (0xa02)
> 88006ca071b8: 41b58ab3 (0x41b58ab3)
> 88006ca071c0:

Re: net/ipv6: use-after-free in __call_rcu/in6_dev_finish_destroy_rcu

[Andrey Konovalov]

On Tue, May 2, 2017 at 4:44 AM, David Ahern <d...@cumulusnetworks.com> wrote:
> On 4/26/17 9:15 AM, Andrey Konovalov wrote:
>> +David
>>
>> I've enabled CONFIG_DEBUG_OBJECTS_RCU_HEAD and this is what I get.
>>
>> Apparently the rcu warning is related to the fib6_del_route bug I've
>> been trying to reproduce:
>> https://groups.google.com/forum/#!msg/syzkaller/3SS80JbVPKA/2tfIAcW7DwAJ
>>
>> Adding David, who provided the fix:
>> https://patchwork.ozlabs.org/patch/754913/
>>
>> I've managed to extract a reproducer, attached together with the
>> .config that I used.
>>
>> On commit 5a7ad1146caa895ad718a534399e38bd2ba721b7 (4.11-rc8) with
>> David's patch applied.
>>
>> [ cut here ]
>> WARNING: CPU: 1 PID: 5911 at lib/debugobjects.c:289
>> debug_print_object+0x175/0x210
>> ODEBUG: activate active (active state 1) object type: rcu_head hint:
>> (null)
>> Modules linked in:
>> CPU: 1 PID: 5911 Comm: a.out Not tainted 4.11.0-rc8+ #271
>> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011
>> Call Trace:
>>  __dump_stack lib/dump_stack.c:16
>>  dump_stack+0x192/0x22d lib/dump_stack.c:52
>>  __warn+0x19f/0x1e0 kernel/panic.c:549
>>  warn_slowpath_fmt+0xe0/0x120 kernel/panic.c:564
>>  debug_print_object+0x175/0x210 lib/debugobjects.c:286
>>  debug_object_activate+0x574/0x7e0 lib/debugobjects.c:442
>>  debug_rcu_head_queue kernel/rcu/rcu.h:75
>>  __call_rcu.constprop.76+0xff/0x9c0 kernel/rcu/tree.c:3229
>>  call_rcu_sched+0x12/0x20 kernel/rcu/tree.c:3288
>>  rt6_rcu_free net/ipv6/ip6_fib.c:158
>>  rt6_release+0x1ea/0x290 net/ipv6/ip6_fib.c:188
>>  fib6_del_route net/ipv6/ip6_fib.c:1461
>
> I think I got to the bottom of this one.
>
> With your config, ip6_tunnel is compiled in.
>
> The program runs in a very tight loop, calling 'unshare -n' and then
> spawns 2 sets of 14 threads running random ioctl calls. The networking
> sequence:
>
> 1. New network namespace created via unshare -n
> - ip6tnl0 device is created in down state
>
> 2. address added to ip6tnl0 (equivalent to ip -6 addr add dev ip6tnl0
> fd00::bb/1)
> - the host route is created and inserted into FIB
>
> 3. ip6tnl0 is brought up - starts DAD on the address
>
> 4. exit namespace
> - teardown / cleanup sequence starts
> - lo teardown appears to happen BEFORE teardown of ip6tunl0
>   + removes host route from FIB
>   + host route added to rcu callback list: call_rcu(>dst.rcu_head,
> dst_rcu_free);
>   + rcu callback has not run yet, so rt is NOT on the gc list so it has
> NOT been marked obsolete
>
> 5. worker_thread runs addrconf_dad_completed
> - calls ipv6_ifa_notify which inserts the host route
>
> All of that happens very quickly. The result is that a route that has
> been deleted and added to the RCU list is re-inserted into the FIB. What
> happens next depends on order -- in this case the exit namespace
> eventually gets to cleaning up ip6tnl0 which removes the host route from
> the FIB, calls the rcu function for cleanup -- and triggers the double
> rcu trace.
>
> I have a hack that flags this sequence and prevents the re-insertion
> following DAD. That allows the command to run until it consumes all 2G
> of memory the VM has -- about 600+ iterations without triggering any
> stack traces.

Hi David,

Thanks for looking into this!

Do you have a patch that I could test?

I also reported another issue recently, that might also be related to this one:
https://groups.google.com/forum/#!topic/syzkaller/Rt0pgY4wfiw

Thanks!

Re: net/key: slab-out-of-bounds in pfkey_compile_policy

[Andrey Konovalov]

On Tue, May 2, 2017 at 6:45 PM, Andrey Konovalov <andreyk...@google.com> wrote:
> Hi,
>
> I've got the following error report while fuzzing the kernel with syzkaller.
>
> On commit d3b5d35290d729a2518af00feca867385a1b08fa (4.11).
>
> A reproducer and .config are attached.
>
> ==
> BUG: KASAN: slab-out-of-bounds in pfkey_compile_policy+0x8e6/0xd40 at
> addr 88006701f798
> Read of size 1280 by task a.out/4181
> CPU: 0 PID: 4181 Comm: a.out Not tainted 4.11.0+ #306
> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011
> Call Trace:
>  __dump_stack lib/dump_stack.c:16
>  dump_stack+0x292/0x395 lib/dump_stack.c:52
>  kasan_object_err+0x1c/0x70 mm/kasan/report.c:164
>  print_address_description mm/kasan/report.c:202
>  kasan_report_error mm/kasan/report.c:291
>  kasan_report+0x252/0x510 mm/kasan/report.c:347
>  check_memory_region_inline mm/kasan/kasan.c:326
>  check_memory_region+0x139/0x190 mm/kasan/kasan.c:333
>  memcpy+0x23/0x50 mm/kasan/kasan.c:368
>  pfkey_sadb2xfrm_user_sec_ctx net/key/af_key.c:474
>  pfkey_compile_policy+0x8e6/0xd40 net/key/af_key.c:3294
>  xfrm_user_policy+0x349/0x560 net/xfrm/xfrm_state.c:1892
>  do_ip_setsockopt.isra.12+0x1d05/0x38c0 net/ipv4/ip_sockglue.c:1175
>  ip_setsockopt+0x3a/0xb0 net/ipv4/ip_sockglue.c:1264
>  tcp_setsockopt+0x82/0xd0 net/ipv4/tcp.c:2732
>  sock_common_setsockopt+0x95/0xd0 net/core/sock.c:2750
>  SYSC_setsockopt net/socket.c:1798
>  SyS_setsockopt+0x270/0x3a0 net/socket.c:1777
>  entry_SYSCALL_64_fastpath+0x1f/0xbe arch/x86/entry/entry_64.S:204
> RIP: 0033:0x7f13a0968b79
> RSP: 002b:7fff131bc3f8 EFLAGS: 0206 ORIG_RAX: 0036
> RAX: ffda RBX: 7fff131bc550 RCX: 7f13a0968b79
> RDX: 0010 RSI:  RDI: 0003
> RBP: 004004e0 R08: 00c2 R09: 
> R10: 20a2ff3e R11: 0206 R12: 
> R13: 7fff131bc550 R14:  R15: 
> Object at 88006701f780, in cache kmalloc-256 size: 256
> Allocated:
> PID = 4181
>  save_stack_trace+0x16/0x20 arch/x86/kernel/stacktrace.c:59
>  save_stack+0x43/0xd0 mm/kasan/kasan.c:513
>  set_track mm/kasan/kasan.c:525
>  kasan_kmalloc+0xad/0xe0 mm/kasan/kasan.c:616
>  __kmalloc+0xa0/0x2d0 mm/slub.c:3745
>  kmalloc ./include/linux/slab.h:495
>  xfrm_user_policy+0xd8/0x560 net/xfrm/xfrm_state.c:1881
>  do_ip_setsockopt.isra.12+0x1d05/0x38c0 net/ipv4/ip_sockglue.c:1175
>  ip_setsockopt+0x3a/0xb0 net/ipv4/ip_sockglue.c:1264
>  tcp_setsockopt+0x82/0xd0 net/ipv4/tcp.c:2732
>  sock_common_setsockopt+0x95/0xd0 net/core/sock.c:2750
>  SYSC_setsockopt net/socket.c:1798
>  SyS_setsockopt+0x270/0x3a0 net/socket.c:1777
>  entry_SYSCALL_64_fastpath+0x1f/0xbe arch/x86/entry/entry_64.S:204
> Freed:
> PID = 3951
>  save_stack_trace+0x16/0x20 arch/x86/kernel/stacktrace.c:59
>  save_stack+0x43/0xd0 mm/kasan/kasan.c:513
>  set_track mm/kasan/kasan.c:525
>  kasan_slab_free+0x73/0xc0 mm/kasan/kasan.c:589
>  slab_free_hook mm/slub.c:1357
>  slab_free_freelist_hook mm/slub.c:1379
>  slab_free mm/slub.c:2961
>  kfree+0xe8/0x2b0 mm/slub.c:3882
>  free_bprm+0x19d/0x200 fs/exec.c:1382
>  do_execveat_common.isra.34+0x19ad/0x2220 fs/exec.c:1778
>  do_execve fs/exec.c:1813
>  SYSC_execve fs/exec.c:1894
>  SyS_execve+0x39/0x50 fs/exec.c:1889
>  do_syscall_64+0x2c7/0x7a0 arch/x86/entry/common.c:281
>  return_from_SYSCALL_64+0x0/0x7a arch/x86/entry/entry_64.S:246
> Memory state around the buggy address:
>  88006701f700: fb fb fb fb fb fb fb fb fc fc fc fc fc fc fc fc
>  88006701f780: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
>>88006701f800: 00 00 00 00 00 00 00 00 02 fc fc fc fc fc fc fc
>^
>  88006701f880: fc fc fc fc fc fc fc fc fb fb fb fb fb fb fb fb
>  88006701f900: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
> ==

+ syzkaller

net/key: slab-out-of-bounds in pfkey_compile_policy

[Andrey Konovalov]

Hi,

I've got the following error report while fuzzing the kernel with syzkaller.

On commit d3b5d35290d729a2518af00feca867385a1b08fa (4.11).

A reproducer and .config are attached.

==
BUG: KASAN: slab-out-of-bounds in pfkey_compile_policy+0x8e6/0xd40 at
addr 88006701f798
Read of size 1280 by task a.out/4181
CPU: 0 PID: 4181 Comm: a.out Not tainted 4.11.0+ #306
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011
Call Trace:
 __dump_stack lib/dump_stack.c:16
 dump_stack+0x292/0x395 lib/dump_stack.c:52
 kasan_object_err+0x1c/0x70 mm/kasan/report.c:164
 print_address_description mm/kasan/report.c:202
 kasan_report_error mm/kasan/report.c:291
 kasan_report+0x252/0x510 mm/kasan/report.c:347
 check_memory_region_inline mm/kasan/kasan.c:326
 check_memory_region+0x139/0x190 mm/kasan/kasan.c:333
 memcpy+0x23/0x50 mm/kasan/kasan.c:368
 pfkey_sadb2xfrm_user_sec_ctx net/key/af_key.c:474
 pfkey_compile_policy+0x8e6/0xd40 net/key/af_key.c:3294
 xfrm_user_policy+0x349/0x560 net/xfrm/xfrm_state.c:1892
 do_ip_setsockopt.isra.12+0x1d05/0x38c0 net/ipv4/ip_sockglue.c:1175
 ip_setsockopt+0x3a/0xb0 net/ipv4/ip_sockglue.c:1264
 tcp_setsockopt+0x82/0xd0 net/ipv4/tcp.c:2732
 sock_common_setsockopt+0x95/0xd0 net/core/sock.c:2750
 SYSC_setsockopt net/socket.c:1798
 SyS_setsockopt+0x270/0x3a0 net/socket.c:1777
 entry_SYSCALL_64_fastpath+0x1f/0xbe arch/x86/entry/entry_64.S:204
RIP: 0033:0x7f13a0968b79
RSP: 002b:7fff131bc3f8 EFLAGS: 0206 ORIG_RAX: 0036
RAX: ffda RBX: 7fff131bc550 RCX: 7f13a0968b79
RDX: 0010 RSI:  RDI: 0003
RBP: 004004e0 R08: 00c2 R09: 
R10: 20a2ff3e R11: 0206 R12: 
R13: 7fff131bc550 R14:  R15: 
Object at 88006701f780, in cache kmalloc-256 size: 256
Allocated:
PID = 4181
 save_stack_trace+0x16/0x20 arch/x86/kernel/stacktrace.c:59
 save_stack+0x43/0xd0 mm/kasan/kasan.c:513
 set_track mm/kasan/kasan.c:525
 kasan_kmalloc+0xad/0xe0 mm/kasan/kasan.c:616
 __kmalloc+0xa0/0x2d0 mm/slub.c:3745
 kmalloc ./include/linux/slab.h:495
 xfrm_user_policy+0xd8/0x560 net/xfrm/xfrm_state.c:1881
 do_ip_setsockopt.isra.12+0x1d05/0x38c0 net/ipv4/ip_sockglue.c:1175
 ip_setsockopt+0x3a/0xb0 net/ipv4/ip_sockglue.c:1264
 tcp_setsockopt+0x82/0xd0 net/ipv4/tcp.c:2732
 sock_common_setsockopt+0x95/0xd0 net/core/sock.c:2750
 SYSC_setsockopt net/socket.c:1798
 SyS_setsockopt+0x270/0x3a0 net/socket.c:1777
 entry_SYSCALL_64_fastpath+0x1f/0xbe arch/x86/entry/entry_64.S:204
Freed:
PID = 3951
 save_stack_trace+0x16/0x20 arch/x86/kernel/stacktrace.c:59
 save_stack+0x43/0xd0 mm/kasan/kasan.c:513
 set_track mm/kasan/kasan.c:525
 kasan_slab_free+0x73/0xc0 mm/kasan/kasan.c:589
 slab_free_hook mm/slub.c:1357
 slab_free_freelist_hook mm/slub.c:1379
 slab_free mm/slub.c:2961
 kfree+0xe8/0x2b0 mm/slub.c:3882
 free_bprm+0x19d/0x200 fs/exec.c:1382
 do_execveat_common.isra.34+0x19ad/0x2220 fs/exec.c:1778
 do_execve fs/exec.c:1813
 SYSC_execve fs/exec.c:1894
 SyS_execve+0x39/0x50 fs/exec.c:1889
 do_syscall_64+0x2c7/0x7a0 arch/x86/entry/common.c:281
 return_from_SYSCALL_64+0x0/0x7a arch/x86/entry/entry_64.S:246
Memory state around the buggy address:
 88006701f700: fb fb fb fb fb fb fb fb fc fc fc fc fc fc fc fc
 88006701f780: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
>88006701f800: 00 00 00 00 00 00 00 00 02 fc fc fc fc fc fc fc
   ^
 88006701f880: fc fc fc fc fc fc fc fc fb fb fb fb fb fb fb fb
 88006701f900: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
==
// autogenerated by syzkaller (http://github.com/google/syzkaller)

#ifndef __NR_mmap
#define __NR_mmap 9
#endif
#ifndef __NR_socket
#define __NR_socket 41
#endif
#ifndef __NR_setsockopt
#define __NR_setsockopt 54
#endif

#define _GNU_SOURCE

#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 

#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 

#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 

static uintptr_t execute_syscall(int nr, uintptr_t a0, uintptr_t a1,
 uintptr_t a2, uintptr_t a3,
 uintptr_t a4, uintptr_t a5,
 uintptr_t a6, uintptr_t a7,
 uintptr_t a8)
{
  switch (nr) {
  default:
return syscall(nr, a0, a1, a2, a3, a4, a5);
  }
}

long r[4];

void main()
{
  memset(r, -1, sizeof(r));
  r[0] = execute_syscall(__NR_mmap, 0x2000ul, 0xeed000ul, 0x3ul,
 0x32ul, 0xul, 0x0ul, 0, 0, 0);
  r[1] = 

Re: [PATCH net] tcp: do not underestimate skb->truesize in tcp_trim_head()

[Andrey Konovalov]

On Thu, Apr 27, 2017 at 2:15 AM, Eric Dumazet <eric.duma...@gmail.com> wrote:
> From: Eric Dumazet <eduma...@google.com>
>
> Andrey found a way to trigger the WARN_ON_ONCE(delta < len) in
> skb_try_coalesce() using syzkaller and a filter attached to a TCP
> socket over loopback interface.
>
> I believe one issue with looped skbs is that tcp_trim_head() can end up
> producing skb with under estimated truesize.
>
> It hardly matters for normal conditions, since packets sent over
> loopback are never truncated.
>
> Bytes trimmed from skb->head should not change skb truesize, since
> skb->head is not reallocated.

Hi Eric,

With all 3 of your patches applied to net-next I don't see the warning any more.

Thanks!

Tested-by: Andrey Konovalov <andreyk...@google.com>

>
> Signed-off-by: Eric Dumazet <eduma...@google.com>
> Reported-by: Andrey Konovalov <andreyk...@google.com>
> ---
>  net/ipv4/tcp_output.c |   19 ---
>  1 file changed, 12 insertions(+), 7 deletions(-)
>
> diff --git a/net/ipv4/tcp_output.c b/net/ipv4/tcp_output.c
> index 
> c3c082ed38796f65948e7a1042e37813b71d5abf..a85d863c44196e60fd22e25471cf773e72d2c133
>  100644
> --- a/net/ipv4/tcp_output.c
> +++ b/net/ipv4/tcp_output.c
> @@ -1267,7 +1267,7 @@ int tcp_fragment(struct sock *sk, struct sk_buff *skb, 
> u32 len,
>   * eventually). The difference is that pulled data not copied, but
>   * immediately discarded.
>   */
> -static void __pskb_trim_head(struct sk_buff *skb, int len)
> +static int __pskb_trim_head(struct sk_buff *skb, int len)
>  {
> struct skb_shared_info *shinfo;
> int i, k, eat;
> @@ -1277,7 +1277,7 @@ static void __pskb_trim_head(struct sk_buff *skb, int 
> len)
> __skb_pull(skb, eat);
> len -= eat;
> if (!len)
> -   return;
> +   return 0;
> }
> eat = len;
> k = 0;
> @@ -1303,23 +1303,28 @@ static void __pskb_trim_head(struct sk_buff *skb, int 
> len)
> skb_reset_tail_pointer(skb);
> skb->data_len -= len;
> skb->len = skb->data_len;
> +   return len;
>  }
>
>  /* Remove acked data from a packet in the transmit queue. */
>  int tcp_trim_head(struct sock *sk, struct sk_buff *skb, u32 len)
>  {
> +   u32 delta_truesize;
> +
> if (skb_unclone(skb, GFP_ATOMIC))
> return -ENOMEM;
>
> -   __pskb_trim_head(skb, len);
> +   delta_truesize = __pskb_trim_head(skb, len);
>
> TCP_SKB_CB(skb)->seq += len;
> skb->ip_summed = CHECKSUM_PARTIAL;
>
> -   skb->truesize-= len;
> -   sk->sk_wmem_queued   -= len;
> -   sk_mem_uncharge(sk, len);
> -   sock_set_flag(sk, SOCK_QUEUE_SHRUNK);
> +   if (delta_truesize) {
> +   skb->truesize  -= delta_truesize;
> +   sk->sk_wmem_queued -= delta_truesize;
> +   sk_mem_uncharge(sk, delta_truesize);
> +   sock_set_flag(sk, SOCK_QUEUE_SHRUNK);
> +   }
>
> /* Any change of skb->len requires recalculation of tso factor. */
> if (tcp_skb_pcount(skb) > 1)
>
>

Re: [PATCH net] net: adjust skb->truesize in ___pskb_trim()

[Andrey Konovalov]

On Wed, Apr 26, 2017 at 6:07 PM, Eric Dumazet <eric.duma...@gmail.com> wrote:
> From: Eric Dumazet <eduma...@google.com>
>
> Andrey found a way to trigger the WARN_ON_ONCE(delta < len) in
> skb_try_coalesce() using syzkaller and a filter attached to a TCP
> socket.
>
> As we did recently in commit 158f323b9868 ("net: adjust skb->truesize in
> pskb_expand_head()") we can adjust skb->truesize from ___pskb_trim(),
> via a call to skb_condense().
>
> If all frags were freed, then skb->truesize can be recomputed.
>
> This call can be done if skb is not yet owned, or destructor is
> sock_edemux().

Hi Eric,

I still see the warning even with your patch.

Thanks!

>
> Signed-off-by: Eric Dumazet <eduma...@google.com>
> Reported-by: Andrey Konovalov <andreyk...@google.com>
> Cc: Willem de Bruijn <will...@google.com>
> ---
>  net/core/skbuff.c |2 ++
>  1 file changed, 2 insertions(+)
>
> diff --git a/net/core/skbuff.c b/net/core/skbuff.c
> index 
> f86bf69cfb8d8bc17262cdba5d9f57a4726cd476..f1d04592ace02f32efa6e05df89c9a5e0023157f
>  100644
> --- a/net/core/skbuff.c
> +++ b/net/core/skbuff.c
> @@ -1576,6 +1576,8 @@ int ___pskb_trim(struct sk_buff *skb, unsigned int len)
> skb_set_tail_pointer(skb, len);
> }
>
> +   if (!skb->sk || skb->destructor == sock_edemux)
> +   skb_condense(skb);
> return 0;
>  }
>  EXPORT_SYMBOL(___pskb_trim);
>
>

Re: net/ipv6: use-after-free in __call_rcu/in6_dev_finish_destroy_rcu

[Andrey Konovalov]

On Wed, Apr 26, 2017 at 3:59 PM, Paul E. McKenney
<paul...@linux.vnet.ibm.com> wrote:
> On Wed, Apr 26, 2017 at 02:34:15PM +0200, Andrey Konovalov wrote:
>> Hi,
>>
>> I've got the following error report while fuzzing the kernel with syzkaller.
>>
>> On commit 5a7ad1146caa895ad718a534399e38bd2ba721b7 (4.11-rc8).
>>
>> Unfortunately it's not reproducible.
>>
>> I'm not sure whether is is an issue with rcu or ipv6.
>>
>> ==
>> BUG: KASAN: use-after-free in __call_rcu.constprop.77+0x13be/0x1640
>
> Does building with CONFIG_DEBUG_OBJECTS_RCU_HEAD=y show any splats?
> (Yeah, kind of a stupid question if it is not reproducible, but had
> to ask!)

Hi Paul,

I'll try enabling this config.

In the meantime, while I was trying to reproduce this issue, I got this warning:

[ cut here ]
WARNING: CPU: 0 PID: 4590 at kernel/rcu/tree.c:2919
rcu_do_batch.isra.65+0x845/0xbd0
Modules linked in:
CPU: 0 PID: 4590 Comm: syz-executor Not tainted 4.11.0-rc8+ #270
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011
Call Trace:
 
 __dump_stack lib/dump_stack.c:16
 dump_stack+0x192/0x22d lib/dump_stack.c:52
 __warn+0x19f/0x1e0 kernel/panic.c:549
 warn_slowpath_null+0x2c/0x40 kernel/panic.c:584
 rcu_do_batch.isra.65+0x845/0xbd0 kernel/rcu/tree.c:2919
 invoke_rcu_callbacks kernel/rcu/tree.c:3142
 __rcu_process_callbacks kernel/rcu/tree.c:3109
 rcu_process_callbacks+0x23f/0x810 kernel/rcu/tree.c:3126
 __do_softirq+0x253/0x78b kernel/softirq.c:284
 invoke_softirq kernel/softirq.c:364
 irq_exit+0x149/0x180 kernel/softirq.c:405
 exiting_irq ./arch/x86/include/asm/apic.h:657
 smp_apic_timer_interrupt+0x76/0xa0 arch/x86/kernel/apic/apic.c:962
 apic_timer_interrupt+0x89/0x90
RIP: 0010:do_anonymous_page mm/memory.c:2962
RIP: 0010:handle_pte_fault mm/memory.c:3721
RIP: 0010:__handle_mm_fault+0xdab/0x1c00 mm/memory.c:3841
RSP: 0018:88006a02f7d0 EFLAGS: 0246 ORIG_RAX: ff10
RAX: 0005dab0 RBX: 11000d405f00 RCX: 11000d28cd3f
RDX: dc00 RSI: 8025 RDI: 8800694669f8
RBP: 88006a02f9a8 R08: 014280ca R09: 11000d405eb0
R10: 88006a02f660 R11: dc00 R12: 88006a02f8e0
R13: 88006a02f980 R14: 8800694669b0 R15: 880069466a00
 
 handle_mm_fault+0x1aa/0x450 mm/memory.c:3878
 faultin_page mm/gup.c:408
 __get_user_pages+0x606/0x14a0 mm/gup.c:607
 populate_vma_page_range+0xd9/0x100 mm/gup.c:1062
 __mm_populate+0x278/0x540 mm/gup.c:1112
 mm_populate ./include/linux/mm.h:2132
 vm_mmap_pgoff+0x258/0x280 mm/util.c:314
 SYSC_mmap_pgoff mm/mmap.c:1503
 SyS_mmap_pgoff+0x22c/0x5e0 mm/mmap.c:1461
 SYSC_mmap arch/x86/kernel/sys_x86_64.c:96
 SyS_mmap+0x16/0x20 arch/x86/kernel/sys_x86_64.c:87
 entry_SYSCALL_64_fastpath+0x1a/0xa9 arch/x86/entry/entry_64.S:204
RIP: 0033:0x4458e9
RSP: 002b:7f3a15ce4b58 EFLAGS: 0282 ORIG_RAX: 0009
RAX: ffda RBX: 7f3a15ce5700 RCX: 004458e9
RDX: 0002 RSI: 009b8000 RDI: 2000
RBP:  R08:  R09: 8000
R10: 8032 R11: 0282 R12: 
R13:  R14: 7f3a15ce59c0 R15: 7f3a15ce5700
---[ end trace e36457085170396e ]---

>
> Thanx, Paul
>
>> kernel/rcu/tree.c:3269 at addr 88003b842280
>> Write of size 8 by task kworker/u10:1/180
>> CPU: 2 PID: 180 Comm: kworker/u10:1 Not tainted 4.11.0-rc8+ #270
>> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011
>> Workqueue: events_unbound call_usermodehelper_exec_work
>> Call Trace:
>>  __dump_stack lib/dump_stack.c:16 [inline]
>>  dump_stack+0x192/0x22d lib/dump_stack.c:52
>>  kasan_object_err+0x1c/0x70 mm/kasan/report.c:164
>>  print_address_description mm/kasan/report.c:202 [inline]
>>  kasan_report_error mm/kasan/report.c:291 [inline]
>>  kasan_report+0x252/0x510 mm/kasan/report.c:347
>>  __asan_report_store8_noabort+0x17/0x20 mm/kasan/report.c:373
>>  __call_rcu.constprop.77+0x13be/0x1640 kernel/rcu/tree.c:3269
>>  call_rcu_sched+0x12/0x20 kernel/rcu/tree.c:3288
>>  free_pid+0x446/0x5d0 kernel/pid.c:293
>>  __change_pid+0x2a1/0x3d0 kernel/pid.c:411
>>  detach_pid+0x1f/0x30 kernel/pid.c:416
>>  __unhash_process kernel/exit.c:74 [inline]
>>  __exit_signal kernel/exit.c:155 [inline]
>>  release_task+0xbb0/0x1d90 kernel/exit.c:199
>>  wait_task_zombie kernel/exit.c:1230 [inline]
>>  wait_consider_task+0x11fe/0x3410 kernel/exit.c:1458
>>  do_wait_thread kernel/exit.c:1521 [inline]
>>  do_wait+0x3ea/0x8e0 kernel/exit.c:1592
>>  SYSC_wait4 kernel/exit.c:1720 [inline]
>>  SyS_wait4+0x20

net/ipv6: use-after-free in __call_rcu/in6_dev_finish_destroy_rcu

[Andrey Konovalov]

Hi,

I've got the following error report while fuzzing the kernel with syzkaller.

On commit 5a7ad1146caa895ad718a534399e38bd2ba721b7 (4.11-rc8).

Unfortunately it's not reproducible.

I'm not sure whether is is an issue with rcu or ipv6.

==
BUG: KASAN: use-after-free in __call_rcu.constprop.77+0x13be/0x1640
kernel/rcu/tree.c:3269 at addr 88003b842280
Write of size 8 by task kworker/u10:1/180
CPU: 2 PID: 180 Comm: kworker/u10:1 Not tainted 4.11.0-rc8+ #270
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011
Workqueue: events_unbound call_usermodehelper_exec_work
Call Trace:
 __dump_stack lib/dump_stack.c:16 [inline]
 dump_stack+0x192/0x22d lib/dump_stack.c:52
 kasan_object_err+0x1c/0x70 mm/kasan/report.c:164
 print_address_description mm/kasan/report.c:202 [inline]
 kasan_report_error mm/kasan/report.c:291 [inline]
 kasan_report+0x252/0x510 mm/kasan/report.c:347
 __asan_report_store8_noabort+0x17/0x20 mm/kasan/report.c:373
 __call_rcu.constprop.77+0x13be/0x1640 kernel/rcu/tree.c:3269
 call_rcu_sched+0x12/0x20 kernel/rcu/tree.c:3288
 free_pid+0x446/0x5d0 kernel/pid.c:293
 __change_pid+0x2a1/0x3d0 kernel/pid.c:411
 detach_pid+0x1f/0x30 kernel/pid.c:416
 __unhash_process kernel/exit.c:74 [inline]
 __exit_signal kernel/exit.c:155 [inline]
 release_task+0xbb0/0x1d90 kernel/exit.c:199
 wait_task_zombie kernel/exit.c:1230 [inline]
 wait_consider_task+0x11fe/0x3410 kernel/exit.c:1458
 do_wait_thread kernel/exit.c:1521 [inline]
 do_wait+0x3ea/0x8e0 kernel/exit.c:1592
 SYSC_wait4 kernel/exit.c:1720 [inline]
 SyS_wait4+0x208/0x340 kernel/exit.c:1689
 call_usermodehelper_exec_sync kernel/kmod.c:292 [inline]
 call_usermodehelper_exec_work+0x1a7/0x2b0 kernel/kmod.c:329
 process_one_work+0x9f7/0x1580 kernel/workqueue.c:2097
 worker_thread+0x1df/0x14b0 kernel/workqueue.c:2231
 kthread+0x31f/0x3f0 kernel/kthread.c:231
 ret_from_fork+0x2c/0x40 arch/x86/entry/entry_64.S:430
Object at 88003b842018, in cache kmalloc-1024 size: 1024
Allocated:
PID = 1
 save_stack_trace+0x16/0x20 arch/x86/kernel/stacktrace.c:59
 save_stack+0x43/0xd0 mm/kasan/kasan.c:513
 set_track mm/kasan/kasan.c:525 [inline]
 kasan_kmalloc+0xad/0xe0 mm/kasan/kasan.c:616
 kmem_cache_alloc_trace+0x61/0x170 mm/slub.c:2745
 kmalloc include/linux/slab.h:490 [inline]
 kzalloc include/linux/slab.h:663 [inline]
 ipv6_add_dev+0x199/0x1380 net/ipv6/addrconf.c:380
 addrconf_init+0xd0/0x29a net/ipv6/addrconf.c:6405
 inet6_init+0x2f6/0x584 net/ipv6/af_inet6.c:962
 do_one_initcall+0xf3/0x380 init/main.c:792
 do_initcall_level init/main.c:858 [inline]
 do_initcalls init/main.c:866 [inline]
 do_basic_setup init/main.c:884 [inline]
 kernel_init_freeable+0x54d/0x622 init/main.c:1035
 kernel_init+0x13/0x180 init/main.c:959
 ret_from_fork+0x2c/0x40 arch/x86/entry/entry_64.S:430
Freed:
PID = 6479
 save_stack_trace+0x16/0x20 arch/x86/kernel/stacktrace.c:59
 save_stack+0x43/0xd0 mm/kasan/kasan.c:513
 set_track mm/kasan/kasan.c:525 [inline]
 kasan_slab_free+0x73/0xc0 mm/kasan/kasan.c:589
 slab_free_hook mm/slub.c:1357 [inline]
 slab_free_freelist_hook mm/slub.c:1379 [inline]
 slab_free mm/slub.c:2961 [inline]
 kfree+0x91/0x190 mm/slub.c:3882
 in6_dev_finish_destroy_rcu+0x97/0xc0 net/ipv6/addrconf_core.c:150
 __rcu_reclaim kernel/rcu/rcu.h:118 [inline]
 rcu_do_batch.isra.65+0x6de/0xbd0 kernel/rcu/tree.c:2879
 invoke_rcu_callbacks kernel/rcu/tree.c:3142 [inline]
 __rcu_process_callbacks kernel/rcu/tree.c:3109 [inline]
 rcu_process_callbacks+0x23f/0x810 kernel/rcu/tree.c:3126
 __do_softirq+0x253/0x78b kernel/softirq.c:284
Memory state around the buggy address:
 88003b842180: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
 88003b842200: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
>88003b842280: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
   ^
 88003b842300: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
 88003b842380: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
==

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

[Andrey Konovalov]

On Tue, Apr 25, 2017 at 6:36 PM, Andrey Konovalov <andreyk...@google.com> wrote:
> On Tue, Apr 25, 2017 at 5:56 PM, David Ahern <d...@cumulusnetworks.com> wrote:
>> On 3/4/17 11:57 AM, Dmitry Vyukov wrote:
>>> ==
>>> BUG: KASAN: slab-out-of-bounds in rt6_dump_route+0x293/0x2f0
>>> net/ipv6/route.c:3551 at addr 88007e523694
>>> Read of size 4 by task syz-executor3/24426
>>> CPU: 2 PID: 24426 Comm: syz-executor3 Not tainted 4.10.0+ #293
>>> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011
>>> Call Trace:
>>>  __dump_stack lib/dump_stack.c:16 [inline]
>>>  dump_stack+0x2fb/0x3fd lib/dump_stack.c:52
>>>  kasan_object_err+0x1c/0x90 mm/kasan/report.c:166
>>>  print_address_description mm/kasan/report.c:208 [inline]
>>>  kasan_report_error mm/kasan/report.c:292 [inline]
>>>  kasan_report.part.2+0x1b0/0x460 mm/kasan/report.c:314
>>>  kasan_report mm/kasan/report.c:334 [inline]
>>>  __asan_report_load4_noabort+0x29/0x30 mm/kasan/report.c:334
>>>  rt6_dump_route+0x293/0x2f0 net/ipv6/route.c:3551
>>>  fib6_dump_node+0x101/0x1a0 net/ipv6/ip6_fib.c:315
>>>  fib6_walk_continue+0x4b3/0x620 net/ipv6/ip6_fib.c:1576
>>>  fib6_walk+0x91/0xf0 net/ipv6/ip6_fib.c:1621
>>>  fib6_dump_table net/ipv6/ip6_fib.c:374 [inline]
>>>  inet6_dump_fib+0x832/0xea0 net/ipv6/ip6_fib.c:447
>>
>> My expectation is that this one is fixed with the ipv6 patch I have sent
>> (not yet committed). Are you seeing this backtrace with that patch?
>
> Before applying your patch I was hitting reports related to fib6 all the time.
> I've stopped seeing them for some time after I applied your patch.
> However today another one was triggered:

I'll keep fuzzing in the meantime to make sure.
Maybe I'll be able to collect more reports or even another reproducer.

>
> ==
> BUG: KASAN: slab-out-of-bounds in find_rr_leaf net/ipv6/route.c:722
> [inline] at addr 880033dddaa8
> BUG: KASAN: slab-out-of-bounds in rt6_select net/ipv6/route.c:758
> [inline] at addr 880033dddaa8
> BUG: KASAN: slab-out-of-bounds in ip6_pol_route+0x1b1e/0x1ba0
> net/ipv6/route.c:1091 at addr 880033dddaa8
> Read of size 4 by task syz-executor7/9808
> CPU: 2 PID: 9808 Comm: syz-executor7 Not tainted 4.11.0-rc8+ #268
> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011
> Call Trace:
>  __dump_stack lib/dump_stack.c:16 [inline]
>  dump_stack+0x192/0x22d lib/dump_stack.c:52
>  kasan_object_err+0x1c/0x70 mm/kasan/report.c:164
>  print_address_description mm/kasan/report.c:202 [inline]
>  kasan_report_error mm/kasan/report.c:291 [inline]
>  kasan_report+0x252/0x510 mm/kasan/report.c:347
>  __asan_report_load4_noabort+0x14/0x20 mm/kasan/report.c:367
>  find_rr_leaf net/ipv6/route.c:722 [inline]
>  rt6_select net/ipv6/route.c:758 [inline]
>  ip6_pol_route+0x1b1e/0x1ba0 net/ipv6/route.c:1091
>  ip6_pol_route_output+0x4c/0x60 net/ipv6/route.c:1212
>  fib6_rule_action+0x261/0x8a0 net/ipv6/fib6_rules.c:100
>  fib_rules_lookup+0x34b/0xae0 net/core/fib_rules.c:265
>  fib6_rule_lookup+0x175/0x360 net/ipv6/fib6_rules.c:44
>  ip6_route_output_flags+0x260/0x2f0 net/ipv6/route.c:1240
>  ip6_route_output include/net/ip6_route.h:79 [inline]
>  ip6_dst_lookup_tail+0xe59/0x1640 net/ipv6/ip6_output.c:959
>  ip6_dst_lookup_flow+0xb1/0x260 net/ipv6/ip6_output.c:1082
>  ip6_sk_dst_lookup_flow+0x2c6/0x7f0 net/ipv6/ip6_output.c:1113
>  udpv6_sendmsg+0x2350/0x3310 net/ipv6/udp.c:1219
>  inet_sendmsg+0x164/0x490 net/ipv4/af_inet.c:762
>  sock_sendmsg_nosec net/socket.c:633 [inline]
>  sock_sendmsg+0xca/0x110 net/socket.c:643
>  SYSC_sendto+0x660/0x810 net/socket.c:1696
>  SyS_sendto+0x40/0x50 net/socket.c:1664
>  entry_SYSCALL_64_fastpath+0x1a/0xa9
> RIP: 0033:0x4458d9
> RSP: 002b:7ff3a5343b58 EFLAGS: 0282 ORIG_RAX: 002c
> RAX: ffda RBX: 00708000 RCX: 004458d9
> RDX: 0fa8 RSI: 2000 RDI: 0005
> RBP: 4300 R08: 20006000 R09: 001c
> R10: 0004 R11: 0282 R12: 006e33c0
> R13: 0005 R14: 0029 R15: 0023
> Object at 880033ddd940, in cache ip_dst_cache size: 224
> Allocated:
> PID = 9717
>  save_stack_trace+0x16/0x20 arch/x86/kernel/stacktrace.c:59
>  save_stack+0x43/0xd0 mm/kasan/kasan.c:513
>  set_track mm/kasan/kasan.c:525 [inline]
>  kasan_kmalloc+0xad/0xe0 mm/kasan/kasan.c:616
>  kasan_slab_alloc+0x12/0x20 mm/kasan/kasan.c:555
>  slab_post_alloc_hook m

Re: [PATCH v3 net] net: ipv6: regenerate host route if moved to gc list

[Andrey Konovalov]

On Tue, Apr 25, 2017 at 5:54 PM, David Ahern <d...@cumulusnetworks.com> wrote:
> On 4/25/17 6:50 AM, Andrey Konovalov wrote:
>> I've been running syzkaller with your patch and got another report
>> from ip6_pol_route.
>
> In general the existing patch cleans up all of the ipv6 fib kasan and
> WARN_ON traces that were seen?

Before applying your patch I was hitting reports related to fib6 all the time.
I've stopped seeing them for some time after I applied your patch.
However today another one was triggered (the one I sent above).

>
>
>>
>> It happened only once so far and I couldn't reproduce it.
>
> Some similarity in the sense of a ipv4 route in the ipv6 fib. That's
> only going to happen if it hits the dst gc list and then back.
>
> This duplicates what Dmitry reported on March 3rd.

Re: [PATCH v3 net] net: ipv6: regenerate host route if moved to gc list

[Andrey Konovalov]

net/route.h:123 [inline]
 ip_route_output_flow+0x29/0xa0 net/ipv4/route.c:2477
 ip_route_output_key include/net/route.h:133 [inline]
 sctp_v4_get_dst+0x606/0x1420 net/sctp/protocol.c:458
 sctp_transport_route+0xa8/0x420 net/sctp/transport.c:287
 sctp_assoc_add_peer+0x5a5/0x1470 net/sctp/associola.c:656
 sctp_sendmsg+0x18a8/0x3b50 net/sctp/socket.c:1871
 inet_sendmsg+0x164/0x490 net/ipv4/af_inet.c:762
 sock_sendmsg_nosec net/socket.c:633 [inline]
 sock_sendmsg+0xca/0x110 net/socket.c:643
 SYSC_sendto+0x660/0x810 net/socket.c:1696
 SyS_sendto+0x40/0x50 net/socket.c:1664
 entry_SYSCALL_64_fastpath+0x1a/0xa9
Freed:
PID = 868
 save_stack_trace+0x16/0x20 arch/x86/kernel/stacktrace.c:59
 save_stack+0x43/0xd0 mm/kasan/kasan.c:513
 set_track mm/kasan/kasan.c:525 [inline]
 kasan_slab_free+0x73/0xc0 mm/kasan/kasan.c:589
 slab_free_hook mm/slub.c:1357 [inline]
 slab_free_freelist_hook mm/slub.c:1379 [inline]
 slab_free mm/slub.c:2961 [inline]
 kmem_cache_free+0x72/0x190 mm/slub.c:2983
 dst_destroy+0x24c/0x390 net/core/dst.c:269
 dst_free include/net/dst.h:428 [inline]
 rt_fibinfo_free net/ipv4/fib_semantics.c:155 [inline]
 free_fib_info_rcu+0x852/0xa10 net/ipv4/fib_semantics.c:214
 __rcu_reclaim kernel/rcu/rcu.h:118 [inline]
 rcu_do_batch.isra.65+0x6de/0xbd0 kernel/rcu/tree.c:2879
 invoke_rcu_callbacks kernel/rcu/tree.c:3142 [inline]
 __rcu_process_callbacks kernel/rcu/tree.c:3109 [inline]
 rcu_process_callbacks+0x23f/0x810 kernel/rcu/tree.c:3126
 __do_softirq+0x253/0x78b kernel/softirq.c:284
Memory state around the buggy address:
 880033ddd980: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
 880033ddda00: 00 00 00 00 fc fc fc fc fc fc fc fc fc fc fc fc
>880033ddda80: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
  ^
 880033dddb00: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
 880033dddb80: fc fc fc fc fc fc fc fc fb fb fb fb fb fb fb fb
==


>
> Fixes: f1705ec197e7 ("net: ipv6: Make address flushing on ifdown optional")
> Reported-by: Dmitry Vyukov <dvyu...@google.com>
> Reported-by: Andrey Konovalov <andreyk...@google.com>
> Signed-off-by: David Ahern <d...@cumulusnetworks.com>
> ---
> v3
> - removed 'if (prev)' and just call ip6_rt_put; added comment about spinlock
>
> v2
> - change ifp->rt under spinlock vs cmpxchg
> - add comment about rt6i_ref == 0
>
>  net/ipv6/addrconf.c | 15 +--
>  1 file changed, 13 insertions(+), 2 deletions(-)
>
> diff --git a/net/ipv6/addrconf.c b/net/ipv6/addrconf.c
> index 80ce478c4851..93f81d9cd85f 100644
> --- a/net/ipv6/addrconf.c
> +++ b/net/ipv6/addrconf.c
> @@ -3271,14 +3271,25 @@ static void addrconf_gre_config(struct net_device 
> *dev)
>  static int fixup_permanent_addr(struct inet6_dev *idev,
> struct inet6_ifaddr *ifp)
>  {
> -   if (!ifp->rt) {
> -   struct rt6_info *rt;
> +   /* rt6i_ref == 0 means the host route was removed from the
> +* FIB, for example, if 'lo' device is taken down. In that
> +* case regenerate the host route.
> +*/
> +   if (!ifp->rt || !atomic_read(>rt->rt6i_ref)) {
> +   struct rt6_info *rt, *prev;
>
> rt = addrconf_dst_alloc(idev, >addr, false);
> if (unlikely(IS_ERR(rt)))
> return PTR_ERR(rt);
>
> +   prev = ifp->rt;
> +
> +   /* ifp->rt can be accessed outside of rtnl */
> +   spin_lock(>lock);
> ifp->rt = rt;
> +   spin_unlock(>lock);
> +
> +   ip6_rt_put(prev);
> }
>
> if (!(ifp->flags & IFA_F_NOPREFIXROUTE)) {
> --
> 2.1.4
>

Re: net/ipv6: slab-out-of-bounds in ip6_tnl_xmit

[Andrey Konovalov]

On Tue, Apr 25, 2017 at 7:04 AM, Cong Wang <xiyou.wangc...@gmail.com> wrote:
> On Mon, Apr 24, 2017 at 9:47 AM, Cong Wang <xiyou.wangc...@gmail.com> wrote:
>>
>> We use ipv4 dst in ip6_tunnel and cast an IPv4 neigh key as an
>> IPv6 address...
>>
>>
>> neigh = dst_neigh_lookup(skb_dst(skb),
>>  _hdr(skb)->daddr);
>> if (!neigh)
>> goto tx_err_link_failure;
>>
>> addr6 = (struct in6_addr *)>primary_key; // <=== HERE
>> addr_type = ipv6_addr_type(addr6);
>>
>> if (addr_type == IPV6_ADDR_ANY)
>> addr6 = _hdr(skb)->daddr;
>>
>> memcpy(>daddr, addr6, sizeof(fl6->daddr));
>>
>> Also the network header of the skb at this point should be still IPv4?
>
> Please try the attached patch.

I don't see these crashes with your patch.

Thanks!

Tested-by: Andrey Konovalov <andreyk...@google.com>

>
> I am not sure how we could handle 4in6 case better than just relying on
> the config of ip6 tunnel.

Re: net/ipv6: slab-out-of-bounds in ip6_tnl_xmit

[Andrey Konovalov]

On Mon, Apr 24, 2017 at 5:03 PM, Andrey Konovalov <andreyk...@google.com> wrote:
> Hi,
>
> I've got the following error report while fuzzing the kernel with syzkaller.
>
> On commit 5a7ad1146caa895ad718a534399e38bd2ba721b7 (4.11-rc8).
>
> Unfortunately it's not reproducible.
>
> The issue might be similar to this one:
> https://groups.google.com/forum/#!topic/syzkaller/IDoQHFmrnRI
>
> ==
> BUG: KASAN: slab-out-of-bounds in ip6_tnl_xmit+0x25dd/0x28f0
> net/ipv6/ip6_tunnel.c:1078 at addr 88005dcc5f98
> Read of size 16 by task syz-executor7/8076
> CPU: 3 PID: 8076 Comm: syz-executor7 Not tainted 4.11.0-rc8+ #266
> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011
> Call Trace:
>  __dump_stack lib/dump_stack.c:16 [inline]
>  dump_stack+0x192/0x22d lib/dump_stack.c:52
>  kasan_object_err+0x1c/0x70 mm/kasan/report.c:164
>  print_address_description mm/kasan/report.c:202 [inline]
>  kasan_report_error mm/kasan/report.c:291 [inline]
>  kasan_report+0x252/0x510 mm/kasan/report.c:347
>  __asan_report_load_n_noabort+0xf/0x20 mm/kasan/report.c:378
>  ip6_tnl_xmit+0x25dd/0x28f0 net/ipv6/ip6_tunnel.c:1078
>  ip4ip6_tnl_xmit net/ipv6/ip6_tunnel.c:1268 [inline]
>  ip6_tnl_start_xmit+0xc1e/0x1890 net/ipv6/ip6_tunnel.c:1370
>  __netdev_start_xmit include/linux/netdevice.h:3980 [inline]
>  netdev_start_xmit include/linux/netdevice.h:3989 [inline]
>  xmit_one net/core/dev.c:2908 [inline]
>  dev_hard_start_xmit+0x213/0x800 net/core/dev.c:2924
>  __dev_queue_xmit+0x1abc/0x2580 net/core/dev.c:3391
>  dev_queue_xmit+0x17/0x20 net/core/dev.c:3424
>  neigh_direct_output+0x15/0x20 net/core/neighbour.c:1349
>  neigh_output include/net/neighbour.h:478 [inline]
>  ip_finish_output2+0x7cd/0x1020 net/ipv4/ip_output.c:228
>  ip_finish_output+0x83d/0xc30 net/ipv4/ip_output.c:316
>  NF_HOOK_COND include/linux/netfilter.h:246 [inline]
>  ip_output+0x1e7/0x5d0 net/ipv4/ip_output.c:404
>  dst_output include/net/dst.h:486 [inline]
>  ip_local_out+0x82/0xb0 net/ipv4/ip_output.c:124
>  ip_send_skb+0x3c/0xc0 net/ipv4/ip_output.c:1492
>  ip_push_pending_frames+0x64/0x80 net/ipv4/ip_output.c:1512
>  ping_v4_push_pending_frames net/ipv4/ping.c:653 [inline]
>  ping_v4_sendmsg+0x1b35/0x23e0 net/ipv4/ping.c:840
>  inet_sendmsg+0x164/0x490 net/ipv4/af_inet.c:762
>  sock_sendmsg_nosec net/socket.c:633 [inline]
>  sock_sendmsg+0xca/0x110 net/socket.c:643
>  SYSC_sendto+0x660/0x810 net/socket.c:1696
>  SyS_sendto+0x40/0x50 net/socket.c:1664
>  entry_SYSCALL_64_fastpath+0x1a/0xa9
> RIP: 0033:0x4458d9
> RSP: 002b:7f853159db58 EFLAGS: 0282 ORIG_RAX: 002c
> RAX: ffda RBX: 00708000 RCX: 004458d9
> RDX: 0008 RSI: 204f9fe1 RDI: 0017
> RBP: 3410 R08: 20235000 R09: 0010
> R10:  R11: 0282 R12: 006e24d0
> R13: 20ef8000 R14: 1000 R15: 0003
> Object at 88005dcc5e20, in cache kmalloc-512 size: 512
> Allocated:
> PID = 8076
>  save_stack_trace+0x16/0x20 arch/x86/kernel/stacktrace.c:59
>  save_stack+0x43/0xd0 mm/kasan/kasan.c:513
>  set_track mm/kasan/kasan.c:525 [inline]
>  kasan_kmalloc+0xad/0xe0 mm/kasan/kasan.c:616
>  __kmalloc+0x7c/0x1c0 mm/slub.c:3745
>  kmalloc include/linux/slab.h:495 [inline]
>  kzalloc include/linux/slab.h:663 [inline]
>  neigh_alloc net/core/neighbour.c:286 [inline]
>  __neigh_create+0x386/0x1da0 net/core/neighbour.c:458
>  neigh_create include/net/neighbour.h:313 [inline]
>  ipv4_neigh_lookup+0x4bb/0x730 net/ipv4/route.c:463
>  dst_neigh_lookup include/net/dst.h:447 [inline]
>  ip6_tnl_xmit+0x1598/0x28f0 net/ipv6/ip6_tunnel.c:1067
>  ip4ip6_tnl_xmit net/ipv6/ip6_tunnel.c:1268 [inline]
>  ip6_tnl_start_xmit+0xc1e/0x1890 net/ipv6/ip6_tunnel.c:1370
>  __netdev_start_xmit include/linux/netdevice.h:3980 [inline]
>  netdev_start_xmit include/linux/netdevice.h:3989 [inline]
>  xmit_one net/core/dev.c:2908 [inline]
>  dev_hard_start_xmit+0x213/0x800 net/core/dev.c:2924
>  __dev_queue_xmit+0x1abc/0x2580 net/core/dev.c:3391
>  dev_queue_xmit+0x17/0x20 net/core/dev.c:3424
>  neigh_direct_output+0x15/0x20 net/core/neighbour.c:1349
>  neigh_output include/net/neighbour.h:478 [inline]
>  ip_finish_output2+0x7cd/0x1020 net/ipv4/ip_output.c:228
>  ip_finish_output+0x83d/0xc30 net/ipv4/ip_output.c:316
>  NF_HOOK_COND include/linux/netfilter.h:246 [inline]
>  ip_output+0x1e7/0x5d0 net/ipv4/ip_output.c:404
>  dst_output include/net/dst.h:486 [inline]
>  ip_local_out+0x82/0xb0 net/ipv4/ip_output.c:124
>  ip_send_skb+0x3c/0xc0 net/ipv4/ip_output.c:1492
>  ip_push_pending_frames+0x64/0x80 net/ipv4/ip_output.c:15

net/ipv6: slab-out-of-bounds in ip6_tnl_xmit

[Andrey Konovalov]

Hi,

I've got the following error report while fuzzing the kernel with syzkaller.

On commit 5a7ad1146caa895ad718a534399e38bd2ba721b7 (4.11-rc8).

Unfortunately it's not reproducible.

The issue might be similar to this one:
https://groups.google.com/forum/#!topic/syzkaller/IDoQHFmrnRI

==
BUG: KASAN: slab-out-of-bounds in ip6_tnl_xmit+0x25dd/0x28f0
net/ipv6/ip6_tunnel.c:1078 at addr 88005dcc5f98
Read of size 16 by task syz-executor7/8076
CPU: 3 PID: 8076 Comm: syz-executor7 Not tainted 4.11.0-rc8+ #266
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011
Call Trace:
 __dump_stack lib/dump_stack.c:16 [inline]
 dump_stack+0x192/0x22d lib/dump_stack.c:52
 kasan_object_err+0x1c/0x70 mm/kasan/report.c:164
 print_address_description mm/kasan/report.c:202 [inline]
 kasan_report_error mm/kasan/report.c:291 [inline]
 kasan_report+0x252/0x510 mm/kasan/report.c:347
 __asan_report_load_n_noabort+0xf/0x20 mm/kasan/report.c:378
 ip6_tnl_xmit+0x25dd/0x28f0 net/ipv6/ip6_tunnel.c:1078
 ip4ip6_tnl_xmit net/ipv6/ip6_tunnel.c:1268 [inline]
 ip6_tnl_start_xmit+0xc1e/0x1890 net/ipv6/ip6_tunnel.c:1370
 __netdev_start_xmit include/linux/netdevice.h:3980 [inline]
 netdev_start_xmit include/linux/netdevice.h:3989 [inline]
 xmit_one net/core/dev.c:2908 [inline]
 dev_hard_start_xmit+0x213/0x800 net/core/dev.c:2924
 __dev_queue_xmit+0x1abc/0x2580 net/core/dev.c:3391
 dev_queue_xmit+0x17/0x20 net/core/dev.c:3424
 neigh_direct_output+0x15/0x20 net/core/neighbour.c:1349
 neigh_output include/net/neighbour.h:478 [inline]
 ip_finish_output2+0x7cd/0x1020 net/ipv4/ip_output.c:228
 ip_finish_output+0x83d/0xc30 net/ipv4/ip_output.c:316
 NF_HOOK_COND include/linux/netfilter.h:246 [inline]
 ip_output+0x1e7/0x5d0 net/ipv4/ip_output.c:404
 dst_output include/net/dst.h:486 [inline]
 ip_local_out+0x82/0xb0 net/ipv4/ip_output.c:124
 ip_send_skb+0x3c/0xc0 net/ipv4/ip_output.c:1492
 ip_push_pending_frames+0x64/0x80 net/ipv4/ip_output.c:1512
 ping_v4_push_pending_frames net/ipv4/ping.c:653 [inline]
 ping_v4_sendmsg+0x1b35/0x23e0 net/ipv4/ping.c:840
 inet_sendmsg+0x164/0x490 net/ipv4/af_inet.c:762
 sock_sendmsg_nosec net/socket.c:633 [inline]
 sock_sendmsg+0xca/0x110 net/socket.c:643
 SYSC_sendto+0x660/0x810 net/socket.c:1696
 SyS_sendto+0x40/0x50 net/socket.c:1664
 entry_SYSCALL_64_fastpath+0x1a/0xa9
RIP: 0033:0x4458d9
RSP: 002b:7f853159db58 EFLAGS: 0282 ORIG_RAX: 002c
RAX: ffda RBX: 00708000 RCX: 004458d9
RDX: 0008 RSI: 204f9fe1 RDI: 0017
RBP: 3410 R08: 20235000 R09: 0010
R10:  R11: 0282 R12: 006e24d0
R13: 20ef8000 R14: 1000 R15: 0003
Object at 88005dcc5e20, in cache kmalloc-512 size: 512
Allocated:
PID = 8076
 save_stack_trace+0x16/0x20 arch/x86/kernel/stacktrace.c:59
 save_stack+0x43/0xd0 mm/kasan/kasan.c:513
 set_track mm/kasan/kasan.c:525 [inline]
 kasan_kmalloc+0xad/0xe0 mm/kasan/kasan.c:616
 __kmalloc+0x7c/0x1c0 mm/slub.c:3745
 kmalloc include/linux/slab.h:495 [inline]
 kzalloc include/linux/slab.h:663 [inline]
 neigh_alloc net/core/neighbour.c:286 [inline]
 __neigh_create+0x386/0x1da0 net/core/neighbour.c:458
 neigh_create include/net/neighbour.h:313 [inline]
 ipv4_neigh_lookup+0x4bb/0x730 net/ipv4/route.c:463
 dst_neigh_lookup include/net/dst.h:447 [inline]
 ip6_tnl_xmit+0x1598/0x28f0 net/ipv6/ip6_tunnel.c:1067
 ip4ip6_tnl_xmit net/ipv6/ip6_tunnel.c:1268 [inline]
 ip6_tnl_start_xmit+0xc1e/0x1890 net/ipv6/ip6_tunnel.c:1370
 __netdev_start_xmit include/linux/netdevice.h:3980 [inline]
 netdev_start_xmit include/linux/netdevice.h:3989 [inline]
 xmit_one net/core/dev.c:2908 [inline]
 dev_hard_start_xmit+0x213/0x800 net/core/dev.c:2924
 __dev_queue_xmit+0x1abc/0x2580 net/core/dev.c:3391
 dev_queue_xmit+0x17/0x20 net/core/dev.c:3424
 neigh_direct_output+0x15/0x20 net/core/neighbour.c:1349
 neigh_output include/net/neighbour.h:478 [inline]
 ip_finish_output2+0x7cd/0x1020 net/ipv4/ip_output.c:228
 ip_finish_output+0x83d/0xc30 net/ipv4/ip_output.c:316
 NF_HOOK_COND include/linux/netfilter.h:246 [inline]
 ip_output+0x1e7/0x5d0 net/ipv4/ip_output.c:404
 dst_output include/net/dst.h:486 [inline]
 ip_local_out+0x82/0xb0 net/ipv4/ip_output.c:124
 ip_send_skb+0x3c/0xc0 net/ipv4/ip_output.c:1492
 ip_push_pending_frames+0x64/0x80 net/ipv4/ip_output.c:1512
 ping_v4_push_pending_frames net/ipv4/ping.c:653 [inline]
 ping_v4_sendmsg+0x1b35/0x23e0 net/ipv4/ping.c:840
 inet_sendmsg+0x164/0x490 net/ipv4/af_inet.c:762
 sock_sendmsg_nosec net/socket.c:633 [inline]
 sock_sendmsg+0xca/0x110 net/socket.c:643
 SYSC_sendto+0x660/0x810 net/socket.c:1696
 SyS_sendto+0x40/0x50 net/socket.c:1664
 entry_SYSCALL_64_fastpath+0x1a/0xa9
Freed:
PID = 7604
 save_stack_trace+0x16/0x20 arch/x86/kernel/stacktrace.c:59
 save_stack+0x43/0xd0 mm/kasan/kasan.c:513
 set_track mm/kasan/kasan.c:525 [inline]
 

Re: [PATCH v2 net] net: ipv6: regenerate host route if moved to gc list

[Andrey Konovalov]

On Sat, Apr 22, 2017 at 6:40 PM, David Ahern <d...@cumulusnetworks.com> wrote:
> Taking down the loopback device wreaks havoc on IPv6 routes. By
> extension, taking a VRF device wreaks havoc on its table.
>
> Dmitry and Andrey both reported heap out-of-bounds reports in the IPv6
> FIB code while running syzkaller fuzzer. The root cause is a dead dst
> that is on the garbage list gets reinserted into the IPv6 FIB. While on
> the gc (or perhaps when it gets added to the gc list) the dst->next is
> set to an IPv4 dst. A subsequent walk of the ipv6 tables causes the
> out-of-bounds access.
>
> Andrey's reproducer was the key to getting to the bottom of this.
>
> With IPv6, host routes for an address have the dst->dev set to the
> loopback device. When the 'lo' device is taken down, rt6_ifdown initiates
> a walk of the fib evicting routes with the 'lo' device which means all
> host routes are removed. That process moves the dst which is attached to
> an inet6_ifaddr to the gc list and marks it as dead.
>
> The recent change to keep global IPv6 addresses added a new function
> fixup_permanent_addr that is called on admin up. That function restarts
> dad for an inet6_ifaddr and when it completes the host route attached
> to it is inserted into the fib. Since the route was marked dead and
> moved to the gc list, we get the reported out-of-bounds accesses. If
> the device with the address is taken down or the address is removed, the
> WARN_ON in fib6_del is triggered.
>
> All of those faults are fixed by regenerating the host route of the
> existing one has been moved to the gc list, something that can be
> determined by checking if the rt6i_ref counter is 0.
>
> Fixes: f1705ec197e7 ("net: ipv6: Make address flushing on ifdown optional")
> Reported-by: Dmitry Vyukov <dvyu...@google.com>
> Reported-by: Andrey Konovalov <andreyk...@google.com>
> Signed-off-by: David Ahern <d...@cumulusnetworks.com>
> ---
> v2
> - change ifp->rt under spinlock vs cmpxchg
> - add comment about rt6i_ref == 0
>
> Dmitry / Andrey: can you guys add this patch to your tree and run
> syzkaller tests? I'd like to confirm that all of the fib traces
> are fixed. Thanks.

Tried fuzzing with your patch, I don't see any fib6 related reports
any more, so it should be good. I'll let you know if I see some
possibly related crashes.

Thanks!

>
>  net/ipv6/addrconf.c | 14 --
>  1 file changed, 12 insertions(+), 2 deletions(-)
>
> diff --git a/net/ipv6/addrconf.c b/net/ipv6/addrconf.c
> index 08f9e8ea7a81..97e86158bbcb 100644
> --- a/net/ipv6/addrconf.c
> +++ b/net/ipv6/addrconf.c
> @@ -3303,14 +3303,24 @@ static void addrconf_gre_config(struct net_device 
> *dev)
>  static int fixup_permanent_addr(struct inet6_dev *idev,
> struct inet6_ifaddr *ifp)
>  {
> -   if (!ifp->rt) {
> -   struct rt6_info *rt;
> +   /* rt6i_ref == 0 means the host route was removed from the
> +* FIB, for example, if 'lo' device is taken down. In that
> +* case regenerate the host route.
> +*/
> +   if (!ifp->rt || !atomic_read(>rt->rt6i_ref)) {
> +   struct rt6_info *rt, *prev;
>
> rt = addrconf_dst_alloc(idev, >addr, false);
> if (unlikely(IS_ERR(rt)))
> return PTR_ERR(rt);
>
> +   spin_lock(>lock);
> +   prev = ifp->rt;
> ifp->rt = rt;
> +   spin_unlock(>lock);
> +
> +   if (prev)
> +   ip6_rt_put(prev);
> }
>
> if (!(ifp->flags & IFA_F_NOPREFIXROUTE)) {
> --
> 2.1.4
>

Re: net: cleanup_net is slow

[Andrey Konovalov]

On Fri, Apr 21, 2017 at 9:45 PM, Florian Westphal  wrote:
> Florian Westphal  wrote:
>> Indeed.  Setting net.netfilter.nf_conntrack_default_on=0 cuts time
>> cleanup time by 2/3 ...
>>
>> nf unregister is way too happy to issue synchronize_net(), I'll work on
>> a fix.
>
> I'll test this patch as a start.  Maybe we can also leverage exit_batch
> more on netfilter side.

Hi Florian,

Your patch improves fuzzing speed at least twice, which is a great start!

Thanks!

>
> diff --git a/net/netfilter/core.c b/net/netfilter/core.c
> index a87a6f8a74d8..08fe1f526265 100644
> --- a/net/netfilter/core.c
> +++ b/net/netfilter/core.c
> @@ -126,14 +126,15 @@ int nf_register_net_hook(struct net *net, const struct 
> nf_hook_ops *reg)
>  }
>  EXPORT_SYMBOL(nf_register_net_hook);
>
> -void nf_unregister_net_hook(struct net *net, const struct nf_hook_ops *reg)
> +static struct nf_hook_entry *
> +__nf_unregister_net_hook(struct net *net, const struct nf_hook_ops *reg)
>  {
> struct nf_hook_entry __rcu **pp;
> struct nf_hook_entry *p;
>
> pp = nf_hook_entry_head(net, reg);
> if (WARN_ON_ONCE(!pp))
> -   return;
> +   return NULL;
>
> mutex_lock(_hook_mutex);
> for (; (p = nf_entry_dereference(*pp)) != NULL; pp = >next) {
> @@ -145,7 +146,7 @@ void nf_unregister_net_hook(struct net *net, const struct 
> nf_hook_ops *reg)
> mutex_unlock(_hook_mutex);
> if (!p) {
> WARN(1, "nf_unregister_net_hook: hook not found!\n");
> -   return;
> +   return NULL;
> }
>  #ifdef CONFIG_NETFILTER_INGRESS
> if (reg->pf == NFPROTO_NETDEV && reg->hooknum == NF_NETDEV_INGRESS)
> @@ -154,6 +155,17 @@ void nf_unregister_net_hook(struct net *net, const 
> struct nf_hook_ops *reg)
>  #ifdef HAVE_JUMP_LABEL
> static_key_slow_dec(_hooks_needed[reg->pf][reg->hooknum]);
>  #endif
> +
> +   return p;
> +}
> +
> +void nf_unregister_net_hook(struct net *net, const struct nf_hook_ops *reg)
> +{
> +   struct nf_hook_entry *p = __nf_unregister_net_hook(net, reg);
> +
> +   if (!p)
> +   return;
> +
> synchronize_net();
> nf_queue_nf_hook_drop(net, p);
> /* other cpu might still process nfqueue verdict that used reg */
> @@ -183,10 +195,36 @@ int nf_register_net_hooks(struct net *net, const struct 
> nf_hook_ops *reg,
>  EXPORT_SYMBOL(nf_register_net_hooks);
>
>  void nf_unregister_net_hooks(struct net *net, const struct nf_hook_ops *reg,
> -unsigned int n)
> +unsigned int hookcount)
>  {
> -   while (n-- > 0)
> -   nf_unregister_net_hook(net, [n]);
> +   struct nf_hook_entry *to_free[16];
> +   unsigned int i, n;
> +
> +   WARN_ON_ONCE(hookcount > ARRAY_SIZE(to_free));
> +
> + next_round:
> +   n = min_t(unsigned int, hookcount, ARRAY_SIZE(to_free));
> +
> +   for (i = 0; i < n; i++)
> +   to_free[i] = __nf_unregister_net_hook(net, [i]);
> +
> +   synchronize_net();
> +
> +   for (i = 0; i < n; i++) {
> +   if (to_free[i])
> +   nf_queue_nf_hook_drop(net, to_free[i]);
> +   }
> +
> +   synchronize_net();
> +
> +   for (i = 0; i < n; i++)
> +   kfree(to_free[i]);
> +
> +   if (n < hookcount) {
> +   hookcount -= n;
> +   reg += n;
> +   goto next_round;
> +   }
>  }
>  EXPORT_SYMBOL(nf_unregister_net_hooks);
>

Re: [PATCH net] ip6mr: fix notification device destruction

[Andrey Konovalov]

On Fri, Apr 21, 2017 at 8:30 PM, Nikolay Aleksandrov
<niko...@cumulusnetworks.com> wrote:
> On 21/04/17 20:42, Nikolay Aleksandrov wrote:
>> Andrey Konovalov reported a BUG caused by the ip6mr code which is caused
>> because we call unregister_netdevice_many for a device that is already
>> being destroyed. In IPv4's ipmr that has been resolved by two commits
>> long time ago by introducing the "notify" parameter to the delete
>> function and avoiding the unregister when called from a notifier, so
>> let's do the same for ip6mr.

Hi Nikolay,

Your patch fixes BUG_ON() being triggered for me.

Tested-by: Andrey Konovalov <andreyk...@google.com>

Thanks!

>>
>> The trace from Andrey:
>> [ cut here ]
>> kernel BUG at net/core/dev.c:6813!
>> invalid opcode:  [#1] SMP KASAN
>> Modules linked in:
>> CPU: 1 PID: 1165 Comm: kworker/u4:3 Not tainted 4.11.0-rc7+ #251
>> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs
>> 01/01/2011
>> Workqueue: netns cleanup_net
>> task: 880069208000 task.stack: 8800692d8000
>> RIP: 0010:rollback_registered_many+0x348/0xeb0 net/core/dev.c:6813
>> RSP: 0018:8800692de7f0 EFLAGS: 00010297
>> RAX: 880069208000 RBX: 0002 RCX: 0001
>> RDX:  RSI:  RDI: 88006af90569
>> RBP: 8800692de9f0 R08: 8800692dec60 R09: 
>> R10: 0006 R11:  R12: 88006af90070
>> R13: 8800692debf0 R14: dc00 R15: 88006af9
>> FS:  () GS:88006cb0()
>> knlGS:
>> CS:  0010 DS:  ES:  CR0: 80050033
>> CR2: 7fe7e897d870 CR3: 657e7000 CR4: 06e0
>> Call Trace:
>>  unregister_netdevice_many.part.105+0x87/0x440 net/core/dev.c:7881
>>  unregister_netdevice_many+0xc8/0x120 net/core/dev.c:7880
>>  ip6mr_device_event+0x362/0x3f0 net/ipv6/ip6mr.c:1346
>>  notifier_call_chain+0x145/0x2f0 kernel/notifier.c:93
>>  __raw_notifier_call_chain kernel/notifier.c:394
>>  raw_notifier_call_chain+0x2d/0x40 kernel/notifier.c:401
>>  call_netdevice_notifiers_info+0x51/0x90 net/core/dev.c:1647
>>  call_netdevice_notifiers net/core/dev.c:1663
>>  rollback_registered_many+0x919/0xeb0 net/core/dev.c:6841
>>  unregister_netdevice_many.part.105+0x87/0x440 net/core/dev.c:7881
>>  unregister_netdevice_many net/core/dev.c:7880
>>  default_device_exit_batch+0x4fa/0x640 net/core/dev.c:8333
>>  ops_exit_list.isra.4+0x100/0x150 net/core/net_namespace.c:144
>>  cleanup_net+0x5a8/0xb40 net/core/net_namespace.c:463
>>  process_one_work+0xc04/0x1c10 kernel/workqueue.c:2097
>>  worker_thread+0x223/0x19c0 kernel/workqueue.c:2231
>>  kthread+0x35e/0x430 kernel/kthread.c:231
>>  ret_from_fork+0x31/0x40 arch/x86/entry/entry_64.S:430
>> Code: 3c 32 00 0f 85 70 0b 00 00 48 b8 00 02 00 00 00 00 ad de 49 89
>> 47 78 e9 93 fe ff ff 49 8d 57 70 49 8d 5f 78 eb 9e e8 88 7a 14 fe <0f>
>> 0b 48 8b 9d 28 fe ff ff e8 7a 7a 14 fe 48 b8 00 00 00 00 00
>> RIP: rollback_registered_many+0x348/0xeb0 RSP: 8800692de7f0
>> ---[ end trace e0b29c57e9b3292c ]---
>>
>> Reported-by: Andrey Konovalov <andreyk...@google.com>
>> Signed-off-by: Nikolay Aleksandrov <niko...@cumulusnetworks.com>
>> ---
>
> +CC LKML and Linus
>
>> Andrey could you please test with this patch applied ?
>> I have run the reproducer locally and can no longer trigger the bug.
>> I've made "notify" an int instead of a bool only to be closer to the ipmr
>> code for easier future patches.
>>
>>  net/ipv6/ip6mr.c | 13 ++---
>>  1 file changed, 6 insertions(+), 7 deletions(-)
>>
>> diff --git a/net/ipv6/ip6mr.c b/net/ipv6/ip6mr.c
>> index fb4546e80c82..374997d26488 100644
>> --- a/net/ipv6/ip6mr.c
>> +++ b/net/ipv6/ip6mr.c
>> @@ -774,7 +774,8 @@ static struct net_device *ip6mr_reg_vif(struct net *net, 
>> struct mr6_table *mrt)
>>   *   Delete a VIF entry
>>   */
>>
>> -static int mif6_delete(struct mr6_table *mrt, int vifi, struct list_head 
>> *head)
>> +static int mif6_delete(struct mr6_table *mrt, int vifi, int notify,
>> +struct list_head *head)
>>  {
>>   struct mif_device *v;
>>   struct net_device *dev;
>> @@ -820,7 +821,7 @@ static int mif6_delete(struct mr6_table *mrt, int vifi, 
>> struct list_head *head)
>>dev->ifindex, _dev->cnf);
>>   }
>>
>> - if (v->flags &am

net/rose: null-ptr-deref in rose_route_frame

[Andrey Konovalov]

Hi,

I've got the following error report while fuzzing the kernel with syzkaller.

On commit 4f7d029b9bf009fbee76bb10c0c4351a1870d2f3 (4.11-rc7).

rose_xmit calls rose_route_frame(skb, ax25 = NULL), and
rose_route_frame then dereferences ax25 when doing
ax25cmp(>dest_addr, _neigh->callsign).

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: 1 PID: 15 Comm: ksoftirqd/1 Not tainted 4.11.0-rc7+ #251
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011
task: 88003e10adc0 task.stack: 88003e148000
RIP: 0010:ax25cmp+0x3f/0x150 net/ax25/ax25_addr.c:122
RSP: 0018:88003e14d450 EFLAGS: 00010202
RAX: 88003e10adc0 RBX: 880069c606b8 RCX: 0002
RDX: 0100 RSI: 0007 RDI: 0017
RBP: 88003e14d488 R08: dc00 R09: 
R10: 6a8a172cb651d699 R11: dc00 R12: dc00
R13: 001d R14: 880069c606c0 R15: 0017
FS:  () GS:88003ed0() knlGS:
CS:  0010 DS:  ES:  CR0: 80050033
CR2: 2044ef69 CR3: 5682b000 CR4: 06e0
Call Trace:
 rose_route_frame+0x3b1/0x19f0 net/rose/rose_route.c:883
 rose_xmit+0x7f/0x180 net/rose/rose_dev.c:110
 __netdev_start_xmit include/linux/netdevice.h:3980 [inline]
 netdev_start_xmit include/linux/netdevice.h:3989 [inline]
 xmit_one net/core/dev.c:2908 [inline]
 dev_hard_start_xmit+0x24e/0xac0 net/core/dev.c:2924
 __dev_queue_xmit+0x1ff8/0x2840 net/core/dev.c:3391
 dev_queue_xmit+0x17/0x20 net/core/dev.c:3424
 bond_dev_queue_xmit+0x185/0x240 drivers/net/bonding/bond_main.c:261
 bond_xmit_slave_id+0x1fe/0x590 drivers/net/bonding/bond_main.c:3702
 bond_xmit_roundrobin drivers/net/bonding/bond_main.c:3779 [inline]
 __bond_start_xmit drivers/net/bonding/bond_main.c:4037 [inline]
 bond_start_xmit+0xb8a/0x17f0 drivers/net/bonding/bond_main.c:4071
 __netdev_start_xmit include/linux/netdevice.h:3980 [inline]
 netdev_start_xmit include/linux/netdevice.h:3989 [inline]
 xmit_one net/core/dev.c:2908 [inline]
 dev_hard_start_xmit+0x24e/0xac0 net/core/dev.c:2924
 __dev_queue_xmit+0x1ff8/0x2840 net/core/dev.c:3391
 dev_queue_xmit+0x17/0x20 net/core/dev.c:3424
 neigh_connected_output+0x534/0x790 net/core/neighbour.c:1338
 neigh_output include/net/neighbour.h:478 [inline]
 ip6_finish_output2+0xbf8/0x2560 net/ipv6/ip6_output.c:123
 ip6_finish_output+0x302/0x960 net/ipv6/ip6_output.c:149
 NF_HOOK_COND include/linux/netfilter.h:246 [inline]
 ip6_output+0x1cb/0x8d0 net/ipv6/ip6_output.c:163
 dst_output include/net/dst.h:486 [inline]
 NF_HOOK.constprop.39+0x115/0x650 include/linux/netfilter.h:257
 mld_sendpack+0x6fc/0xd40 net/ipv6/mcast.c:1660
 mld_send_cr net/ipv6/mcast.c:1951 [inline]
 mld_ifc_timer_expire+0x3c3/0x750 net/ipv6/mcast.c:2449
 call_timer_fn+0x23f/0x810 kernel/time/timer.c:1268
 expire_timers kernel/time/timer.c:1307 [inline]
 __run_timers+0x94e/0xcd0 kernel/time/timer.c:1601
 run_timer_softirq+0x21/0x80 kernel/time/timer.c:1614
 __do_softirq+0x2fb/0xb7d kernel/softirq.c:284
 run_ksoftirqd+0x20/0x60 kernel/softirq.c:676
 smpboot_thread_fn+0x562/0x860 kernel/smpboot.c:164
 kthread+0x35e/0x430 kernel/kthread.c:231
 ret_from_fork+0x31/0x40 arch/x86/entry/entry_64.S:430
Code: 49 89 f6 49 bc 00 00 00 00 00 fc ff df 48 83 ec 10 48 89 7d c8
48 89 75 d0 e8 4e 4a 57 fd 4c 89 f9 4c 89 fe 48 c1 e9 03 83 e6 07 <42>
0f b6 0c 21 40 38 f1 7f 08 84 c9 0f 85 ef 00 00 00 4c 89 f1
RIP: ax25cmp+0x3f/0x150 net/ax25/ax25_addr.c:122 RSP: 88003e14d450
---[ end trace f569731c3e601819 ]---
Kernel panic - not syncing: Fatal exception in interrupt
Dumping ftrace buffer:
   (ftrace buffer empty)
Kernel Offset: disabled
Rebooting in 86400 seconds..

Re: net/xfrm: stack-out-of-bounds in xfrm_state_find

[Andrey Konovalov]

On Thu, Apr 20, 2017 at 6:47 PM, Andrey Konovalov <andreyk...@google.com> wrote:
> Hi,
>
> I've got the following error report while fuzzing the kernel with syzkaller.
>
> On linux-next commit 4f7d029b9bf009fbee76bb10c0c4351a1870d2f3 (4.11-rc7).
>
> A reproducer and .config are attached.
>
> ==
> BUG: KASAN: stack-out-of-bounds in xfrm_state_find+0x2ce7/0x2f70 at
> addr 88006654f790
> Read of size 4 by task a.out/4065
> page:ea00019953c0 count:0 mapcount:0 mapping:  (null) index:0x0
> flags: 0x100()
> raw: 0100   
> raw:  ea00019953e0  
> page dumped because: kasan: bad access detected
> CPU: 1 PID: 4065 Comm: a.out Not tainted 4.11.0-rc7+ #251
> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011
> Call Trace:
>  __dump_stack lib/dump_stack.c:16
>  dump_stack+0x292/0x398 lib/dump_stack.c:52
>  kasan_report_error mm/kasan/report.c:212
>  kasan_report+0x4d8/0x510 mm/kasan/report.c:347
>  __asan_report_load4_noabort+0x14/0x20 mm/kasan/report.c:367
>  xfrm_state_find+0x2ce7/0x2f70 net/xfrm/xfrm_state.c:897

I'm not sure if the line numbers in the report are correct.

My guess is that the guilty line is actually this one:

h = xfrm_dst_hash(net, daddr, saddr, tmpl->reqid, encap_family);

but I might be wrong.

>  xfrm_tmpl_resolve_one net/xfrm/xfrm_policy.c:1470
>  xfrm_tmpl_resolve+0x308/0xc90 net/xfrm/xfrm_policy.c:1514
>  xfrm_resolve_and_create_bundle+0x16e/0x2590 net/xfrm/xfrm_policy.c:1889
>  xfrm_lookup+0xd72/0x1170 net/xfrm/xfrm_policy.c:2253
>  xfrm_lookup_route+0x39/0x1a0 net/xfrm/xfrm_policy.c:2375
>  ip_route_output_flow+0x7f/0xa0 net/ipv4/route.c:2483
>  udp_sendmsg+0x1565/0x2cd0 net/ipv4/udp.c:1015
>  udpv6_sendmsg+0x8af/0x3500 net/ipv6/udp.c:1083
>  inet_sendmsg+0x164/0x5b0 net/ipv4/af_inet.c:762
>  sock_sendmsg_nosec net/socket.c:633
>  sock_sendmsg+0xca/0x110 net/socket.c:643
>  SYSC_sendto+0x660/0x810 net/socket.c:1696
>  SyS_sendto+0x40/0x50 net/socket.c:1664
>  entry_SYSCALL_64_fastpath+0x1f/0xc2 arch/x86/entry/entry_64.S:204
> RIP: 0033:0x7f3daefd0b79
> RSP: 002b:7ffdb39bb0b8 EFLAGS: 0206 ORIG_RAX: 002c
> RAX: ffda RBX: 7ffdb39bb210 RCX: 7f3daefd0b79
> RDX:  RSI: 20001000 RDI: 0003
> RBP: 004004a0 R08: 20013ff0 R09: 0010
> R10: 2000 R11: 0206 R12: 
> R13: 7ffdb39bb210 R14:  R15: 
> Memory state around the buggy address:
>  88006654f680: f1 f1 f1 00 f2 f2 f2 f2 f2 f2 f2 f8 f2 f2 f2 f2
>  88006654f700: f2 f2 f2 00 00 00 00 f2 f2 f2 f2 00 00 00 00 00
>>88006654f780: 00 00 f2 f2 f2 f2 f2 00 00 00 00 00 00 00 00 00
>  ^
>  88006654f800: f2 f2 f2 f3 f3 f3 f3 00 00 00 00 00 00 00 00 00
>  88006654f880: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> ==

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

[Andrey Konovalov]

On Thu, Apr 20, 2017 at 5:39 PM, Andrey Konovalov <andreyk...@google.com> wrote:
> On Thu, Apr 20, 2017 at 5:35 PM, David Ahern <d...@cumulusnetworks.com> wrote:
>> On 4/20/17 9:28 AM, Andrey Konovalov wrote:
>>> This one seems to be much closer to what Dmitry reported intially.
>>
>> does not repro here; I ran in a loop and nothing.

Here's strace log, maybe it'll help figuring out why it doesn't reproduce:

# strace ./a.out
...
socket(PF_INET6, SOCK_RAW, IPPROTO_TCP) = 3
ioctl(3, SIOCSIFFLAGS, {ifr_name="lo",
ifr_flags=IFF_UP|IFF_PROMISC|IFF_ALLMULTI|0x8000}) = 0
socket(PF_INET6, SOCK_RAW|SOCK_CLOEXEC, 0x2b /* IPPROTO_??? */) = 4
socket(PF_INET6, SOCK_DGRAM|SOCK_NONBLOCK, IPPROTO_IP) = 5
ioctl(5, SIOCGIFINDEX, {ifr_name="ip6_vti0", ifr_index=26}) = 0
ioctl(4, SIOCSIFADDR, {ifr_name="?", ifr_addr={AF_X25,
"\0\0\32\0\0\0\254*b\333\263\177\0\0"}}) = 0
socket(PF_INET6, SOCK_STREAM|SOCK_NONBLOCK, 0x84 /* IPPROTO_??? */) = 6
ioctl(6, SIOCSIFFLAGS, {ifr_name="lo", ifr_flags=0x8000 /* IFF_??? */}) = 0
socket(PF_INET6, SOCK_RAW, 0x3 /* IPPROTO_??? */) = 7
ioctl(7, SIOCSIFFLAGS, {ifr_name="ip6_vti0",
ifr_flags=IFF_UP|IFF_PROMISC|IFF_ALLMULTI|0x8000}) = 0
ioctl(3, SIOCSIFFLAGS, {ifr_name="lo",
ifr_flags=IFF_UP|IFF_PROMISC|IFF_ALLMULTI|0x8000}) = 0
ioctl(6, SIOCSIFFLAGS, {ifr_name="lo", ifr_flags=0x8000 /* IFF_??? */}) = 0
exit_group(0)   = ?

>
> You use the attached config, right?
>
>>
>> can you send output of "sysctl -a --pattern 'net.ipv6'"
>
> Uploaded here:
> https://gist.github.com/xairy/7b6988c9cd8fda5458005df05584ff27

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

[Andrey Konovalov]

On Thu, Apr 20, 2017 at 5:35 PM, David Ahern <d...@cumulusnetworks.com> wrote:
> On 4/20/17 9:28 AM, Andrey Konovalov wrote:
>> This one seems to be much closer to what Dmitry reported intially.
>
> does not repro here; I ran in a loop and nothing.

You use the attached config, right?

>
> can you send output of "sysctl -a --pattern 'net.ipv6'"

Uploaded here:
https://gist.github.com/xairy/7b6988c9cd8fda5458005df05584ff27

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

[Andrey Konovalov]

On Thu, Apr 20, 2017 at 5:28 PM, Andrey Konovalov <andreyk...@google.com> wrote:
> I've extracted a reproducer for another bug.

It works for me as is, but you might need to run it in a loop.

>
> This one seems to be much closer to what Dmitry reported intially.
>
> [ cut here ]
> WARNING: CPU: 1 PID: 3892 at net/ipv6/ip6_fib.c:1472 fib6_del+0xa60/0xdc0
> Modules linked in:
> CPU: 1 PID: 3892 Comm: a.out Not tainted 4.11.0-rc7+ #251
> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011
> Call Trace:
>  __dump_stack lib/dump_stack.c:16
>  dump_stack+0x292/0x398 lib/dump_stack.c:52
>  __warn+0x19f/0x1e0 kernel/panic.c:549
>  warn_slowpath_null+0x2c/0x40 kernel/panic.c:584
>  fib6_del+0xa60/0xdc0 net/ipv6/ip6_fib.c:1472
>  fib6_clean_node+0x3ce/0x550 net/ipv6/ip6_fib.c:1652
>  fib6_walk_continue+0x577/0x760 net/ipv6/ip6_fib.c:1578
>  fib6_walk+0x91/0xf0 net/ipv6/ip6_fib.c:1623
>  fib6_clean_tree+0x266/0x3c0 net/ipv6/ip6_fib.c:1695
>  __fib6_clean_all+0x1f7/0x3b0 net/ipv6/ip6_fib.c:1711
>  fib6_clean_all+0x27/0x30 net/ipv6/ip6_fib.c:1722
>  rt6_ifdown+0xf7/0x910 net/ipv6/route.c:2820
>  addrconf_ifdown+0x1a3/0x1aa0 net/ipv6/addrconf.c:3541
>  addrconf_notify+0x1bb/0x2570 net/ipv6/addrconf.c:3466
>  notifier_call_chain+0x145/0x2f0 kernel/notifier.c:93
>  __raw_notifier_call_chain kernel/notifier.c:394
>  raw_notifier_call_chain+0x2d/0x40 kernel/notifier.c:401
>  call_netdevice_notifiers_info+0x51/0x90 net/core/dev.c:1647
>  call_netdevice_notifiers net/core/dev.c:1663
>  __dev_notify_flags+0x1fd/0x320 net/core/dev.c:6499
>  dev_change_flags+0xf5/0x140 net/core/dev.c:6530
>  dev_ifsioc+0x62a/0x9f0 net/core/dev_ioctl.c:254
>  dev_ioctl+0x249/0x1160 net/core/dev_ioctl.c:532
>  sock_do_ioctl+0x94/0xb0 net/socket.c:913
>  sock_ioctl+0x28f/0x440 net/socket.c:1004
>  vfs_ioctl fs/ioctl.c:45
>  do_vfs_ioctl+0x1bf/0x1780 fs/ioctl.c:685
>  SYSC_ioctl fs/ioctl.c:700
>  SyS_ioctl+0x8f/0xc0 fs/ioctl.c:691
>  entry_SYSCALL_64_fastpath+0x1f/0xc2 arch/x86/entry/entry_64.S:204
> RIP: 0033:0x7f575ded4347
> RSP: 002b:7fffc94d9948 EFLAGS: 0217 ORIG_RAX: 0010
> RAX: ffda RBX: 7fffc94d9b30 RCX: 7f575ded4347
> RDX: 7fffc94d9980 RSI: 8914 RDI: 0006
> RBP: 004004e0 R08: 0028 R09: 0101010101010101
> R10:  R11: 0217 R12: 
> R13: 7fffc94d9b30 R14:  R15: 
> ---[ end trace 9bda4459ad907043 ]---

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

[Andrey Konovalov]

On Thu, Apr 20, 2017 at 10:35 AM, Dmitry Vyukov <dvyu...@google.com> wrote:
> On Thu, Apr 20, 2017 at 1:51 AM, David Ahern <d...@cumulusnetworks.com> wrote:
>> On 4/19/17 5:47 PM, Cong Wang wrote:
>>> On Wed, Apr 19, 2017 at 9:12 AM, Andrey Konovalov <andreyk...@google.com> 
>>> wrote:
>>>>
>>>> Anyway, I just finished simplifying the reproducer. Give this one a try.
>>>
>>> Thanks for providing such a minimal reproducer!
>>>
>>> The following patch could fix this crash, but I am not 100% sure if we 
>>> should
>>> just clear these bits or reject them with an errno.
>>>
>>> diff --git a/net/ipv6/route.c b/net/ipv6/route.c
>>> index 9db14189..cf524c2 100644
>>> --- a/net/ipv6/route.c
>>> +++ b/net/ipv6/route.c
>>> @@ -2086,7 +2086,7 @@ static struct rt6_info
>>> *ip6_route_info_create(struct fib6_config *cfg)
>>> } else
>>> rt->rt6i_prefsrc.plen = 0;
>>>
>>> -   rt->rt6i_flags = cfg->fc_flags;
>>> +   rt->rt6i_flags = cfg->fc_flags & ~(RTF_PCPU | RTF_CACHE);
>>>
>>>  install_route:
>>> rt->dst.dev = dev;
>>>
>>
>> I sent a patch returning EINVAL if RTF_PCPU is set in fc_flags
>
>
> Andrey, does it fix the other crashes?

No, still see them.

I'm working on reproducing those.

Re: [PATCH net] net: ipv6: RTF_PCPU should not be settable from userspace

[Andrey Konovalov]

Thanks!

Tested-by: Andrey Konovalov <andreyk...@google.com>

On Wed, Apr 19, 2017 at 11:52 PM, Martin KaFai Lau <ka...@fb.com> wrote:
> On Wed, Apr 19, 2017 at 02:19:43PM -0700, David Ahern wrote:
>> Andrey reported a fault in the IPv6 route code:
>>
>> kasan: GPF could be caused by NULL-ptr deref or user memory access
>> general protection fault:  [#1] SMP KASAN
>> Modules linked in:
>> CPU: 1 PID: 4035 Comm: a.out Not tainted 4.11.0-rc7+ #250
>> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011
>> task: 880069809600 task.stack: 880062dc8000
>> RIP: 0010:ip6_rt_cache_alloc+0xa6/0x560 net/ipv6/route.c:975
>> RSP: 0018:880062dced30 EFLAGS: 00010206
>> RAX: dc00 RBX: 8800670561c0 RCX: 0006
>> RDX: 0003 RSI: 880062dcfb28 RDI: 0018
>> RBP: 880062dced68 R08: 0001 R09: 
>> R10:  R11:  R12: 
>> R13: 880062dcfb28 R14: dc00 R15: 
>> FS:  7feebe37e7c0() GS:88006cb0() knlGS:
>> CS:  0010 DS:  ES:  CR0: 80050033
>> CR2: 205a0fe4 CR3: 6b5c9000 CR4: 06e0
>> Call Trace:
>>  ip6_pol_route+0x1512/0x1f20 net/ipv6/route.c:1128
>>  ip6_pol_route_output+0x4c/0x60 net/ipv6/route.c:1212
>> ...
>>
>> Andrey's syzkaller program passes rtmsg.rtmsg_flags with the RTF_PCPU bit
>> set. Flags passed to the kernel are blindly copied to the allocated
>> rt6_info by ip6_route_info_create making a newly inserted route appear
>> as though it is a per-cpu route. ip6_rt_cache_alloc sees the flag set
>> and expects rt->dst.from to be set - which it is not since it is not
>> really a per-cpu copy. The subsequent call to __ip6_dst_alloc then
>> generates the fault.
>>
>> Fix by checking for the flag and failing with EINVAL.
> Thanks for the fix.
>
> Acked-by: Martin KaFai Lau <ka...@fb.com>
>
>>
>> Fixes: d52d3997f843f ("ipv6: Create percpu rt6_info")
>> Reported-by: Andrey Konovalov <andreyk...@google.com>
>> Signed-off-by: David Ahern <d...@cumulusnetworks.com>
>> ---
>>  include/uapi/linux/ipv6_route.h | 2 +-
>>  net/ipv6/route.c| 4 
>>  2 files changed, 5 insertions(+), 1 deletion(-)
>>
>> diff --git a/include/uapi/linux/ipv6_route.h 
>> b/include/uapi/linux/ipv6_route.h
>> index 85bbb1799df3..d496c02e14bc 100644
>> --- a/include/uapi/linux/ipv6_route.h
>> +++ b/include/uapi/linux/ipv6_route.h
>> @@ -35,7 +35,7 @@
>>  #define RTF_PREF(pref)   ((pref) << 27)
>>  #define RTF_PREF_MASK0x1800
>>
>> -#define RTF_PCPU 0x4000
>> +#define RTF_PCPU 0x4000  /* read-only: can not be set by user */
>>  #define RTF_LOCAL0x8000
>>
>>
>> diff --git a/net/ipv6/route.c b/net/ipv6/route.c
>> index 4ba7c49872ff..a1bf426c959b 100644
>> --- a/net/ipv6/route.c
>> +++ b/net/ipv6/route.c
>> @@ -1854,6 +1854,10 @@ static struct rt6_info *ip6_route_info_create(struct 
>> fib6_config *cfg)
>>   int addr_type;
>>   int err = -EINVAL;
>>
>> + /* RTF_PCPU is an internal flag; can not be set by userspace */
>> + if (cfg->fc_flags & RTF_PCPU)
>> + goto out;
>> +
>>   if (cfg->fc_dst_len > 128 || cfg->fc_src_len > 128)
>>   goto out;
>>  #ifndef CONFIG_IPV6_SUBTREES
>> --
>> 2.9.3
>>

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

[Andrey Konovalov]

On Wed, Apr 19, 2017 at 6:09 PM, David Ahern <d...@cumulusnetworks.com> wrote:
> On 4/18/17 2:43 PM, Andrey Konovalov wrote:
>> Hi!
>>
>> I've finally managed to reproduce one of the crashes on commit
>> 4f7d029b9bf009fbee76bb10c0c4351a1870d2f3 (4.11-rc7).
>>
>> I'm not sure if this bug has the same root cause as the first one
>> reported in this thread, but it definitely has to do with ipv6
>> routing.
>>
>> C reproducer, syzkaller program and my .config are attached.
>
> built a kernel with that config. booted the vm. ran the program. nada.
>
> strace is showing:
>
> clone(child_stack=0x72ffb0,
> flags=CLONE_NEWUTS|CLONE_NEWUSER|CLONE_NEWPID|CLONE_NEWNET) = -1 EINVAL
> (Invalid argument)
>

That's weird. I usually see this when I have CONFIG_USER_NS disabled.

Anyway, I just finished simplifying the reproducer. Give this one a try.
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 

#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 

#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 

void loop() {
	int s0 = socket(AF_INET6, SOCK_STREAM, 0x84);

	struct in6_rtmsg rtmsg;
	memset(_dst, 0, sizeof(rtmsg.rtmsg_dst));
	rtmsg.rtmsg_src = in6addr_loopback;
	memset(_gateway, 0, sizeof(rtmsg.rtmsg_gateway));
	rtmsg.rtmsg_type = 0x4;
	rtmsg.rtmsg_dst_len = 0x;
	rtmsg.rtmsg_src_len = 0x7;
	rtmsg.rtmsg_metric = 0x100;
	rtmsg.rtmsg_info = 0x8001;
	rtmsg.rtmsg_flags = 0x4000;
	rtmsg.rtmsg_ifindex = if_nametoindex("gre0");
	ioctl(s0, SIOCADDRT, );

	int s1 = socket(AF_INET6, SOCK_RAW|SOCK_NONBLOCK, IPPROTO_RAW);

	struct sockaddr_in6 si;
	memset(, 0, sizeof(si));
	char buffer[1];
	sendto(s1, [0], 0, MSG_CONFIRM, (const struct sockaddr *), sizeof(si));
}

int main() {
	unshare(CLONE_NEWUSER);
	unshare(CLONE_NEWNET);

	loop();

	return 0;
}

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

[Andrey Konovalov]

On Wed, Apr 19, 2017 at 1:20 AM, David Ahern <d...@cumulusnetworks.com> wrote:
> On 4/18/17 2:43 PM, Andrey Konovalov wrote:
>> I've finally managed to reproduce one of the crashes on commit
>> 4f7d029b9bf009fbee76bb10c0c4351a1870d2f3 (4.11-rc7).
>>
>> I'm not sure if this bug has the same root cause as the first one
>> reported in this thread, but it definitely has to do with ipv6
>> routing.
>>
>> C reproducer, syzkaller program and my .config are attached.

Just FYI, the reproducer uses interface number 9 inside a user
namespace, which is apparently ip6gre0.

1: lo:  mtu 65536 qdisc noop state DOWN mode DEFAULT qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
2: tunl0@NONE:  mtu 1480 qdisc noop state DOWN mode DEFAULT qlen 1000
link/ipip 0.0.0.0 brd 0.0.0.0
3: gre0@NONE:  mtu 1476 qdisc noop state DOWN mode DEFAULT qlen 1000
link/gre 0.0.0.0 brd 0.0.0.0
4: gretap0@NONE: <BROADCAST,MULTICAST> mtu 1462 qdisc noop state DOWN
mode DEFAULT qlen 1000
link/ether 00:00:00:00:00:00 brd ff:ff:ff:ff:ff:ff
5: ip_vti0@NONE:  mtu 1332 qdisc noop state DOWN mode DEFAULT qlen 1000
link/ipip 0.0.0.0 brd 0.0.0.0
6: ip6_vti0@NONE:  mtu 1500 qdisc noop state DOWN mode DEFAULT qlen 1000
link/tunnel6 :: brd ::
7: sit0@NONE:  mtu 1480 qdisc noop state DOWN mode DEFAULT qlen 1000
link/sit 0.0.0.0 brd 0.0.0.0
8: ip6tnl0@NONE:  mtu 1452 qdisc noop state DOWN mode DEFAULT qlen 1000
link/tunnel6 :: brd ::
9: ip6gre0@NONE:  mtu 1448 qdisc noop state DOWN mode DEFAULT qlen 1000
link/[823] 00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00 brd
00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00

>>
>> Thanks!
>>
>> kasan: CONFIG_KASAN_INLINE enabled
>> kasan: GPF could be caused by NULL-ptr deref or user memory access
>> general protection fault:  [#1] SMP KASAN
>> Modules linked in:
>> CPU: 1 PID: 4035 Comm: a.out Not tainted 4.11.0-rc7+ #250
>> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011
>> task: 880069809600 task.stack: 880062dc8000
>> RIP: 0010:ip6_rt_cache_alloc+0xa6/0x560 net/ipv6/route.c:975
>
> From a quick glance seems to be a different bug than Dmitry's.

It might be.

>

Re: net/ipv4: use-after-free in ip_queue_xmit

[Andrey Konovalov]

On Tue, Apr 18, 2017 at 6:05 PM, Cong Wang <xiyou.wangc...@gmail.com> wrote:
> On Tue, Apr 18, 2017 at 5:15 AM, Andrey Konovalov <andreyk...@google.com> 
> wrote:
>> Yes, I don't have this field in the rtable struct.
>>
>> I'm on 39da7c509acff13fc8cb12ec1bb20337c988ed36 (4.11-rc6).
>>
>> I also don't see it in the cross reference:
>> http://lxr.free-electrons.com/source/include/net/route.h#L51
>>
>
> It is provided by my patch: https://patchwork.ozlabs.org/patch/747556/
> which means you applied an incomplete patch... :-/

Oops, my bad.

Applied the patch.

Thanks!

Re: net/ipv6: slab-out-of-bounds read in seg6_validate_srh

[Andrey Konovalov]

On Tue, Apr 18, 2017 at 5:16 PM, David Lebrun <david.leb...@uclouvain.be> wrote:
> On 04/18/2017 04:54 PM, Andrey Konovalov wrote:
>> Hi,
>>
>> I've got the following error report while fuzzing the kernel with syzkaller.
>>
>> On commit 4f7d029b9bf009fbee76bb10c0c4351a1870d2f3 (4.11-rc7).
>>
>> A reproducer and .config are attached.
>>
>> ==
>> BUG: KASAN: slab-out-of-bounds in seg6_validate_srh+0x203/0x220
>> net/ipv6/seg6.c:57 at addr 88006a759608
>> Read of size 1 by task syz-executor4/2627
>
> Thanks for the report. It seems to happen when the trailing data is less
> than sizeof(struct sr6_tlv). The following (untested) patch should fix
> the issue, I'll test it and submit it properly if it works.

Hi David,

This fixes the bug.

Thanks!

Tested-by: Andrey Konovalov <andreyk...@google.com>

>
> diff --git a/net/ipv6/seg6.c b/net/ipv6/seg6.c
> index a855eb3..5f44ffe 100644
> --- a/net/ipv6/seg6.c
> +++ b/net/ipv6/seg6.c
> @@ -53,6 +53,9 @@ bool seg6_validate_srh(struct ipv6_sr_hdr *srh, int len)
> struct sr6_tlv *tlv;
> unsigned int tlv_len;
>
> +   if (trailing < sizeof(*tlv))
> +   return false;
> +
> tlv = (struct sr6_tlv *)((unsigned char *)srh + tlv_offset);
> tlv_len = sizeof(*tlv) + tlv->len;
>
>
>

Re: net/ipv4: use-after-free in ip_queue_xmit

[Andrey Konovalov]

On Thu, Apr 13, 2017 at 9:59 PM, Cong Wang <xiyou.wangc...@gmail.com> wrote:
> On Thu, Apr 13, 2017 at 11:49 AM, Andrey Konovalov
> <andreyk...@google.com> wrote:
>> On Mon, Apr 10, 2017 at 7:46 PM, Andrey Konovalov <andreyk...@google.com> 
>> wrote:
>>> On Mon, Apr 10, 2017 at 7:42 PM, Cong Wang <xiyou.wangc...@gmail.com> wrote:
>>>> On Mon, Apr 10, 2017 at 7:40 AM, Andrey Konovalov <andreyk...@google.com> 
>>>> wrote:
>>>>> Hi,
>>>>>
>>>>> I've got the following error report while fuzzing the kernel with 
>>>>> syzkaller.
>>>>>
>>>>> On commit 39da7c509acff13fc8cb12ec1bb20337c988ed36 (4.11-rc6).
>>>>>
>>>>> Unfortunately it's not reproducible.
>>>>>
>>>>> BUG: KASAN: use-after-free in ip_select_ttl include/net/dst.h:176
>>>>> [inline] at addr 88006ab3602c
>>>>> BUG: KASAN: use-after-free in ip_queue_xmit+0x1817/0x1a30
>>>>> net/ipv4/ip_output.c:485 at addr 88006ab3602c
>>>>> Read of size 4 by task syz-executor1/12627
>>>>> CPU: 3 PID: 12627 Comm: syz-executor1 Not tainted 4.11.0-rc6+ #206
>>>>> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 
>>>>> 01/01/2011
>>>>> Call Trace:
>>>>>  __dump_stack lib/dump_stack.c:16 [inline]
>>>>>  dump_stack+0x292/0x398 lib/dump_stack.c:52
>>>>>  kasan_object_err+0x1c/0x70 mm/kasan/report.c:164
>>>>>  print_address_description mm/kasan/report.c:202 [inline]
>>>>>  kasan_report_error mm/kasan/report.c:291 [inline]
>>>>>  kasan_report+0x252/0x510 mm/kasan/report.c:347
>>>>>  __asan_report_load4_noabort+0x14/0x20 mm/kasan/report.c:367
>>>>>  ip_select_ttl include/net/dst.h:176 [inline]
>>>>
>>>> Probably same as the one you reported on ipv4_mtu(), it would
>>>> be nice if you could test the patch I proposed:
>>>>
>>>> https://patchwork.ozlabs.org/patch/747556/
>>>
>>> Applied your patch.
>>
>> Oops, apparently your patch doesn't compile:
>>
>
> Weird, it compiles fine here. Either you have a different config
> or the following piece is missing for some reason?
>
> @@ -69,6 +69,7 @@  struct rtable {
>
>   struct list_head rt_uncached;
>   struct uncached_list *rt_uncached_list;
> + struct fib_info *fi; /* for refcnt to shared metrics */
>  };

Yes, I don't have this field in the rtable struct.

I'm on 39da7c509acff13fc8cb12ec1bb20337c988ed36 (4.11-rc6).

I also don't see it in the cross reference:
http://lxr.free-electrons.com/source/include/net/route.h#L51

>
> --
> You received this message because you are subscribed to the Google Groups 
> "syzkaller" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to syzkaller+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

Re: net/ipv4: use-after-free in ip_queue_xmit

[Andrey Konovalov]

On Mon, Apr 10, 2017 at 7:46 PM, Andrey Konovalov <andreyk...@google.com> wrote:
> On Mon, Apr 10, 2017 at 7:42 PM, Cong Wang <xiyou.wangc...@gmail.com> wrote:
>> On Mon, Apr 10, 2017 at 7:40 AM, Andrey Konovalov <andreyk...@google.com> 
>> wrote:
>>> Hi,
>>>
>>> I've got the following error report while fuzzing the kernel with syzkaller.
>>>
>>> On commit 39da7c509acff13fc8cb12ec1bb20337c988ed36 (4.11-rc6).
>>>
>>> Unfortunately it's not reproducible.
>>>
>>> BUG: KASAN: use-after-free in ip_select_ttl include/net/dst.h:176
>>> [inline] at addr 88006ab3602c
>>> BUG: KASAN: use-after-free in ip_queue_xmit+0x1817/0x1a30
>>> net/ipv4/ip_output.c:485 at addr 88006ab3602c
>>> Read of size 4 by task syz-executor1/12627
>>> CPU: 3 PID: 12627 Comm: syz-executor1 Not tainted 4.11.0-rc6+ #206
>>> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011
>>> Call Trace:
>>>  __dump_stack lib/dump_stack.c:16 [inline]
>>>  dump_stack+0x292/0x398 lib/dump_stack.c:52
>>>  kasan_object_err+0x1c/0x70 mm/kasan/report.c:164
>>>  print_address_description mm/kasan/report.c:202 [inline]
>>>  kasan_report_error mm/kasan/report.c:291 [inline]
>>>  kasan_report+0x252/0x510 mm/kasan/report.c:347
>>>  __asan_report_load4_noabort+0x14/0x20 mm/kasan/report.c:367
>>>  ip_select_ttl include/net/dst.h:176 [inline]
>>
>> Probably same as the one you reported on ipv4_mtu(), it would
>> be nice if you could test the patch I proposed:
>>
>> https://patchwork.ozlabs.org/patch/747556/
>
> Applied your patch.

Oops, apparently your patch doesn't compile:

  CC  net/ipv4/route.o
net/ipv4/route.c: In function ‘ipv4_dst_destroy’:
net/ipv4/route.c:1394:8: error: ‘struct rtable’ has no member named ‘fi’
  if (rt->fi) {
^~
net/ipv4/route.c:1395:18: error: ‘struct rtable’ has no member named ‘fi’
   fib_info_put(rt->fi);
  ^~
net/ipv4/route.c:1396:5: error: ‘struct rtable’ has no member named ‘fi’
   rt->fi = NULL;
 ^~
net/ipv4/route.c: In function ‘rt_init_metrics’:
net/ipv4/route.c:1440:5: error: ‘struct rtable’ has no member named ‘fi’
   rt->fi = fi;
 ^~
net/ipv4/route.c: In function ‘rt_dst_alloc’:
net/ipv4/route.c:1512:5: error: ‘struct rtable’ has no member named ‘fi’
   rt->fi = NULL;
 ^~
make[2]: *** [net/ipv4/route.o] Error 1
make[1]: *** [net/ipv4] Error 2
make[1]: *** Waiting for unfinished jobs
make: *** [net] Error 2


>
> The bug gets triggered very rarely (only twice so far), but I'll let
> you know if I see it again.
>
> Thanks!
>
>>
>>
>> Thanks!
>>
>>>  ip_queue_xmit+0x1817/0x1a30 net/ipv4/ip_output.c:485
>>>  sctp_v4_xmit+0x10d/0x140 net/sctp/protocol.c:994
>>>  sctp_packet_transmit+0x215c/0x3560 net/sctp/output.c:637
>>>  sctp_outq_flush+0xade/0x3f90 net/sctp/outqueue.c:885
>>>  sctp_outq_uncork+0x5a/0x70 net/sctp/outqueue.c:750
>>>  sctp_cmd_interpreter net/sctp/sm_sideeffect.c:1773 [inline]
>>>  sctp_side_effects net/sctp/sm_sideeffect.c:1175 [inline]
>>>  sctp_do_sm+0x5a0/0x6a50 net/sctp/sm_sideeffect.c:1147
>>>  sctp_primitive_ASSOCIATE+0x9d/0xd0 net/sctp/primitive.c:88
>>>  sctp_sendmsg+0x270d/0x3b50 net/sctp/socket.c:1954
>>>  inet_sendmsg+0x164/0x5b0 net/ipv4/af_inet.c:762
>>>  sock_sendmsg_nosec net/socket.c:633 [inline]
>>>  sock_sendmsg+0xca/0x110 net/socket.c:643
>>>  SYSC_sendto+0x660/0x810 net/socket.c:1696
>>>  SyS_sendto+0x40/0x50 net/socket.c:1664
>>>  entry_SYSCALL_64_fastpath+0x1f/0xc2
>>> RIP: 0033:0x4458d9
>>> RSP: 002b:7fdceca85b58 EFLAGS: 0282 ORIG_RAX: 002c
>>> RAX: ffda RBX: 0016 RCX: 004458d9
>>> RDX: 0087 RSI: 20003000 RDI: 0016
>>> RBP: 006e2fe0 R08: 20003000 R09: 0010
>>> R10: 00040841 R11: 0282 R12: 007080a8
>>> R13: 000a R14: 0005 R15: 0084
>>> Object at 88006ab36008, in cache kmalloc-64 size: 64
>>> Allocated:
>>> PID = 7243
>>>  save_stack_trace+0x16/0x20 arch/x86/kernel/stacktrace.c:59
>>>  save_stack+0x43/0xd0 mm/kasan/kasan.c:513
>>>  set_track mm/kasan/kasan.c:525 [inline]
>>>  kasan_kmalloc+0xad/0xe0 mm/kasan/kasan.c:616
>>>  kmem_cache_alloc_trace+0x82/0x270 mm/slub.c:2745
>>>  kmalloc include/linux/slab.h:490 [inline]
>>>  kzalloc include/linux/slab.h:663 [inline]
>>>  fib_create_info+0x8e0/0x3a30 net/ipv4

Re: net/ipv4: deadlock in ip_ra_control

[Andrey Konovalov]

On Wed, Apr 12, 2017 at 9:41 PM, Cong Wang <xiyou.wangc...@gmail.com> wrote:
> On Wed, Apr 12, 2017 at 5:05 AM, Andrey Konovalov <andreyk...@google.com> 
> wrote:
>> Hi Cong,
>>
>> I now have a reproducer for this bug (attached) and your patch fixes it.
>>
>> Could you send it?
>>
>
> Done. I verified it with your reproducer too.
>
> Thanks!

Great, thanks!

net/ipv4: use-after-free in ipv4_datagram_support_cmsg

[Andrey Konovalov]

Hi,

I've got the following error report while fuzzing the kernel with syzkaller.

On commit 39da7c509acff13fc8cb12ec1bb20337c988ed36 (4.11-rc6).

Unfortunately it's not reproducible.

==
BUG: KASAN: use-after-free in ipv4_datagram_support_cmsg
net/ipv4/ip_sockglue.c:500 [inline] at addr 880059be0128
BUG: KASAN: use-after-free in ip_recv_error+0xb37/0xed0
net/ipv4/ip_sockglue.c:553 at addr 880059be0128
Read of size 4 by task syz-executor5/22308
CPU: 0 PID: 22308 Comm: syz-executor5 Not tainted 4.11.0-rc6+ #213
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011
Call Trace:
 __dump_stack lib/dump_stack.c:16 [inline]
 dump_stack+0x292/0x398 lib/dump_stack.c:52
 kasan_object_err+0x1c/0x70 mm/kasan/report.c:164
 print_address_description mm/kasan/report.c:202 [inline]
 kasan_report_error mm/kasan/report.c:291 [inline]
 kasan_report+0x252/0x510 mm/kasan/report.c:347
 __asan_report_load4_noabort+0x14/0x20 mm/kasan/report.c:367
 ipv4_datagram_support_cmsg net/ipv4/ip_sockglue.c:500 [inline]
 ip_recv_error+0xb37/0xed0 net/ipv4/ip_sockglue.c:553
 udp_recvmsg+0xe70/0x1370 net/ipv4/udp.c:1421
 inet_recvmsg+0x13e/0x600 net/ipv4/af_inet.c:793
 sock_recvmsg_nosec net/socket.c:751 [inline]
 sock_recvmsg+0xd7/0x110 net/socket.c:758
 ___sys_recvmsg+0x2f4/0x730 net/socket.c:2156
 __sys_recvmsg+0x135/0x320 net/socket.c:2201
 SYSC_recvmsg net/socket.c:2213 [inline]
 SyS_recvmsg+0x2d/0x50 net/socket.c:2208
 entry_SYSCALL_64_fastpath+0x1f/0xc2
RIP: 0033:0x4458d9
RSP: 002b:7f230ab31b58 EFLAGS: 0286 ORIG_RAX: 002f
RAX: ffda RBX: 0005 RCX: 004458d9
RDX: 40002102 RSI: 20edffc8 RDI: 0005
RBP: 006e2d00 R08:  R09: 
R10:  R11: 0286 R12: 00708000
R13: 0002 R14: 00708008 R15: 7f230ab32700
Object at 880059be0008, in cache kmalloc-8192 size: 8192
Allocated:
PID = 16445
 save_stack_trace+0x16/0x20 arch/x86/kernel/stacktrace.c:59
 save_stack+0x43/0xd0 mm/kasan/kasan.c:513
 set_track mm/kasan/kasan.c:525 [inline]
 kasan_kmalloc+0xad/0xe0 mm/kasan/kasan.c:616
 __kmalloc+0xa0/0x2d0 mm/slub.c:3745
 kzalloc include/linux/slab.h:495 [inline]
 alloc_netdev_mqs+0xbc1/0xf40 net/core/dev.c:7706
 br_add_bridge+0x34/0xd0 net/bridge/br_if.c:384
 br_ioctl_deviceless_stub+0x7fc/0xa30 net/bridge/br_ioctl.c:378
 sock_ioctl+0x256/0x440 net/socket.c:971
 vfs_ioctl fs/ioctl.c:45 [inline]
 do_vfs_ioctl+0x1bf/0x1780 fs/ioctl.c:685
 SYSC_ioctl fs/ioctl.c:700 [inline]
 SyS_ioctl+0x8f/0xc0 fs/ioctl.c:691
 entry_SYSCALL_64_fastpath+0x1f/0xc2
Freed:
PID = 22308
 save_stack_trace+0x16/0x20 arch/x86/kernel/stacktrace.c:59
 save_stack+0x43/0xd0 mm/kasan/kasan.c:513
 set_track mm/kasan/kasan.c:525 [inline]
 kasan_slab_free+0x73/0xc0 mm/kasan/kasan.c:589
 slab_free_hook mm/slub.c:1357 [inline]
 slab_free_freelist_hook mm/slub.c:1379 [inline]
 slab_free mm/slub.c:2961 [inline]
 kfree+0xe8/0x2b0 mm/slub.c:3882
 kvfree+0x36/0x60 mm/util.c:337
 netdev_freemem+0x4c/0x60 net/core/dev.c:7658
 netdev_release+0x76/0x90 net/core/net-sysfs.c:1502
 device_release+0x18d/0x220 drivers/base/core.c:814
 kobject_cleanup lib/kobject.c:645 [inline]
 kobject_release+0xfa/0x1a0 lib/kobject.c:674
 kref_put include/linux/kref.h:72 [inline]
 kobject_put+0x6e/0xd0 lib/kobject.c:691
 netdev_run_todo+0x6b2/0xa40 net/core/dev.c:7563
 rtnl_unlock+0xe/0x10 net/core/rtnetlink.c:104
 br_del_bridge+0xb6/0xe0 net/bridge/br_if.c:422
 br_ioctl_deviceless_stub+0x324/0xa30 net/bridge/br_ioctl.c:380
 sock_ioctl+0x256/0x440 net/socket.c:971
 vfs_ioctl fs/ioctl.c:45 [inline]
 do_vfs_ioctl+0x1bf/0x1780 fs/ioctl.c:685
 SYSC_ioctl fs/ioctl.c:700 [inline]
 SyS_ioctl+0x8f/0xc0 fs/ioctl.c:691
 entry_SYSCALL_64_fastpath+0x1f/0xc2
Memory state around the buggy address:
 880059be: fc fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
 880059be0080: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
>880059be0100: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
  ^
 880059be0180: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
 880059be0200: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
==

Re: net/ipv4: deadlock in ip_ra_control

[Andrey Konovalov]

On Mon, Mar 6, 2017 at 3:04 AM, Cong Wang  wrote:
> 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 syzkaller fuzzer
> on linux-next/51788aebe7cae79cb334ad50641347465fc188fd:
>
> ==
> [ INFO: possible circular locking dependency detected ]
> 4.10.0-next-20170301+ #1 Not tainted
> ---
> syz-executor1/3394 is trying to acquire lock:
>  (sk_lock-AF_INET){+.+.+.}, at: [] lock_sock
> include/net/sock.h:1460 [inline]
>  (sk_lock-AF_INET){+.+.+.}, at: []
> do_ip_setsockopt.isra.12+0x21c/0x3540 net/ipv4/ip_sockglue.c:652
>
> but task is already holding lock:
>  (rtnl_mutex){+.+.+.}, at: [] rtnl_lock+0x17/0x20
> net/core/rtnetlink.c:70
>
> which lock already depends on the new lock.
>
>
> the existing dependency chain (in reverse order) is:
>
> -> #1 (rtnl_mutex){+.+.+.}:
>validate_chain kernel/locking/lockdep.c:2265 [inline]
>__lock_acquire+0x2149/0x3430 kernel/locking/lockdep.c:3338
>lock_acquire+0x2a1/0x630 kernel/locking/lockdep.c:3753
>__mutex_lock_common kernel/locking/mutex.c:754 [inline]
>__mutex_lock+0x172/0x1730 kernel/locking/mutex.c:891
>mutex_lock_nested+0x16/0x20 kernel/locking/mutex.c:906
>rtnl_lock+0x17/0x20 net/core/rtnetlink.c:70
>mrtsock_destruct+0x86/0x2c0 net/ipv4/ipmr.c:1281
>ip_ra_control+0x459/0x600 net/ipv4/ip_sockglue.c:372
>do_ip_setsockopt.isra.12+0x1064/0x3540 net/ipv4/ip_sockglue.c:1161
>ip_setsockopt+0x3a/0xb0 net/ipv4/ip_sockglue.c:1264
>raw_setsockopt+0xb7/0xd0 net/ipv4/raw.c:839
>sock_common_setsockopt+0x95/0xd0 net/core/sock.c:2725
>SYSC_setsockopt net/socket.c:1786 [inline]
>SyS_setsockopt+0x25c/0x390 net/socket.c:1765
>entry_SYSCALL_64_fastpath+0x1f/0xc2
>
> -> #0 (sk_lock-AF_INET){+.+.+.}:
>check_prev_add kernel/locking/lockdep.c:1828 [inline]
>check_prevs_add+0xa8f/0x19f0 kernel/locking/lockdep.c:1938
>validate_chain kernel/locking/lockdep.c:2265 [inline]
>__lock_acquire+0x2149/0x3430 kernel/locking/lockdep.c:3338
>lock_acquire+0x2a1/0x630 kernel/locking/lockdep.c:3753
>lock_sock_nested+0xcb/0x120 net/core/sock.c:2530
>lock_sock include/net/sock.h:1460 [inline]
>do_ip_setsockopt.isra.12+0x21c/0x3540 net/ipv4/ip_sockglue.c:652
>ip_setsockopt+0x3a/0xb0 net/ipv4/ip_sockglue.c:1264
>tcp_setsockopt+0x82/0xd0 net/ipv4/tcp.c:2721
>sock_common_setsockopt+0x95/0xd0 net/core/sock.c:2725
>SYSC_setsockopt net/socket.c:1786 [inline]
>SyS_setsockopt+0x25c/0x390 net/socket.c:1765
>entry_SYSCALL_64_fastpath+0x1f/0xc2
>

 Please try the attached patch (compile only).
>>>
>>>
>>> Pushed the patch to the bots.
>>> Thanks
>>
>>
>> This patch triggers:
>
> Ah, update the patch to fix this.

Hi Cong,

I now have a reproducer for this bug (attached) and your patch fixes it.

Could you send it?

Thanks!

>
> --
> You received this message because you are subscribed to the Google Groups 
> "syzkaller" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to syzkaller+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
// autogenerated by syzkaller (http://github.com/google/syzkaller)

#ifndef __NR_mmap
#define __NR_mmap 9
#endif
#ifndef __NR_socket
#define __NR_socket 41
#endif
#ifndef __NR_setsockopt
#define __NR_setsockopt 54
#endif

#define _GNU_SOURCE

#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 

#include 
#include 
#include 
#include 
#include 
#include 

#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 

const int kFailStatus = 67;
const int kErrorStatus = 68;
const int kRetryStatus = 69;

__attribute__((noreturn)) void doexit(int status)
{
  volatile unsigned i;
  syscall(__NR_exit_group, status);
  for (i = 0;; i++) {
  }
}

__attribute__((noreturn)) void fail(const char* msg, ...)
{
  int e = errno;
  fflush(stdout);
  va_list args;
  va_start(args, msg);
  vfprintf(stderr, msg, args);
  va_end(args);
  fprintf(stderr, " (errno %d)\n", e);
  doexit((e == ENOMEM || e == EAGAIN) ? kRetryStatus : kFailStatus);
}

Re: net/ipv4: use-after-free in ip_queue_xmit

[Andrey Konovalov]

On Mon, Apr 10, 2017 at 7:42 PM, Cong Wang <xiyou.wangc...@gmail.com> wrote:
> On Mon, Apr 10, 2017 at 7:40 AM, Andrey Konovalov <andreyk...@google.com> 
> wrote:
>> Hi,
>>
>> I've got the following error report while fuzzing the kernel with syzkaller.
>>
>> On commit 39da7c509acff13fc8cb12ec1bb20337c988ed36 (4.11-rc6).
>>
>> Unfortunately it's not reproducible.
>>
>> BUG: KASAN: use-after-free in ip_select_ttl include/net/dst.h:176
>> [inline] at addr 88006ab3602c
>> BUG: KASAN: use-after-free in ip_queue_xmit+0x1817/0x1a30
>> net/ipv4/ip_output.c:485 at addr 88006ab3602c
>> Read of size 4 by task syz-executor1/12627
>> CPU: 3 PID: 12627 Comm: syz-executor1 Not tainted 4.11.0-rc6+ #206
>> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011
>> Call Trace:
>>  __dump_stack lib/dump_stack.c:16 [inline]
>>  dump_stack+0x292/0x398 lib/dump_stack.c:52
>>  kasan_object_err+0x1c/0x70 mm/kasan/report.c:164
>>  print_address_description mm/kasan/report.c:202 [inline]
>>  kasan_report_error mm/kasan/report.c:291 [inline]
>>  kasan_report+0x252/0x510 mm/kasan/report.c:347
>>  __asan_report_load4_noabort+0x14/0x20 mm/kasan/report.c:367
>>  ip_select_ttl include/net/dst.h:176 [inline]
>
> Probably same as the one you reported on ipv4_mtu(), it would
> be nice if you could test the patch I proposed:
>
> https://patchwork.ozlabs.org/patch/747556/

Applied your patch.

The bug gets triggered very rarely (only twice so far), but I'll let
you know if I see it again.

Thanks!

>
>
> Thanks!
>
>>  ip_queue_xmit+0x1817/0x1a30 net/ipv4/ip_output.c:485
>>  sctp_v4_xmit+0x10d/0x140 net/sctp/protocol.c:994
>>  sctp_packet_transmit+0x215c/0x3560 net/sctp/output.c:637
>>  sctp_outq_flush+0xade/0x3f90 net/sctp/outqueue.c:885
>>  sctp_outq_uncork+0x5a/0x70 net/sctp/outqueue.c:750
>>  sctp_cmd_interpreter net/sctp/sm_sideeffect.c:1773 [inline]
>>  sctp_side_effects net/sctp/sm_sideeffect.c:1175 [inline]
>>  sctp_do_sm+0x5a0/0x6a50 net/sctp/sm_sideeffect.c:1147
>>  sctp_primitive_ASSOCIATE+0x9d/0xd0 net/sctp/primitive.c:88
>>  sctp_sendmsg+0x270d/0x3b50 net/sctp/socket.c:1954
>>  inet_sendmsg+0x164/0x5b0 net/ipv4/af_inet.c:762
>>  sock_sendmsg_nosec net/socket.c:633 [inline]
>>  sock_sendmsg+0xca/0x110 net/socket.c:643
>>  SYSC_sendto+0x660/0x810 net/socket.c:1696
>>  SyS_sendto+0x40/0x50 net/socket.c:1664
>>  entry_SYSCALL_64_fastpath+0x1f/0xc2
>> RIP: 0033:0x4458d9
>> RSP: 002b:7fdceca85b58 EFLAGS: 0282 ORIG_RAX: 002c
>> RAX: ffda RBX: 0016 RCX: 004458d9
>> RDX: 0087 RSI: 20003000 RDI: 0016
>> RBP: 006e2fe0 R08: 20003000 R09: 0010
>> R10: 00040841 R11: 0282 R12: 007080a8
>> R13: 000a R14: 0005 R15: 0084
>> Object at 88006ab36008, in cache kmalloc-64 size: 64
>> Allocated:
>> PID = 7243
>>  save_stack_trace+0x16/0x20 arch/x86/kernel/stacktrace.c:59
>>  save_stack+0x43/0xd0 mm/kasan/kasan.c:513
>>  set_track mm/kasan/kasan.c:525 [inline]
>>  kasan_kmalloc+0xad/0xe0 mm/kasan/kasan.c:616
>>  kmem_cache_alloc_trace+0x82/0x270 mm/slub.c:2745
>>  kmalloc include/linux/slab.h:490 [inline]
>>  kzalloc include/linux/slab.h:663 [inline]
>>  fib_create_info+0x8e0/0x3a30 net/ipv4/fib_semantics.c:1040
>>  fib_table_insert+0x1a5/0x1550 net/ipv4/fib_trie.c:1221
>>  ip_rt_ioctl+0xddc/0x1590 net/ipv4/fib_frontend.c:597
>>  inet_ioctl+0xf2/0x1c0 net/ipv4/af_inet.c:882
>>  sock_do_ioctl+0x65/0xb0 net/socket.c:906
>>  sock_ioctl+0x28f/0x440 net/socket.c:1004
>>  vfs_ioctl fs/ioctl.c:45 [inline]
>>  do_vfs_ioctl+0x1bf/0x1780 fs/ioctl.c:685
>>  SYSC_ioctl fs/ioctl.c:700 [inline]
>>  SyS_ioctl+0x8f/0xc0 fs/ioctl.c:691
>>  entry_SYSCALL_64_fastpath+0x1f/0xc2
>> Freed:
>> PID = 12622
>>  save_stack_trace+0x16/0x20 arch/x86/kernel/stacktrace.c:59
>>  save_stack+0x43/0xd0 mm/kasan/kasan.c:513
>>  set_track mm/kasan/kasan.c:525 [inline]
>>  kasan_slab_free+0x73/0xc0 mm/kasan/kasan.c:589
>>  slab_free_hook mm/slub.c:1357 [inline]
>>  slab_free_freelist_hook mm/slub.c:1379 [inline]
>>  slab_free mm/slub.c:2961 [inline]
>>  kfree+0xe8/0x2b0 mm/slub.c:3882
>>  free_fib_info_rcu+0x4ba/0x5e0 net/ipv4/fib_semantics.c:218
>>  __rcu_reclaim kernel/rcu/rcu.h:118 [inline]
>>  rcu_do_batch.isra.64+0x947/0xcc0 kernel/rcu/tree.c:2879
>>  invoke_rcu_callbacks kernel/rcu/tree.c:3142 [inline]
>>  __rcu_process_callbacks kernel/rcu/tree.c

net/ipv4: use-after-free in ip_queue_xmit

[Andrey Konovalov]

Hi,

I've got the following error report while fuzzing the kernel with syzkaller.

On commit 39da7c509acff13fc8cb12ec1bb20337c988ed36 (4.11-rc6).

Unfortunately it's not reproducible.

BUG: KASAN: use-after-free in ip_select_ttl include/net/dst.h:176
[inline] at addr 88006ab3602c
BUG: KASAN: use-after-free in ip_queue_xmit+0x1817/0x1a30
net/ipv4/ip_output.c:485 at addr 88006ab3602c
Read of size 4 by task syz-executor1/12627
CPU: 3 PID: 12627 Comm: syz-executor1 Not tainted 4.11.0-rc6+ #206
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011
Call Trace:
 __dump_stack lib/dump_stack.c:16 [inline]
 dump_stack+0x292/0x398 lib/dump_stack.c:52
 kasan_object_err+0x1c/0x70 mm/kasan/report.c:164
 print_address_description mm/kasan/report.c:202 [inline]
 kasan_report_error mm/kasan/report.c:291 [inline]
 kasan_report+0x252/0x510 mm/kasan/report.c:347
 __asan_report_load4_noabort+0x14/0x20 mm/kasan/report.c:367
 ip_select_ttl include/net/dst.h:176 [inline]
 ip_queue_xmit+0x1817/0x1a30 net/ipv4/ip_output.c:485
 sctp_v4_xmit+0x10d/0x140 net/sctp/protocol.c:994
 sctp_packet_transmit+0x215c/0x3560 net/sctp/output.c:637
 sctp_outq_flush+0xade/0x3f90 net/sctp/outqueue.c:885
 sctp_outq_uncork+0x5a/0x70 net/sctp/outqueue.c:750
 sctp_cmd_interpreter net/sctp/sm_sideeffect.c:1773 [inline]
 sctp_side_effects net/sctp/sm_sideeffect.c:1175 [inline]
 sctp_do_sm+0x5a0/0x6a50 net/sctp/sm_sideeffect.c:1147
 sctp_primitive_ASSOCIATE+0x9d/0xd0 net/sctp/primitive.c:88
 sctp_sendmsg+0x270d/0x3b50 net/sctp/socket.c:1954
 inet_sendmsg+0x164/0x5b0 net/ipv4/af_inet.c:762
 sock_sendmsg_nosec net/socket.c:633 [inline]
 sock_sendmsg+0xca/0x110 net/socket.c:643
 SYSC_sendto+0x660/0x810 net/socket.c:1696
 SyS_sendto+0x40/0x50 net/socket.c:1664
 entry_SYSCALL_64_fastpath+0x1f/0xc2
RIP: 0033:0x4458d9
RSP: 002b:7fdceca85b58 EFLAGS: 0282 ORIG_RAX: 002c
RAX: ffda RBX: 0016 RCX: 004458d9
RDX: 0087 RSI: 20003000 RDI: 0016
RBP: 006e2fe0 R08: 20003000 R09: 0010
R10: 00040841 R11: 0282 R12: 007080a8
R13: 000a R14: 0005 R15: 0084
Object at 88006ab36008, in cache kmalloc-64 size: 64
Allocated:
PID = 7243
 save_stack_trace+0x16/0x20 arch/x86/kernel/stacktrace.c:59
 save_stack+0x43/0xd0 mm/kasan/kasan.c:513
 set_track mm/kasan/kasan.c:525 [inline]
 kasan_kmalloc+0xad/0xe0 mm/kasan/kasan.c:616
 kmem_cache_alloc_trace+0x82/0x270 mm/slub.c:2745
 kmalloc include/linux/slab.h:490 [inline]
 kzalloc include/linux/slab.h:663 [inline]
 fib_create_info+0x8e0/0x3a30 net/ipv4/fib_semantics.c:1040
 fib_table_insert+0x1a5/0x1550 net/ipv4/fib_trie.c:1221
 ip_rt_ioctl+0xddc/0x1590 net/ipv4/fib_frontend.c:597
 inet_ioctl+0xf2/0x1c0 net/ipv4/af_inet.c:882
 sock_do_ioctl+0x65/0xb0 net/socket.c:906
 sock_ioctl+0x28f/0x440 net/socket.c:1004
 vfs_ioctl fs/ioctl.c:45 [inline]
 do_vfs_ioctl+0x1bf/0x1780 fs/ioctl.c:685
 SYSC_ioctl fs/ioctl.c:700 [inline]
 SyS_ioctl+0x8f/0xc0 fs/ioctl.c:691
 entry_SYSCALL_64_fastpath+0x1f/0xc2
Freed:
PID = 12622
 save_stack_trace+0x16/0x20 arch/x86/kernel/stacktrace.c:59
 save_stack+0x43/0xd0 mm/kasan/kasan.c:513
 set_track mm/kasan/kasan.c:525 [inline]
 kasan_slab_free+0x73/0xc0 mm/kasan/kasan.c:589
 slab_free_hook mm/slub.c:1357 [inline]
 slab_free_freelist_hook mm/slub.c:1379 [inline]
 slab_free mm/slub.c:2961 [inline]
 kfree+0xe8/0x2b0 mm/slub.c:3882
 free_fib_info_rcu+0x4ba/0x5e0 net/ipv4/fib_semantics.c:218
 __rcu_reclaim kernel/rcu/rcu.h:118 [inline]
 rcu_do_batch.isra.64+0x947/0xcc0 kernel/rcu/tree.c:2879
 invoke_rcu_callbacks kernel/rcu/tree.c:3142 [inline]
 __rcu_process_callbacks kernel/rcu/tree.c:3109 [inline]
 rcu_process_callbacks+0x2cc/0xb90 kernel/rcu/tree.c:3126
 __do_softirq+0x2fb/0xb7d kernel/softirq.c:284
Memory state around the buggy address:
 88006ab35f00: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
 88006ab35f80: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
>88006ab36000: fc fb fb fb fb fb fb fb fb fc fc fc fc fc fc fc
  ^
 88006ab36080: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
 88006ab36100: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
==

net: use-after-free in __ns_get_path

[Andrey Konovalov]

Hi,

I've got the following error report while fuzzing the kernel with syzkaller.

On commit 39da7c509acff13fc8cb12ec1bb20337c988ed36 (4.11-rc6).

Unfortunately it's not reproducible.

==
BUG: KASAN: use-after-free in __read_once_size
include/linux/compiler.h:254 [inline] at addr 880059ce6590
BUG: KASAN: use-after-free in atomic_read
arch/x86/include/asm/atomic.h:26 [inline] at addr 880059ce6590
BUG: KASAN: use-after-free in virt_spin_lock
arch/x86/include/asm/qspinlock.h:62 [inline] at addr 880059ce6590
BUG: KASAN: use-after-free in queued_spin_lock_slowpath+0xb0a/0xfd0
kernel/locking/qspinlock.c:421 at addr 880059ce6590
Read of size 4 by task syz-executor6/567
CPU: 1 PID: 567 Comm: syz-executor6 Not tainted 4.11.0-rc6+ #206
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011
Call Trace:
 __dump_stack lib/dump_stack.c:16 [inline]
 dump_stack+0x292/0x398 lib/dump_stack.c:52
 kasan_object_err+0x1c/0x70 mm/kasan/report.c:164
 print_address_description mm/kasan/report.c:202 [inline]
 kasan_report_error mm/kasan/report.c:291 [inline]
 kasan_report+0x252/0x510 mm/kasan/report.c:347
 __asan_report_load4_noabort+0x14/0x20 mm/kasan/report.c:367
 __read_once_size include/linux/compiler.h:254 [inline]
 atomic_read arch/x86/include/asm/atomic.h:26 [inline]
 virt_spin_lock arch/x86/include/asm/qspinlock.h:62 [inline]
 queued_spin_lock_slowpath+0xb0a/0xfd0 kernel/locking/qspinlock.c:421
 queued_spin_lock include/asm-generic/qspinlock.h:103 [inline]
 do_raw_spin_lock+0x151/0x1e0 kernel/locking/spinlock_debug.c:113
 __raw_spin_lock include/linux/spinlock_api_smp.h:143 [inline]
 _raw_spin_lock+0x32/0x40 kernel/locking/spinlock.c:151
 spin_lock include/linux/spinlock.h:299 [inline]
 lockref_get_not_dead+0x19/0x80 lib/lockref.c:179
 __ns_get_path+0x197/0x860 fs/nsfs.c:66
 open_related_ns+0xda/0x200 fs/nsfs.c:143
 sock_ioctl+0x39d/0x440 net/socket.c:1001
 vfs_ioctl fs/ioctl.c:45 [inline]
 do_vfs_ioctl+0x1bf/0x1780 fs/ioctl.c:685
 SYSC_ioctl fs/ioctl.c:700 [inline]
 SyS_ioctl+0x8f/0xc0 fs/ioctl.c:691
 entry_SYSCALL_64_fastpath+0x1f/0xc2
RIP: 0033:0x4458d9
RSP: 002b:7f1c9259eb58 EFLAGS: 0286 ORIG_RAX: 0010
RAX: ffda RBX: 0016 RCX: 004458d9
RDX: 2090affc RSI: 894c RDI: 0016
RBP: 006e1c50 R08:  R09: 
R10:  R11: 0286 R12: 00708150
R13:  R14: 7f1c9259f9c0 R15: 7f1c9259f700
Object at 880059ce6510, in cache dentry size: 288
Allocated:
PID = 565
 save_stack_trace+0x16/0x20 arch/x86/kernel/stacktrace.c:59
 save_stack+0x43/0xd0 mm/kasan/kasan.c:513
 set_track mm/kasan/kasan.c:525 [inline]
 kasan_kmalloc+0xad/0xe0 mm/kasan/kasan.c:616
 kasan_slab_alloc+0x12/0x20 mm/kasan/kasan.c:555
 slab_post_alloc_hook mm/slab.h:456 [inline]
 slab_alloc_node mm/slub.c:2718 [inline]
 slab_alloc mm/slub.c:2726 [inline]
 kmem_cache_alloc+0x1af/0x250 mm/slub.c:2731
 __d_alloc+0xb3/0xbd0 fs/dcache.c:1571
 d_alloc_pseudo+0x1d/0x30 fs/dcache.c:1692
 __ns_get_path+0x3e8/0x860 fs/nsfs.c:88
 open_related_ns+0xda/0x200 fs/nsfs.c:143
 sock_ioctl+0x39d/0x440 net/socket.c:1001
 vfs_ioctl fs/ioctl.c:45 [inline]
 do_vfs_ioctl+0x1bf/0x1780 fs/ioctl.c:685
 SYSC_ioctl fs/ioctl.c:700 [inline]
 SyS_ioctl+0x8f/0xc0 fs/ioctl.c:691
 entry_SYSCALL_64_fastpath+0x1f/0xc2
Freed:
PID = 566
 save_stack_trace+0x16/0x20 arch/x86/kernel/stacktrace.c:59
 save_stack+0x43/0xd0 mm/kasan/kasan.c:513
 set_track mm/kasan/kasan.c:525 [inline]
 kasan_slab_free+0x73/0xc0 mm/kasan/kasan.c:589
 slab_free_hook mm/slub.c:1357 [inline]
 slab_free_freelist_hook mm/slub.c:1379 [inline]
 slab_free mm/slub.c:2961 [inline]
 kmem_cache_free+0xb2/0x2c0 mm/slub.c:2983
 __d_free fs/dcache.c:265 [inline]
 dentry_free+0xd5/0x150 fs/dcache.c:314
 __dentry_kill+0x485/0x6e0 fs/dcache.c:552
 dentry_kill fs/dcache.c:579 [inline]
 dput.part.25+0x5cd/0x7c0 fs/dcache.c:791
 dput+0x1f/0x30 fs/dcache.c:753
 __fput+0x527/0x7f0 fs/file_table.c:227
 fput+0x15/0x20 fs/file_table.c:245
 task_work_run+0x19b/0x270 kernel/task_work.c:116
 tracehook_notify_resume include/linux/tracehook.h:191 [inline]
 exit_to_usermode_loop+0x1c2/0x200 arch/x86/entry/common.c:161
 prepare_exit_to_usermode arch/x86/entry/common.c:191 [inline]
 syscall_return_slowpath+0x3d3/0x420 arch/x86/entry/common.c:260
 entry_SYSCALL_64_fastpath+0xc0/0xc2
Memory state around the buggy address:
 880059ce6480: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
 880059ce6500: fc fc fb fb fb fb fb fb fb fb fb fb fb fb fb fb
>880059ce6580: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
 ^
 880059ce6600: fb fb fb fb fb fb fc fc fc fc fc fc fc fc fc fc
 880059ce6680: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
==

net/ipv4: use-after-free in ip_check_mc_rcu

[Andrey Konovalov]

Hi,

I've got the following error report while fuzzing the kernel with syzkaller.

On commit 39da7c509acff13fc8cb12ec1bb20337c988ed36 (4.11-rc6).

Unfortunately it's not reproducible.

BUG: KASAN: use-after-free in ip_check_mc_rcu+0x805/0x8b0
net/ipv4/igmp.c:2645 at addr 880065b21cb8
Read of size 8 by task syz-executor1/2843
CPU: 3 PID: 2843 Comm: syz-executor1 Not tainted 4.11.0-rc6+ #206
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011
Call Trace:
 __dump_stack lib/dump_stack.c:16 [inline]
 dump_stack+0x292/0x398 lib/dump_stack.c:52
 kasan_object_err+0x1c/0x70 mm/kasan/report.c:164
 print_address_description mm/kasan/report.c:202 [inline]
 kasan_report_error mm/kasan/report.c:291 [inline]
 kasan_report+0x252/0x510 mm/kasan/report.c:347
 __asan_report_load8_noabort+0x14/0x20 mm/kasan/report.c:368
 ip_check_mc_rcu+0x805/0x8b0 net/ipv4/igmp.c:2645
 __mkroute_output net/ipv4/route.c:2103 [inline]
 __ip_route_output_key_hash+0x241d/0x2ea0 net/ipv4/route.c:2375
 __ip_route_output_key include/net/route.h:122 [inline]
 ip_route_output_flow+0x29/0xa0 net/ipv4/route.c:2461
 udp_sendmsg+0x1565/0x2cd0 net/ipv4/udp.c:1015
 inet_sendmsg+0x164/0x5b0 net/ipv4/af_inet.c:762
 sock_sendmsg_nosec net/socket.c:633 [inline]
 sock_sendmsg+0xca/0x110 net/socket.c:643
 SYSC_sendto+0x660/0x810 net/socket.c:1696
 SyS_sendto+0x40/0x50 net/socket.c:1664
 entry_SYSCALL_64_fastpath+0x1f/0xc2
RIP: 0033:0x4458d9
RSP: 002b:7f030b49bb58 EFLAGS: 0282 ORIG_RAX: 002c
RAX: ffda RBX: 0005 RCX: 004458d9
RDX: 1000 RSI: 20004000 RDI: 0005
RBP: 006e2fc0 R08: 2000a000 R09: 0010
R10:  R11: 0282 R12: 00708000
R13: 0005 R14: 2ff3 R15: 20006ffc
Object at 880065b21cb8, in cache kmalloc-64 size: 64
Allocated:
PID = 2841
 save_stack_trace+0x16/0x20 arch/x86/kernel/stacktrace.c:59
 save_stack+0x43/0xd0 mm/kasan/kasan.c:513
 set_track mm/kasan/kasan.c:525 [inline]
 kasan_kmalloc+0xad/0xe0 mm/kasan/kasan.c:616
 kmem_cache_alloc_trace+0x82/0x270 mm/slub.c:2745
 kmalloc include/linux/slab.h:490 [inline]
 kzalloc include/linux/slab.h:663 [inline]
 ip_mc_add1_src net/ipv4/igmp.c:1909 [inline]
 ip_mc_add_src+0xbea/0x1020 net/ipv4/igmp.c:2033
 ip_mc_msfilter+0x5e5/0xcf0 net/ipv4/igmp.c:2403
 do_ip_setsockopt.isra.12+0x2a9f/0x36c0 net/ipv4/ip_sockglue.c:967
 ip_setsockopt+0x3a/0xb0 net/ipv4/ip_sockglue.c:1264
 raw_setsockopt+0xb7/0xd0 net/ipv4/raw.c:839
 sock_common_setsockopt+0x95/0xd0 net/core/sock.c:2750
 SYSC_setsockopt net/socket.c:1798 [inline]
 SyS_setsockopt+0x270/0x3a0 net/socket.c:1777
 entry_SYSCALL_64_fastpath+0x1f/0xc2
Freed:
PID = 2841
 save_stack_trace+0x16/0x20 arch/x86/kernel/stacktrace.c:59
 save_stack+0x43/0xd0 mm/kasan/kasan.c:513
 set_track mm/kasan/kasan.c:525 [inline]
 kasan_slab_free+0x73/0xc0 mm/kasan/kasan.c:589
 slab_free_hook mm/slub.c:1357 [inline]
 slab_free_freelist_hook mm/slub.c:1379 [inline]
 slab_free mm/slub.c:2961 [inline]
 kfree+0xe8/0x2b0 mm/slub.c:3882
 ip_mc_del1_src+0x842/0x9d0 net/ipv4/igmp.c:1822
 ip_mc_del_src+0x59a/0xbe0 net/ipv4/igmp.c:1863
 ip_mc_leave_src+0x15d/0x320 net/ipv4/igmp.c:2155
 ip_mc_drop_socket+0x113/0x230 net/ipv4/igmp.c:2607
 inet_release+0x4e/0x1c0 net/ipv4/af_inet.c:411
 sock_release+0x8d/0x1e0 net/socket.c:597
 sock_close+0x16/0x20 net/socket.c:1072
 __fput+0x332/0x7f0 fs/file_table.c:209
 fput+0x15/0x20 fs/file_table.c:245
 task_work_run+0x19b/0x270 kernel/task_work.c:116
 exit_task_work include/linux/task_work.h:21 [inline]
 do_exit+0x18b6/0x2830 kernel/exit.c:878
 do_group_exit+0x149/0x420 kernel/exit.c:982
 get_signal+0x76d/0x17e0 kernel/signal.c:2318
 do_signal+0xd2/0x2190 arch/x86/kernel/signal.c:808
 exit_to_usermode_loop+0x170/0x200 arch/x86/entry/common.c:157
 prepare_exit_to_usermode arch/x86/entry/common.c:191 [inline]
 syscall_return_slowpath+0x3d3/0x420 arch/x86/entry/common.c:260
 entry_SYSCALL_64_fastpath+0xc0/0xc2
Memory state around the buggy address:
 880065b21b80: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
 880065b21c00: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
>880065b21c80: fc fc fc fc fc fc fc fb fb fb fb fb fb fb fb fc
^
 880065b21d00: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
 880065b21d80: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
==

net/ipv6: use-after-free in ipv6_sock_ac_close

[Andrey Konovalov]

Hi,

I've got the following error report while fuzzing the kernel with syzkaller.

On commit 39da7c509acff13fc8cb12ec1bb20337c988ed36 (4.11-rc6).

Unfortunately it's not reproducible.

==
BUG: KASAN: use-after-free in ipv6_sock_ac_close+0x3d6/0x3f0
net/ipv6/anycast.c:190 at addr 88005d6ce020
Read of size 8 by task syz-executor6/18308
CPU: 0 PID: 18308 Comm: syz-executor6 Not tainted 4.11.0-rc6+ #206
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011
Call Trace:
 __dump_stack lib/dump_stack.c:16 [inline]
 dump_stack+0x292/0x398 lib/dump_stack.c:52
 kasan_object_err+0x1c/0x70 mm/kasan/report.c:164
 print_address_description mm/kasan/report.c:202 [inline]
 kasan_report_error mm/kasan/report.c:291 [inline]
 kasan_report+0x252/0x510 mm/kasan/report.c:347
 __asan_report_load8_noabort+0x14/0x20 mm/kasan/report.c:368
 ipv6_sock_ac_close+0x3d6/0x3f0 net/ipv6/anycast.c:190
 inet6_release+0x48/0x70 net/ipv6/af_inet6.c:430
 sock_release+0x8d/0x1e0 net/socket.c:597
 sock_close+0x16/0x20 net/socket.c:1072
 __fput+0x332/0x7f0 fs/file_table.c:209
 fput+0x15/0x20 fs/file_table.c:245
 task_work_run+0x19b/0x270 kernel/task_work.c:116
 exit_task_work include/linux/task_work.h:21 [inline]
 do_exit+0x18b6/0x2830 kernel/exit.c:878
 do_group_exit+0x149/0x420 kernel/exit.c:982
 get_signal+0x76d/0x17e0 kernel/signal.c:2318
 do_signal+0xd2/0x2190 arch/x86/kernel/signal.c:808
 exit_to_usermode_loop+0x170/0x200 arch/x86/entry/common.c:157
 prepare_exit_to_usermode arch/x86/entry/common.c:191 [inline]
 syscall_return_slowpath+0x3d3/0x420 arch/x86/entry/common.c:260
 entry_SYSCALL_64_fastpath+0xc0/0xc2
RIP: 0033:0x4458d9
RSP: 002b:7f59304e1cf8 EFLAGS: 0246 ORIG_RAX: 00ca
RAX:  RBX: 00708218 RCX: 004458d9
RDX:  RSI:  RDI: 00708218
RBP: 007081f8 R08:  R09: 
R10:  R11: 0246 R12: 
R13:  R14: 7f59304e29c0 R15: 7f59304e2700
Object at 88005d6ce008, in cache kmalloc-32 size: 32
Allocated:
PID = 18270
 save_stack_trace+0x16/0x20 arch/x86/kernel/stacktrace.c:59
 save_stack+0x43/0xd0 mm/kasan/kasan.c:513
 set_track mm/kasan/kasan.c:525 [inline]
 kasan_kmalloc+0xad/0xe0 mm/kasan/kasan.c:616
 __kmalloc+0xa0/0x2d0 mm/slub.c:3745
 kmalloc include/linux/slab.h:495 [inline]
 sock_kmalloc+0x11e/0x1b0 net/core/sock.c:1804
 ipv6_sock_ac_join+0x21f/0x7b0 net/ipv6/anycast.c:72
 do_ipv6_setsockopt.isra.7+0x2a77/0x3bc0 net/ipv6/ipv6_sockglue.c:655
 ipv6_setsockopt+0x9b/0x140 net/ipv6/ipv6_sockglue.c:919
 sctp_setsockopt+0x2b4/0x5f10 net/sctp/socket.c:3909
 sock_common_setsockopt+0x95/0xd0 net/core/sock.c:2750
 SYSC_setsockopt net/socket.c:1798 [inline]
 SyS_setsockopt+0x270/0x3a0 net/socket.c:1777
 entry_SYSCALL_64_fastpath+0x1f/0xc2
Freed:
PID = 18308
 save_stack_trace+0x16/0x20 arch/x86/kernel/stacktrace.c:59
 save_stack+0x43/0xd0 mm/kasan/kasan.c:513
 set_track mm/kasan/kasan.c:525 [inline]
 kasan_slab_free+0x73/0xc0 mm/kasan/kasan.c:589
 slab_free_hook mm/slub.c:1357 [inline]
 slab_free_freelist_hook mm/slub.c:1379 [inline]
 slab_free mm/slub.c:2961 [inline]
 kfree+0xe8/0x2b0 mm/slub.c:3882
 __sock_kfree_s net/core/sock.c:1825 [inline]
 sock_kfree_s+0x29/0x70 net/core/sock.c:1831
 ipv6_sock_ac_close+0x2d0/0x3f0 net/ipv6/anycast.c:198
 inet6_release+0x48/0x70 net/ipv6/af_inet6.c:430
 sock_release+0x8d/0x1e0 net/socket.c:597
 sock_close+0x16/0x20 net/socket.c:1072
 __fput+0x332/0x7f0 fs/file_table.c:209
 fput+0x15/0x20 fs/file_table.c:245
 task_work_run+0x19b/0x270 kernel/task_work.c:116
 exit_task_work include/linux/task_work.h:21 [inline]
 do_exit+0x18b6/0x2830 kernel/exit.c:878
 do_group_exit+0x149/0x420 kernel/exit.c:982
 get_signal+0x76d/0x17e0 kernel/signal.c:2318
 do_signal+0xd2/0x2190 arch/x86/kernel/signal.c:808
 exit_to_usermode_loop+0x170/0x200 arch/x86/entry/common.c:157
 prepare_exit_to_usermode arch/x86/entry/common.c:191 [inline]
 syscall_return_slowpath+0x3d3/0x420 arch/x86/entry/common.c:260
 entry_SYSCALL_64_fastpath+0xc0/0xc2
Memory state around the buggy address:
 88005d6cdf00: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
 88005d6cdf80: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
>88005d6ce000: fc fb fb fb fb fc fc fc fc fc fc fc fc fc fc fc
   ^
 88005d6ce080: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
 88005d6ce100: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
==
Disabling lock debugging due to kernel taint

Re: net/sctp: list double add warning in sctp_endpoint_add_asoc

[Andrey Konovalov]

On Wed, Apr 5, 2017 at 2:44 PM, Marcelo Ricardo Leitner
<marcelo.leit...@gmail.com> wrote:
> On Wed, Apr 05, 2017 at 06:48:45PM +0800, Xin Long wrote:
>> On Wed, Apr 5, 2017 at 5:14 AM, Marcelo Ricardo Leitner
>> <marcelo.leit...@gmail.com> wrote:
>> > On Wed, Apr 05, 2017 at 01:29:19AM +0800, Xin Long wrote:
>> >> On Tue, Apr 4, 2017 at 9:28 PM, Andrey Konovalov <andreyk...@google.com> 
>> >> wrote:
>> >> > Hi,
>> >> >
>> >> > I've got the following error report while fuzzing the kernel with 
>> >> > syzkaller.
>> >> >
>> >> > On commit a71c9a1c779f2499fb2afc0553e543f18aff6edf (4.11-rc5).
>> >> >
>> >> > A reproducer and .config are attached.
>> >> The script is pretty hard to reproduce the issue in my env.
>> >
>> > I didn't try running it but I also found the reproducer very complicated
>> > to follow. Do you have any plans on having some PoC optimizer, so we can
>> > have a more readable code?
>> > strace is handy for filtering the noise, yes, but sometimes it doesn't
>> > cut it.
>> I got the script now:
>> 1. create sk
>> 2. set sk->sndbuf = x
>> 3. sendmsg with size s1 (s1 < x)
>> 4. sendmsg with size s2 (s1+s2 > x)
>> 5. sendmsg with size s3 (wspace < 0), wait sndbuf, schedule out.
>> 6. listen sk (abnormal operation on sctp client)
>> 7. accept sk.
>>
>> In step 6, sk->sk_state = listening, then step 7 could get the first asoc
>> from ep->asoc_list and alloc a new sk2, attach the asoc to sk2.
>>
>> after a while, sendmsg schedule in, but asoc->sk is sk2, !=sk.
>> the same issue we fix for peeloff on commit dfcb9f4f99f1 ("sctp: deny
>> peeloff operation on asocs with threads sleeping on it") happens.
>
> Yes. That explains why the asoc isn't dead by when sendmsg comes back,
> and avoid that dead check.
>
>>
>> But we should not fix it by the same way as for peeloff. the real reason
>> causes this issue is on step 6, it should disallow listen on the established 
>> sk.
>
> Agreed.
>
>>
>> The following fix should work for this, just similar with what
>> inet_listen() did.
>>
>> @@ -7174,6 +7175,9 @@ int sctp_inet_listen(struct socket *sock, int backlog)
>> if (sock->state != SS_UNCONNECTED)
>> goto out;
>>
>> +   if (!sctp_sstate(sk, LISTENING) && !sctp_sstate(sk,CLOSED))
>> +   goto out;
>> +

This fixes the report.

Tested-by: Andrey Konovalov <andreyk...@google.com>

Thanks!

>>
>> what do you think ?
>
> Yes, agreed.
> Thanks!
>
>   Marcelo

Re: net/sctp: list double add warning in sctp_endpoint_add_asoc

[Andrey Konovalov]

On Tue, Apr 4, 2017 at 11:14 PM, Marcelo Ricardo Leitner
<marcelo.leit...@gmail.com> wrote:
> On Wed, Apr 05, 2017 at 01:29:19AM +0800, Xin Long wrote:
>> On Tue, Apr 4, 2017 at 9:28 PM, Andrey Konovalov <andreyk...@google.com> 
>> wrote:
>> > Hi,
>> >
>> > I've got the following error report while fuzzing the kernel with 
>> > syzkaller.
>> >
>> > On commit a71c9a1c779f2499fb2afc0553e543f18aff6edf (4.11-rc5).
>> >
>> > A reproducer and .config are attached.
>> The script is pretty hard to reproduce the issue in my env.
>
> I didn't try running it but I also found the reproducer very complicated
> to follow. Do you have any plans on having some PoC optimizer, so we can
> have a more readable code?
> strace is handy for filtering the noise, yes, but sometimes it doesn't
> cut it.

We do have some plans (like to remote all those unnecessary helper
functions), but it's probably not going to become much better.

You mostly only need to look at the thr() function to understand
what's going on.

What I sometimes do is run each of the switch cases under strace
separately to understand what each of them do.

I've also attached a program in syzkaller format.
You can take a look at it, if you find it useful, I can start
attaching them for subsequent reports.

>
>> But there seems a case to cause a use-after-free when out of snd_buf.
>>
>> the case is like:
>> ---
>> one thread:   another thread:
>>   sctp_rcv hold asoc (hold transport)
>>   enqueue the chunk to backlog queue
>>   [refcnt=2]
>>
>> sctp_close free assoc
>> [refcnt=1]
>>
>> sctp_sendmsg find asoc
>> but not hold it
>>
>> out of snd_buf
>> hold asoc, schedule out
>> [refcnt = 2]
>>
>>   process backlog and put asoc/transport
>>   [refcnt=1]
>>
>> schedule in, put asoc
>> [refcnt=0] <--- destroyed
>>
>> sctp_sendmsg continue
>
> It shouldn't be continuing here because sctp_wait_for_sndbuf and
> sctp_wait_for_connect functions are checking if the asoc is dead
> already when it schedules in, even though sctp_wait_for_connect return
> value is ignored and sctp_sendmsg() simply returns after that.
> Or the checks for dead asocs in there aren't enough somehow.
>
>> using asoc, panic
>
>
> --
> You received this message because you are subscribed to the Google Groups 
> "syzkaller" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to syzkaller+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.


log
Description: Binary data

net/ipv4: use-after-free in ipv4_mtu

[Andrey Konovalov]

Hi,

I've got the following error report while fuzzing the kernel with syzkaller.

On commit a71c9a1c779f2499fb2afc0553e543f18aff6edf (4.11-rc5).

Unfortunately it's not reproducible.

==
BUG: KASAN: use-after-free in dst_metric_raw include/net/dst.h:176
[inline] at addr 88003d6a965c
BUG: KASAN: use-after-free in ipv4_mtu+0x3f2/0x4b0
net/ipv4/route.c:1270 at addr 88003d6a965c
Read of size 4 by task syz-executor3/20611
CPU: 3 PID: 20611 Comm: syz-executor3 Not tainted 4.11.0-rc5+ #199
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011
Call Trace:
 __dump_stack lib/dump_stack.c:16 [inline]
 dump_stack+0x292/0x398 lib/dump_stack.c:52
 kasan_object_err+0x1c/0x70 mm/kasan/report.c:164
 print_address_description mm/kasan/report.c:202 [inline]
 kasan_report_error mm/kasan/report.c:291 [inline]
 kasan_report+0x252/0x510 mm/kasan/report.c:347
 __asan_report_load4_noabort+0x14/0x20 mm/kasan/report.c:367
 dst_metric_raw include/net/dst.h:176 [inline]
 ipv4_mtu+0x3f2/0x4b0 net/ipv4/route.c:1270
 dst_mtu include/net/dst.h:221 [inline]
 do_ip_getsockopt+0x71d/0x2290 net/ipv4/ip_sockglue.c:1433
 ip_getsockopt+0x90/0x230 net/ipv4/ip_sockglue.c:1578
 tcp_getsockopt+0x82/0xd0 net/ipv4/tcp.c:3131
 sock_common_getsockopt+0x95/0xd0 net/core/sock.c:2709
 SYSC_getsockopt net/socket.c:1829 [inline]
 SyS_getsockopt+0x252/0x390 net/socket.c:1811
 entry_SYSCALL_64_fastpath+0x1f/0xc2
RIP: 0033:0x4458d9
RSP: 002b:7fe87f452b58 EFLAGS: 0286 ORIG_RAX: 0037
RAX: ffda RBX: 0005 RCX: 004458d9
RDX: 000e RSI:  RDI: 0005
RBP: 006e0020 R08: 20db6000 R09: 
R10: 207e8000 R11: 0286 R12: 00708150
R13: 20db8000 R14: 1000 R15: 0003
Object at 88003d6a9658, in cache kmalloc-64 size: 64
Allocated:
PID = 20110
 save_stack_trace+0x16/0x20 arch/x86/kernel/stacktrace.c:59
 save_stack+0x43/0xd0 mm/kasan/kasan.c:513
 set_track mm/kasan/kasan.c:525 [inline]
 kasan_kmalloc+0xad/0xe0 mm/kasan/kasan.c:616
 kmem_cache_alloc_trace+0x82/0x270 mm/slub.c:2745
 kmalloc include/linux/slab.h:490 [inline]
 kzalloc include/linux/slab.h:663 [inline]
 fib_create_info+0x8e0/0x3a30 net/ipv4/fib_semantics.c:1040
 fib_table_insert+0x1a5/0x1550 net/ipv4/fib_trie.c:1221
 ip_rt_ioctl+0xddc/0x1590 net/ipv4/fib_frontend.c:597
 inet_ioctl+0xf2/0x1c0 net/ipv4/af_inet.c:882
sctp: [Deprecated]: syz-executor0 (pid 20638) Use of int in max_burst
socket option.
Use struct sctp_assoc_value instead
 sock_do_ioctl+0x65/0xb0 net/socket.c:906
 sock_ioctl+0x28f/0x440 net/socket.c:1004
 vfs_ioctl fs/ioctl.c:45 [inline]
 do_vfs_ioctl+0x1bf/0x1780 fs/ioctl.c:685
 SYSC_ioctl fs/ioctl.c:700 [inline]
 SyS_ioctl+0x8f/0xc0 fs/ioctl.c:691
 entry_SYSCALL_64_fastpath+0x1f/0xc2
Freed:
PID = 4439
 save_stack_trace+0x16/0x20 arch/x86/kernel/stacktrace.c:59
 save_stack+0x43/0xd0 mm/kasan/kasan.c:513
 set_track mm/kasan/kasan.c:525 [inline]
 kasan_slab_free+0x73/0xc0 mm/kasan/kasan.c:589
 slab_free_hook mm/slub.c:1357 [inline]
 slab_free_freelist_hook mm/slub.c:1379 [inline]
 slab_free mm/slub.c:2961 [inline]
 kfree+0xe8/0x2b0 mm/slub.c:3882
 free_fib_info_rcu+0x4ba/0x5e0 net/ipv4/fib_semantics.c:218
 __rcu_reclaim kernel/rcu/rcu.h:118 [inline]
 rcu_do_batch.isra.64+0x947/0xcc0 kernel/rcu/tree.c:2879
 invoke_rcu_callbacks kernel/rcu/tree.c:3142 [inline]
 __rcu_process_callbacks kernel/rcu/tree.c:3109 [inline]
 rcu_process_callbacks+0x2cc/0xb90 kernel/rcu/tree.c:3126
 __do_softirq+0x2fb/0xb7d kernel/softirq.c:284
Memory state around the buggy address:
 88003d6a9500: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
 88003d6a9580: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
>88003d6a9600: fc fc fc fc fc fc fc fc fc fc fc fb fb fb fb fb
^
 88003d6a9680: fb fb fb fc fc fc fc fc fc fc fc fc fc fc fc fc
 88003d6a9700: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
==

net/dccp: BUG in tfrc_rx_hist_sample_rtt

[Andrey Konovalov]

Hi,

I've got the following error report while fuzzing the kernel with syzkaller.

On commit a71c9a1c779f2499fb2afc0553e543f18aff6edf (4.11-rc5).

I'm able to reproduce it by executing the attached syzkaller prog, but
there's no simple C reproducer. My .config is attached.

BUG: please report to d...@vger.kernel.org => prev = 0, last = 0 at
net/dccp/ccids/lib/packet_history.c:427/tfrc_rx_hist_sample_rtt()
CPU: 1 PID: 4049 Comm: syz-executor Not tainted 4.11.0-rc5+ #199
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011
Call Trace:
 
 __dump_stack lib/dump_stack.c:16
 dump_stack+0x292/0x398 lib/dump_stack.c:52
 tfrc_rx_hist_sample_rtt+0x407/0x4d0 net/dccp/ccids/lib/packet_history.c:424
 ccid3_hc_rx_packet_recv+0x6a3/0xfb0 net/dccp/ccids/ccid3.c:764
 ccid_hc_rx_packet_recv net/dccp/ccid.h:185
 dccp_deliver_input_to_ccids+0xd9/0x250 net/dccp/input.c:180
 dccp_rcv_established+0x88/0xb0 net/dccp/input.c:378
 dccp_v6_do_rcv+0x2af/0x350 net/dccp/ipv6.c:600
 sk_backlog_rcv ./include/net/sock.h:898
 __sk_receive_skb+0x368/0xcb0 net/core/sock.c:469
 dccp_v6_rcv+0xba2/0x1cf0 net/dccp/ipv6.c:744
 ip6_input_finish+0x468/0x17b0 net/ipv6/ip6_input.c:279
 NF_HOOK ./include/linux/netfilter.h:257
 ip6_input+0xdb/0x590 net/ipv6/ip6_input.c:322
 dst_input ./include/net/dst.h:492
 ip6_rcv_finish+0x289/0x890 net/ipv6/ip6_input.c:69
 NF_HOOK ./include/linux/netfilter.h:257
 ipv6_rcv+0x12f1/0x23a0 net/ipv6/ip6_input.c:203
 __netif_receive_skb_core+0x1ad1/0x3400 net/core/dev.c:4207
 __netif_receive_skb+0x2a/0x170 net/core/dev.c:4245
 process_backlog+0xe5/0x6c0 net/core/dev.c:4865
 napi_poll net/core/dev.c:5267
 net_rx_action+0xe70/0x1900 net/core/dev.c:5332
 __do_softirq+0x2fb/0xb7d kernel/softirq.c:284
 do_softirq_own_stack+0x1c/0x30 arch/x86/entry/entry_64.S:902
 
 do_softirq.part.17+0x1e8/0x230 kernel/softirq.c:328
 do_softirq kernel/softirq.c:176
 __local_bh_enable_ip+0x1f2/0x200 kernel/softirq.c:181
 local_bh_enable ./include/linux/bottom_half.h:31
 rcu_read_unlock_bh ./include/linux/rcupdate.h:931
 ip6_finish_output2+0xc4e/0x2560 net/ipv6/ip6_output.c:124
 ip6_finish_output+0x302/0x960 net/ipv6/ip6_output.c:149
 NF_HOOK_COND ./include/linux/netfilter.h:246
 ip6_output+0x1cb/0x8d0 net/ipv6/ip6_output.c:163
 ip6_xmit+0xd38/0x2210 ./include/net/dst.h:486
 inet6_csk_xmit+0x331/0x610 net/ipv6/inet6_connection_sock.c:139
 dccp_transmit_skb+0xb09/0x1120 net/dccp/output.c:142
 dccp_xmit_packet+0x215/0x760 net/dccp/output.c:281
 dccp_write_xmit+0x168/0x1d0 net/dccp/output.c:363
 dccp_sendmsg+0x79c/0xb10 net/dccp/proto.c:796
 inet_sendmsg+0x164/0x5b0 net/ipv4/af_inet.c:762
 sock_sendmsg_nosec net/socket.c:633
 sock_sendmsg+0xca/0x110 net/socket.c:643
 SYSC_sendto+0x660/0x810 net/socket.c:1696
 SyS_sendto+0x40/0x50 net/socket.c:1664
 entry_SYSCALL_64_fastpath+0x1f/0xc2 arch/x86/entry/entry_64.S:204
RIP: 0033:0x4458d9
RSP: 002b:7f4a98d8ab58 EFLAGS: 0282 ORIG_RAX: 002c
RAX: ffda RBX: 0015 RCX: 004458d9
RDX: 007a RSI: 203c4000 RDI: 0015
RBP: 006e2fa0 R08: 20e6f000 R09: 000a
R10: 4000 R11: 0282 R12: 00708150
R13:  R14: 7f4a98d8b9c0 R15: 7f4a98d8b700
dccp_close: ABORT with 1 bytes unread


.config
Description: Binary data


dccp-history-bug-log
Description: Binary data

[PATCH net v2 2/3] net/packet: fix overflow in check for tp_frame_nr

[Andrey Konovalov]

When calculating rb->frames_per_block * req->tp_block_nr the result
can overflow.

Add a check that tp_block_size * tp_block_nr <= UINT_MAX.

Since frames_per_block <= tp_block_size, the expression would
never overflow.

Signed-off-by: Andrey Konovalov <andreyk...@google.com>
---
 net/packet/af_packet.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/net/packet/af_packet.c b/net/packet/af_packet.c
index 2323ee35dc09..3ac286ebb2f4 100644
--- a/net/packet/af_packet.c
+++ b/net/packet/af_packet.c
@@ -4205,6 +4205,8 @@ static int packet_set_ring(struct sock *sk, union 
tpacket_req_u *req_u,
rb->frames_per_block = req->tp_block_size / req->tp_frame_size;
if (unlikely(rb->frames_per_block == 0))
goto out;
+   if (unlikely(req->tp_block_size > UINT_MAX / req->tp_block_nr))
+   goto out;
if (unlikely((rb->frames_per_block * req->tp_block_nr) !=
req->tp_frame_nr))
goto out;
-- 
2.12.2.564.g063fe858b8-goog