2018-11-12 19:40:33

by Qian Cai

[permalink] [raw]
Subject: BUG: KASAN: slab-out-of-bounds in selinux_sctp_bind_connect+0x60/0x150

Running the trinity fuzzer on the latest mainline (rc2) generates this,

[15029.879626] BUG: KASAN: slab-out-of-bounds in selinux_sctp_bind_connect+0x60/0x150
[15029.887275] Read of size 2 at addr ffff801ec53c5080 by task trinity-main/18081
[15029.887294]
[15029.887304] CPU: 28 PID: 18081 Comm: trinity-main Tainted: G W OE 4.20.0-rc2+ #15
[15029.887311] Hardware name: Huawei TaiShan 2280 /BC11SPCD, BIOS 1.50 06/01/2018
[15000.084786] [15029.887320] Call trace:
[15029.915511] dump_backtrace+0x0/0x2c8
[15029.920046] show_stack+0x24/0x30
[15029.923367] dump_stack+0x118/0x19c
[15029.927539] print_address_description+0x68/0x2a0
[15029.932245] kasan_report+0x1b4/0x348
[15029.938760] __asan_load2+0x7c/0xa0
[15029.945098] selinux_sctp_bind_connect+0x60/0x150

[15029.950571] security_sctp_bind_connect+0x58/0x90
[15029.955493] __sctp_setsockopt_connectx+0x68/0x128 [sctp]
[15029.960943] sctp_setsockopt+0x764/0x2928 [sctp]
[15029.965564] sock_common_setsockopt+0x6c/0x80
[15029.969923] __arm64_sys_setsockopt+0x13c/0x1f0
[15029.974456] el0_svc_handler+0xd4/0x198
[15029.978293] el0_svc+0x8/0xc
[15029.981174]
[15029.982667] Allocated by task 18081:
[15029.986245] kasan_kmalloc.part.1+0x40/0x108
[15029.990517] kasan_kmalloc+0xb4/0xc8
[15029.994094] __kmalloc_node+0x1c4/0x638
[15029.997933] kvmalloc_node+0x98/0xa8
[15030.001511] vmemdup_user+0x34/0x128
[15030.005137] __sctp_setsockopt_connectx+0x44/0x128 [sctp]
[15030.010586] sctp_setsockopt+0x764/0x2928 [sctp]
[15030.015205] sock_common_setsockopt+0x6c/0x80
[15030.019564] __arm64_sys_setsockopt+0x13c/0x1f0
[15030.024096] el0_svc_handler+0xd4/0x198
[15030.027933] el0_svc+0x8/0xc
[15030.030814]
[15030.032306] Freed by task 3025:
[15030.035451] __kasan_slab_free+0x114/0x228
[15030.039548] kasan_slab_free+0x10/0x18
[15030.043299] kfree+0x114/0x408
[15030.046357] selinux_sk_free_security+0x38/0x48
[15030.050888] security_sk_free+0x3c/0x58
[15030.054727] __sk_destruct+0x3e8/0x570
[15030.058478] sk_destruct+0x4c/0x58
[15030.061881] __sk_free+0x68/0x138
[15030.065197] sk_free+0x3c/0x48
[15030.068255] unix_release_sock+0x4a8/0x550
[15030.072353] unix_release+0x34/0x50
[15030.075843] __sock_release+0x74/0x110
[15030.079593] sock_close+0x24/0x38
[15030.082913] __fput+0x1b8/0x368
[15030.086055] ____fput+0x20/0x30
[15030.089199] task_work_run+0x14c/0x1a8
[15030.092951] do_notify_resume+0x1e4/0x200
[15030.096961] work_pending+0x8/0x14
[15030.100363]
[15030.101856] The buggy address belongs to the object at ffff801ec53c5080
[15030.101856] which belongs to the cache kmalloc-128 of size 128
[15030.114376] The buggy address is located 0 bytes inside of
[15030.114376] 128-byte region [ffff801ec53c5080, ffff801ec53c5100)
[15030.125939] The buggy address belongs to the page:
[15030.130732] page:ffff7fe007b14f00 count:1 mapcount:0 mapping:ffff8016c0010480 index:0x0
[15030.138738] flags: 0x5fffff0000000200(slab)
[15030.142926] raw: 5fffff0000000200 ffff7fe007980608 ffff801ec000fd60 ffff8016c0010480
[15030.150671] raw: 0000000000000000 0000000000660066 00000001ffffffff 0000000000000000
[15030.158413] page dumped because: kasan: bad access detected
[15030.163984]
[15030.165476] Memory state around the buggy address:
[15030.170269] ffff801ec53c4f80: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
[15030.177491] ffff801ec53c5000: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
[15030.184714] >ffff801ec53c5080: 01 fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
[15030.191934] ^
[15030.195164] ffff801ec53c5100: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
[15030.202386] ffff801ec53c5180: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
[15030.209607] ==================================================================
[15030.216828] Disabling lock debugging due to kernel taint


2018-11-13 00:43:54

by Paul Moore

[permalink] [raw]
Subject: Re: BUG: KASAN: slab-out-of-bounds in selinux_sctp_bind_connect+0x60/0x150

On Mon, Nov 12, 2018 at 2:39 PM Qian Cai <[email protected]> wrote:
>
> Running the trinity fuzzer on the latest mainline (rc2) generates this,
>
> [15029.879626] BUG: KASAN: slab-out-of-bounds in selinux_sctp_bind_connect+0x60/0x150
> [15029.887275] Read of size 2 at addr ffff801ec53c5080 by task trinity-main/18081
> [15029.887294]
> [15029.887304] CPU: 28 PID: 18081 Comm: trinity-main Tainted: G W OE 4.20.0-rc2+ #15
> [15029.887311] Hardware name: Huawei TaiShan 2280 /BC11SPCD, BIOS 1.50 06/01/2018
> [15000.084786] [15029.887320] Call trace:
> [15029.915511] dump_backtrace+0x0/0x2c8
> [15029.920046] show_stack+0x24/0x30
> [15029.923367] dump_stack+0x118/0x19c
> [15029.927539] print_address_description+0x68/0x2a0
> [15029.932245] kasan_report+0x1b4/0x348
> [15029.938760] __asan_load2+0x7c/0xa0
> [15029.945098] selinux_sctp_bind_connect+0x60/0x150
>
> [15029.950571] security_sctp_bind_connect+0x58/0x90
> [15029.955493] __sctp_setsockopt_connectx+0x68/0x128 [sctp]
> [15029.960943] sctp_setsockopt+0x764/0x2928 [sctp]
> [15029.965564] sock_common_setsockopt+0x6c/0x80
> [15029.969923] __arm64_sys_setsockopt+0x13c/0x1f0
> [15029.974456] el0_svc_handler+0xd4/0x198
> [15029.978293] el0_svc+0x8/0xc
> [15029.981174]
> [15029.982667] Allocated by task 18081:
> [15029.986245] kasan_kmalloc.part.1+0x40/0x108
> [15029.990517] kasan_kmalloc+0xb4/0xc8
> [15029.994094] __kmalloc_node+0x1c4/0x638
> [15029.997933] kvmalloc_node+0x98/0xa8
> [15030.001511] vmemdup_user+0x34/0x128
> [15030.005137] __sctp_setsockopt_connectx+0x44/0x128 [sctp]
> [15030.010586] sctp_setsockopt+0x764/0x2928 [sctp]
> [15030.015205] sock_common_setsockopt+0x6c/0x80
> [15030.019564] __arm64_sys_setsockopt+0x13c/0x1f0
> [15030.024096] el0_svc_handler+0xd4/0x198
> [15030.027933] el0_svc+0x8/0xc
> [15030.030814]
> [15030.032306] Freed by task 3025:
> [15030.035451] __kasan_slab_free+0x114/0x228
> [15030.039548] kasan_slab_free+0x10/0x18
> [15030.043299] kfree+0x114/0x408
> [15030.046357] selinux_sk_free_security+0x38/0x48
> [15030.050888] security_sk_free+0x3c/0x58
> [15030.054727] __sk_destruct+0x3e8/0x570
> [15030.058478] sk_destruct+0x4c/0x58
> [15030.061881] __sk_free+0x68/0x138
> [15030.065197] sk_free+0x3c/0x48
> [15030.068255] unix_release_sock+0x4a8/0x550
> [15030.072353] unix_release+0x34/0x50
> [15030.075843] __sock_release+0x74/0x110
> [15030.079593] sock_close+0x24/0x38
> [15030.082913] __fput+0x1b8/0x368
> [15030.086055] ____fput+0x20/0x30
> [15030.089199] task_work_run+0x14c/0x1a8
> [15030.092951] do_notify_resume+0x1e4/0x200
> [15030.096961] work_pending+0x8/0x14

Any chance you have a reproducer for this? Or at the very least a
line number inside selinux_sctp_bind_connect()?

> [15030.101856] The buggy address belongs to the object at ffff801ec53c5080
> [15030.101856] which belongs to the cache kmalloc-128 of size 128
> [15030.114376] The buggy address is located 0 bytes inside of
> [15030.114376] 128-byte region [ffff801ec53c5080, ffff801ec53c5100)
> [15030.125939] The buggy address belongs to the page:
> [15030.130732] page:ffff7fe007b14f00 count:1 mapcount:0 mapping:ffff8016c0010480 index:0x0
> [15030.138738] flags: 0x5fffff0000000200(slab)
> [15030.142926] raw: 5fffff0000000200 ffff7fe007980608 ffff801ec000fd60 ffff8016c0010480
> [15030.150671] raw: 0000000000000000 0000000000660066 00000001ffffffff 0000000000000000
> [15030.158413] page dumped because: kasan: bad access detected
> [15030.163984]
> [15030.165476] Memory state around the buggy address:
> [15030.170269] ffff801ec53c4f80: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
> [15030.177491] ffff801ec53c5000: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
> [15030.184714] >ffff801ec53c5080: 01 fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
> [15030.191934] ^
> [15030.195164] ffff801ec53c5100: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
> [15030.202386] ffff801ec53c5180: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
> [15030.209607] ==================================================================
> [15030.216828] Disabling lock debugging due to kernel taint

--
paul moore
http://www.paul-moore.com

2018-11-13 01:04:10

by Qian Cai

[permalink] [raw]
Subject: Re: BUG: KASAN: slab-out-of-bounds in selinux_sctp_bind_connect+0x60/0x150



> On Nov 12, 2018, at 7:41 PM, Paul Moore <[email protected]> wrote:
>
> On Mon, Nov 12, 2018 at 2:39 PM Qian Cai <[email protected]> wrote:
>>
>> Running the trinity fuzzer on the latest mainline (rc2) generates this,
>>
>> [15029.879626] BUG: KASAN: slab-out-of-bounds in selinux_sctp_bind_connect+0x60/0x150
>> [15029.887275] Read of size 2 at addr ffff801ec53c5080 by task trinity-main/18081
>> [15029.887294]
>> [15029.887304] CPU: 28 PID: 18081 Comm: trinity-main Tainted: G W OE 4.20.0-rc2+ #15
>> [15029.887311] Hardware name: Huawei TaiShan 2280 /BC11SPCD, BIOS 1.50 06/01/2018
>> [15000.084786] [15029.887320] Call trace:
>> [15029.915511] dump_backtrace+0x0/0x2c8
>> [15029.920046] show_stack+0x24/0x30
>> [15029.923367] dump_stack+0x118/0x19c
>> [15029.927539] print_address_description+0x68/0x2a0
>> [15029.932245] kasan_report+0x1b4/0x348
>> [15029.938760] __asan_load2+0x7c/0xa0
>> [15029.945098] selinux_sctp_bind_connect+0x60/0x150
>>
>> [15029.950571] security_sctp_bind_connect+0x58/0x90
>> [15029.955493] __sctp_setsockopt_connectx+0x68/0x128 [sctp]
>> [15029.960943] sctp_setsockopt+0x764/0x2928 [sctp]
>> [15029.965564] sock_common_setsockopt+0x6c/0x80
>> [15029.969923] __arm64_sys_setsockopt+0x13c/0x1f0
>> [15029.974456] el0_svc_handler+0xd4/0x198
>> [15029.978293] el0_svc+0x8/0xc
>> [15029.981174]
>> [15029.982667] Allocated by task 18081:
>> [15029.986245] kasan_kmalloc.part.1+0x40/0x108
>> [15029.990517] kasan_kmalloc+0xb4/0xc8
>> [15029.994094] __kmalloc_node+0x1c4/0x638
>> [15029.997933] kvmalloc_node+0x98/0xa8
>> [15030.001511] vmemdup_user+0x34/0x128
>> [15030.005137] __sctp_setsockopt_connectx+0x44/0x128 [sctp]
>> [15030.010586] sctp_setsockopt+0x764/0x2928 [sctp]
>> [15030.015205] sock_common_setsockopt+0x6c/0x80
>> [15030.019564] __arm64_sys_setsockopt+0x13c/0x1f0
>> [15030.024096] el0_svc_handler+0xd4/0x198
>> [15030.027933] el0_svc+0x8/0xc
>> [15030.030814]
>> [15030.032306] Freed by task 3025:
>> [15030.035451] __kasan_slab_free+0x114/0x228
>> [15030.039548] kasan_slab_free+0x10/0x18
>> [15030.043299] kfree+0x114/0x408
>> [15030.046357] selinux_sk_free_security+0x38/0x48
>> [15030.050888] security_sk_free+0x3c/0x58
>> [15030.054727] __sk_destruct+0x3e8/0x570
>> [15030.058478] sk_destruct+0x4c/0x58
>> [15030.061881] __sk_free+0x68/0x138
>> [15030.065197] sk_free+0x3c/0x48
>> [15030.068255] unix_release_sock+0x4a8/0x550
>> [15030.072353] unix_release+0x34/0x50
>> [15030.075843] __sock_release+0x74/0x110
>> [15030.079593] sock_close+0x24/0x38
>> [15030.082913] __fput+0x1b8/0x368
>> [15030.086055] ____fput+0x20/0x30
>> [15030.089199] task_work_run+0x14c/0x1a8
>> [15030.092951] do_notify_resume+0x1e4/0x200
>> [15030.096961] work_pending+0x8/0x14
>
> Any chance you have a reproducer for this? Or at the very least a
> line number inside selinux_sctp_bind_connect()?
>
Yes, running trinity as non-root will trigger it all the time on this
aarch64 server so far.

$ trinity

https://github.com/kernelslacker/trinity.git

If you have a debug patch I am happy to try that as well if you
need to gather more information.

2018-11-13 03:12:10

by Paul Moore

[permalink] [raw]
Subject: Re: BUG: KASAN: slab-out-of-bounds in selinux_sctp_bind_connect+0x60/0x150

On Mon, Nov 12, 2018 at 7:59 PM Qian Cai <[email protected]> wrote:
> > On Nov 12, 2018, at 7:41 PM, Paul Moore <[email protected]> wrote:
> > On Mon, Nov 12, 2018 at 2:39 PM Qian Cai <[email protected]> wrote:
> >>
> >> Running the trinity fuzzer on the latest mainline (rc2) generates this,
> >>
> >> [15029.879626] BUG: KASAN: slab-out-of-bounds in selinux_sctp_bind_connect+0x60/0x150
> >> [15029.887275] Read of size 2 at addr ffff801ec53c5080 by task trinity-main/18081
> >> [15029.887294]
> >> [15029.887304] CPU: 28 PID: 18081 Comm: trinity-main Tainted: G W OE 4.20.0-rc2+ #15
> >> [15029.887311] Hardware name: Huawei TaiShan 2280 /BC11SPCD, BIOS 1.50 06/01/2018
> >> [15000.084786] [15029.887320] Call trace:
> >> [15029.915511] dump_backtrace+0x0/0x2c8
> >> [15029.920046] show_stack+0x24/0x30
> >> [15029.923367] dump_stack+0x118/0x19c
> >> [15029.927539] print_address_description+0x68/0x2a0
> >> [15029.932245] kasan_report+0x1b4/0x348
> >> [15029.938760] __asan_load2+0x7c/0xa0
> >> [15029.945098] selinux_sctp_bind_connect+0x60/0x150
> >>
> >> [15029.950571] security_sctp_bind_connect+0x58/0x90
> >> [15029.955493] __sctp_setsockopt_connectx+0x68/0x128 [sctp]
> >> [15029.960943] sctp_setsockopt+0x764/0x2928 [sctp]
> >> [15029.965564] sock_common_setsockopt+0x6c/0x80
> >> [15029.969923] __arm64_sys_setsockopt+0x13c/0x1f0
> >> [15029.974456] el0_svc_handler+0xd4/0x198
> >> [15029.978293] el0_svc+0x8/0xc
> >> [15029.981174]
> >> [15029.982667] Allocated by task 18081:
> >> [15029.986245] kasan_kmalloc.part.1+0x40/0x108
> >> [15029.990517] kasan_kmalloc+0xb4/0xc8
> >> [15029.994094] __kmalloc_node+0x1c4/0x638
> >> [15029.997933] kvmalloc_node+0x98/0xa8
> >> [15030.001511] vmemdup_user+0x34/0x128
> >> [15030.005137] __sctp_setsockopt_connectx+0x44/0x128 [sctp]
> >> [15030.010586] sctp_setsockopt+0x764/0x2928 [sctp]
> >> [15030.015205] sock_common_setsockopt+0x6c/0x80
> >> [15030.019564] __arm64_sys_setsockopt+0x13c/0x1f0
> >> [15030.024096] el0_svc_handler+0xd4/0x198
> >> [15030.027933] el0_svc+0x8/0xc
> >> [15030.030814]
> >> [15030.032306] Freed by task 3025:
> >> [15030.035451] __kasan_slab_free+0x114/0x228
> >> [15030.039548] kasan_slab_free+0x10/0x18
> >> [15030.043299] kfree+0x114/0x408
> >> [15030.046357] selinux_sk_free_security+0x38/0x48
> >> [15030.050888] security_sk_free+0x3c/0x58
> >> [15030.054727] __sk_destruct+0x3e8/0x570
> >> [15030.058478] sk_destruct+0x4c/0x58
> >> [15030.061881] __sk_free+0x68/0x138
> >> [15030.065197] sk_free+0x3c/0x48
> >> [15030.068255] unix_release_sock+0x4a8/0x550
> >> [15030.072353] unix_release+0x34/0x50
> >> [15030.075843] __sock_release+0x74/0x110
> >> [15030.079593] sock_close+0x24/0x38
> >> [15030.082913] __fput+0x1b8/0x368
> >> [15030.086055] ____fput+0x20/0x30
> >> [15030.089199] task_work_run+0x14c/0x1a8
> >> [15030.092951] do_notify_resume+0x1e4/0x200
> >> [15030.096961] work_pending+0x8/0x14
> >
> > Any chance you have a reproducer for this? Or at the very least a
> > line number inside selinux_sctp_bind_connect()?
> >
> Yes, running trinity as non-root will trigger it all the time on this
> aarch64 server so far.

Is it just aarch64, or are you seeing it on other arches as well?

> $ trinity
>
> https://github.com/kernelslacker/trinity.git
>
> If you have a debug patch I am happy to try that as well if you
> need to gather more information.

--
paul moore
http://www.paul-moore.com

2018-11-13 03:12:10

by Qian Cai

[permalink] [raw]
Subject: Re: BUG: KASAN: slab-out-of-bounds in selinux_sctp_bind_connect+0x60/0x150



> On Nov 12, 2018, at 10:09 PM, Paul Moore <[email protected]> wrote:
>
> On Mon, Nov 12, 2018 at 7:59 PM Qian Cai <[email protected]> wrote:
>>> On Nov 12, 2018, at 7:41 PM, Paul Moore <[email protected]> wrote:
>>> On Mon, Nov 12, 2018 at 2:39 PM Qian Cai <[email protected]> wrote:
>>>>
>>>> Running the trinity fuzzer on the latest mainline (rc2) generates this,
>>>>
>>>> [15029.879626] BUG: KASAN: slab-out-of-bounds in selinux_sctp_bind_connect+0x60/0x150
>>>> [15029.887275] Read of size 2 at addr ffff801ec53c5080 by task trinity-main/18081
>>>> [15029.887294]
>>>> [15029.887304] CPU: 28 PID: 18081 Comm: trinity-main Tainted: G W OE 4.20.0-rc2+ #15
>>>> [15029.887311] Hardware name: Huawei TaiShan 2280 /BC11SPCD, BIOS 1.50 06/01/2018
>>>> [15000.084786] [15029.887320] Call trace:
>>>> [15029.915511] dump_backtrace+0x0/0x2c8
>>>> [15029.920046] show_stack+0x24/0x30
>>>> [15029.923367] dump_stack+0x118/0x19c
>>>> [15029.927539] print_address_description+0x68/0x2a0
>>>> [15029.932245] kasan_report+0x1b4/0x348
>>>> [15029.938760] __asan_load2+0x7c/0xa0
>>>> [15029.945098] selinux_sctp_bind_connect+0x60/0x150
>>>>
>>>> [15029.950571] security_sctp_bind_connect+0x58/0x90
>>>> [15029.955493] __sctp_setsockopt_connectx+0x68/0x128 [sctp]
>>>> [15029.960943] sctp_setsockopt+0x764/0x2928 [sctp]
>>>> [15029.965564] sock_common_setsockopt+0x6c/0x80
>>>> [15029.969923] __arm64_sys_setsockopt+0x13c/0x1f0
>>>> [15029.974456] el0_svc_handler+0xd4/0x198
>>>> [15029.978293] el0_svc+0x8/0xc
>>>> [15029.981174]
>>>> [15029.982667] Allocated by task 18081:
>>>> [15029.986245] kasan_kmalloc.part.1+0x40/0x108
>>>> [15029.990517] kasan_kmalloc+0xb4/0xc8
>>>> [15029.994094] __kmalloc_node+0x1c4/0x638
>>>> [15029.997933] kvmalloc_node+0x98/0xa8
>>>> [15030.001511] vmemdup_user+0x34/0x128
>>>> [15030.005137] __sctp_setsockopt_connectx+0x44/0x128 [sctp]
>>>> [15030.010586] sctp_setsockopt+0x764/0x2928 [sctp]
>>>> [15030.015205] sock_common_setsockopt+0x6c/0x80
>>>> [15030.019564] __arm64_sys_setsockopt+0x13c/0x1f0
>>>> [15030.024096] el0_svc_handler+0xd4/0x198
>>>> [15030.027933] el0_svc+0x8/0xc
>>>> [15030.030814]
>>>> [15030.032306] Freed by task 3025:
>>>> [15030.035451] __kasan_slab_free+0x114/0x228
>>>> [15030.039548] kasan_slab_free+0x10/0x18
>>>> [15030.043299] kfree+0x114/0x408
>>>> [15030.046357] selinux_sk_free_security+0x38/0x48
>>>> [15030.050888] security_sk_free+0x3c/0x58
>>>> [15030.054727] __sk_destruct+0x3e8/0x570
>>>> [15030.058478] sk_destruct+0x4c/0x58
>>>> [15030.061881] __sk_free+0x68/0x138
>>>> [15030.065197] sk_free+0x3c/0x48
>>>> [15030.068255] unix_release_sock+0x4a8/0x550
>>>> [15030.072353] unix_release+0x34/0x50
>>>> [15030.075843] __sock_release+0x74/0x110
>>>> [15030.079593] sock_close+0x24/0x38
>>>> [15030.082913] __fput+0x1b8/0x368
>>>> [15030.086055] ____fput+0x20/0x30
>>>> [15030.089199] task_work_run+0x14c/0x1a8
>>>> [15030.092951] do_notify_resume+0x1e4/0x200
>>>> [15030.096961] work_pending+0x8/0x14
>>>
>>> Any chance you have a reproducer for this? Or at the very least a
>>> line number inside selinux_sctp_bind_connect()?
>>>
>> Yes, running trinity as non-root will trigger it all the time on this
>> aarch64 server so far.
>
> Is it just aarch64, or are you seeing it on other arches as well?
I only have an aarch64 server to test so far.
>
>> $ trinity
>>
>> https://github.com/kernelslacker/trinity.git
>>
>> If you have a debug patch I am happy to try that as well if you
>> need to gather more information.
>
> --
> paul moore
> http://www.paul-moore.com


2018-11-13 13:34:51

by Paul Moore

[permalink] [raw]
Subject: Re: BUG: KASAN: slab-out-of-bounds in selinux_sctp_bind_connect+0x60/0x150

On Mon, Nov 12, 2018 at 10:11 PM Qian Cai <[email protected]> wrote:
> > On Nov 12, 2018, at 10:09 PM, Paul Moore <[email protected]> wrote:
> >
> > On Mon, Nov 12, 2018 at 7:59 PM Qian Cai <[email protected]> wrote:
> >>> On Nov 12, 2018, at 7:41 PM, Paul Moore <[email protected]> wrote:
> >>> On Mon, Nov 12, 2018 at 2:39 PM Qian Cai <[email protected]> wrote:
> >>>>
> >>>> Running the trinity fuzzer on the latest mainline (rc2) generates this,
> >>>>
> >>>> [15029.879626] BUG: KASAN: slab-out-of-bounds in selinux_sctp_bind_connect+0x60/0x150
> >>>> [15029.887275] Read of size 2 at addr ffff801ec53c5080 by task trinity-main/18081
> >>>> [15029.887294]
> >>>> [15029.887304] CPU: 28 PID: 18081 Comm: trinity-main Tainted: G W OE 4.20.0-rc2+ #15
> >>>> [15029.887311] Hardware name: Huawei TaiShan 2280 /BC11SPCD, BIOS 1.50 06/01/2018
> >>>> [15000.084786] [15029.887320] Call trace:
> >>>> [15029.915511] dump_backtrace+0x0/0x2c8
> >>>> [15029.920046] show_stack+0x24/0x30
> >>>> [15029.923367] dump_stack+0x118/0x19c
> >>>> [15029.927539] print_address_description+0x68/0x2a0
> >>>> [15029.932245] kasan_report+0x1b4/0x348
> >>>> [15029.938760] __asan_load2+0x7c/0xa0
> >>>> [15029.945098] selinux_sctp_bind_connect+0x60/0x150
> >>>>
> >>>> [15029.950571] security_sctp_bind_connect+0x58/0x90
> >>>> [15029.955493] __sctp_setsockopt_connectx+0x68/0x128 [sctp]
> >>>> [15029.960943] sctp_setsockopt+0x764/0x2928 [sctp]
> >>>> [15029.965564] sock_common_setsockopt+0x6c/0x80
> >>>> [15029.969923] __arm64_sys_setsockopt+0x13c/0x1f0
> >>>> [15029.974456] el0_svc_handler+0xd4/0x198
> >>>> [15029.978293] el0_svc+0x8/0xc
> >>>> [15029.981174]
> >>>> [15029.982667] Allocated by task 18081:
> >>>> [15029.986245] kasan_kmalloc.part.1+0x40/0x108
> >>>> [15029.990517] kasan_kmalloc+0xb4/0xc8
> >>>> [15029.994094] __kmalloc_node+0x1c4/0x638
> >>>> [15029.997933] kvmalloc_node+0x98/0xa8
> >>>> [15030.001511] vmemdup_user+0x34/0x128
> >>>> [15030.005137] __sctp_setsockopt_connectx+0x44/0x128 [sctp]
> >>>> [15030.010586] sctp_setsockopt+0x764/0x2928 [sctp]
> >>>> [15030.015205] sock_common_setsockopt+0x6c/0x80
> >>>> [15030.019564] __arm64_sys_setsockopt+0x13c/0x1f0
> >>>> [15030.024096] el0_svc_handler+0xd4/0x198
> >>>> [15030.027933] el0_svc+0x8/0xc
> >>>> [15030.030814]
> >>>> [15030.032306] Freed by task 3025:
> >>>> [15030.035451] __kasan_slab_free+0x114/0x228
> >>>> [15030.039548] kasan_slab_free+0x10/0x18
> >>>> [15030.043299] kfree+0x114/0x408
> >>>> [15030.046357] selinux_sk_free_security+0x38/0x48
> >>>> [15030.050888] security_sk_free+0x3c/0x58
> >>>> [15030.054727] __sk_destruct+0x3e8/0x570
> >>>> [15030.058478] sk_destruct+0x4c/0x58
> >>>> [15030.061881] __sk_free+0x68/0x138
> >>>> [15030.065197] sk_free+0x3c/0x48
> >>>> [15030.068255] unix_release_sock+0x4a8/0x550
> >>>> [15030.072353] unix_release+0x34/0x50
> >>>> [15030.075843] __sock_release+0x74/0x110
> >>>> [15030.079593] sock_close+0x24/0x38
> >>>> [15030.082913] __fput+0x1b8/0x368
> >>>> [15030.086055] ____fput+0x20/0x30
> >>>> [15030.089199] task_work_run+0x14c/0x1a8
> >>>> [15030.092951] do_notify_resume+0x1e4/0x200
> >>>> [15030.096961] work_pending+0x8/0x14
> >>>
> >>> Any chance you have a reproducer for this? Or at the very least a
> >>> line number inside selinux_sctp_bind_connect()?
> >>>
> >> Yes, running trinity as non-root will trigger it all the time on this
> >> aarch64 server so far.
> >
> > Is it just aarch64, or are you seeing it on other arches as well?
>
> I only have an aarch64 server to test so far.

Did you see similar problems with 4.20-rc1?

> >> $ trinity
> >>
> >> https://github.com/kernelslacker/trinity.git
> >>
> >> If you have a debug patch I am happy to try that as well if you
> >> need to gather more information.

--
paul moore
http://www.paul-moore.com

2018-11-13 13:53:51

by Qian Cai

[permalink] [raw]
Subject: Re: BUG: KASAN: slab-out-of-bounds in selinux_sctp_bind_connect+0x60/0x150

On 11/13/18 at 8:33 AM, Paul Moore wrote:

> On Mon, Nov 12, 2018 at 10:11 PM Qian Cai <[email protected]> wrote:
> > > On Nov 12, 2018, at 10:09 PM, Paul Moore <[email protected]> wrote:
> > >
> > > On Mon, Nov 12, 2018 at 7:59 PM Qian Cai <[email protected]> wrote:
> > >>> On Nov 12, 2018, at 7:41 PM, Paul Moore <[email protected]> wrote:
> > >>> On Mon, Nov 12, 2018 at 2:39 PM Qian Cai <[email protected]> wrote:
> > >>>>
> > >>>> Running the trinity fuzzer on the latest mainline (rc2) generates this,
> > >>>>
> > >>>> [15029.879626] BUG: KASAN: slab-out-of-bounds in selinux_sctp_bind_connect+0x60/0x150
> > >>>> [15029.887275] Read of size 2 at addr ffff801ec53c5080 by task trinity-main/18081
> > >>>> [15029.887294]
> > >>>> [15029.887304] CPU: 28 PID: 18081 Comm: trinity-main Tainted: G W OE 4.20.0-rc2+ #15
> > >>>> [15029.887311] Hardware name: Huawei TaiShan 2280 /BC11SPCD, BIOS 1.50 06/01/2018
> > >>>> [15000.084786] [15029.887320] Call trace:
> > >>>> [15029.915511] dump_backtrace+0x0/0x2c8
> > >>>> [15029.920046] show_stack+0x24/0x30
> > >>>> [15029.923367] dump_stack+0x118/0x19c
> > >>>> [15029.927539] print_address_description+0x68/0x2a0
> > >>>> [15029.932245] kasan_report+0x1b4/0x348
> > >>>> [15029.938760] __asan_load2+0x7c/0xa0
> > >>>> [15029.945098] selinux_sctp_bind_connect+0x60/0x150
> > >>>>
> > >>>> [15029.950571] security_sctp_bind_connect+0x58/0x90
> > >>>> [15029.955493] __sctp_setsockopt_connectx+0x68/0x128 [sctp]
> > >>>> [15029.960943] sctp_setsockopt+0x764/0x2928 [sctp]
> > >>>> [15029.965564] sock_common_setsockopt+0x6c/0x80
> > >>>> [15029.969923] __arm64_sys_setsockopt+0x13c/0x1f0
> > >>>> [15029.974456] el0_svc_handler+0xd4/0x198
> > >>>> [15029.978293] el0_svc+0x8/0xc
> > >>>> [15029.981174]
> > >>>> [15029.982667] Allocated by task 18081:
> > >>>> [15029.986245] kasan_kmalloc.part.1+0x40/0x108
> > >>>> [15029.990517] kasan_kmalloc+0xb4/0xc8
> > >>>> [15029.994094] __kmalloc_node+0x1c4/0x638
> > >>>> [15029.997933] kvmalloc_node+0x98/0xa8
> > >>>> [15030.001511] vmemdup_user+0x34/0x128
> > >>>> [15030.005137] __sctp_setsockopt_connectx+0x44/0x128 [sctp]
> > >>>> [15030.010586] sctp_setsockopt+0x764/0x2928 [sctp]
> > >>>> [15030.015205] sock_common_setsockopt+0x6c/0x80
> > >>>> [15030.019564] __arm64_sys_setsockopt+0x13c/0x1f0
> > >>>> [15030.024096] el0_svc_handler+0xd4/0x198
> > >>>> [15030.027933] el0_svc+0x8/0xc
> > >>>> [15030.030814]
> > >>>> [15030.032306] Freed by task 3025:
> > >>>> [15030.035451] __kasan_slab_free+0x114/0x228
> > >>>> [15030.039548] kasan_slab_free+0x10/0x18
> > >>>> [15030.043299] kfree+0x114/0x408
> > >>>> [15030.046357] selinux_sk_free_security+0x38/0x48
> > >>>> [15030.050888] security_sk_free+0x3c/0x58
> > >>>> [15030.054727] __sk_destruct+0x3e8/0x570
> > >>>> [15030.058478] sk_destruct+0x4c/0x58
> > >>>> [15030.061881] __sk_free+0x68/0x138
> > >>>> [15030.065197] sk_free+0x3c/0x48
> > >>>> [15030.068255] unix_release_sock+0x4a8/0x550
> > >>>> [15030.072353] unix_release+0x34/0x50
> > >>>> [15030.075843] __sock_release+0x74/0x110
> > >>>> [15030.079593] sock_close+0x24/0x38
> > >>>> [15030.082913] __fput+0x1b8/0x368
> > >>>> [15030.086055] ____fput+0x20/0x30
> > >>>> [15030.089199] task_work_run+0x14c/0x1a8
> > >>>> [15030.092951] do_notify_resume+0x1e4/0x200
> > >>>> [15030.096961] work_pending+0x8/0x14
> > >>>
> > >>> Any chance you have a reproducer for this? Or at the very least a
> > >>> line number inside selinux_sctp_bind_connect()?
> > >>>
> > >> Yes, running trinity as non-root will trigger it all the time on this
> > >> aarch64 server so far.
> > >
> > > Is it just aarch64, or are you seeing it on other arches as well?
> >
> > I only have an aarch64 server to test so far.
>
> Did you see similar problems with 4.20-rc1?
I did not test on -rc1.
>
> > >> $ trinity
> > >>
> > >> https://github.com/kernelslacker/trinity.git
> > >>
> > >> If you have a debug patch I am happy to try that as well if you
> > >> need to gather more information.
>
> --
> paul moore
> http://www.paul-moore.com

2018-11-13 14:31:22

by Paul Moore

[permalink] [raw]
Subject: Re: BUG: KASAN: slab-out-of-bounds in selinux_sctp_bind_connect+0x60/0x150

On Tue, Nov 13, 2018 at 8:52 AM Qian Cai <[email protected]> wrote:
> On 11/13/18 at 8:33 AM, Paul Moore wrote:
> > On Mon, Nov 12, 2018 at 10:11 PM Qian Cai <[email protected]> wrote:
> > > > On Nov 12, 2018, at 10:09 PM, Paul Moore <[email protected]> wrote:
> > > >
> > > > On Mon, Nov 12, 2018 at 7:59 PM Qian Cai <[email protected]> wrote:
> > > >>> On Nov 12, 2018, at 7:41 PM, Paul Moore <[email protected]> wrote:
> > > >>> On Mon, Nov 12, 2018 at 2:39 PM Qian Cai <[email protected]> wrote:
> > > >>>>
> > > >>>> Running the trinity fuzzer on the latest mainline (rc2) generates this,
> > > >>>>
> > > >>>> [15029.879626] BUG: KASAN: slab-out-of-bounds in selinux_sctp_bind_connect+0x60/0x150
> > > >>>> [15029.887275] Read of size 2 at addr ffff801ec53c5080 by task trinity-main/18081
> > > >>>> [15029.887294]
> > > >>>> [15029.887304] CPU: 28 PID: 18081 Comm: trinity-main Tainted: G W OE 4.20.0-rc2+ #15
> > > >>>> [15029.887311] Hardware name: Huawei TaiShan 2280 /BC11SPCD, BIOS 1.50 06/01/2018
> > > >>>> [15000.084786] [15029.887320] Call trace:
> > > >>>> [15029.915511] dump_backtrace+0x0/0x2c8
> > > >>>> [15029.920046] show_stack+0x24/0x30
> > > >>>> [15029.923367] dump_stack+0x118/0x19c
> > > >>>> [15029.927539] print_address_description+0x68/0x2a0
> > > >>>> [15029.932245] kasan_report+0x1b4/0x348
> > > >>>> [15029.938760] __asan_load2+0x7c/0xa0
> > > >>>> [15029.945098] selinux_sctp_bind_connect+0x60/0x150
> > > >>>>
> > > >>>> [15029.950571] security_sctp_bind_connect+0x58/0x90
> > > >>>> [15029.955493] __sctp_setsockopt_connectx+0x68/0x128 [sctp]
> > > >>>> [15029.960943] sctp_setsockopt+0x764/0x2928 [sctp]
> > > >>>> [15029.965564] sock_common_setsockopt+0x6c/0x80
> > > >>>> [15029.969923] __arm64_sys_setsockopt+0x13c/0x1f0
> > > >>>> [15029.974456] el0_svc_handler+0xd4/0x198
> > > >>>> [15029.978293] el0_svc+0x8/0xc
> > > >>>> [15029.981174]
> > > >>>> [15029.982667] Allocated by task 18081:
> > > >>>> [15029.986245] kasan_kmalloc.part.1+0x40/0x108
> > > >>>> [15029.990517] kasan_kmalloc+0xb4/0xc8
> > > >>>> [15029.994094] __kmalloc_node+0x1c4/0x638
> > > >>>> [15029.997933] kvmalloc_node+0x98/0xa8
> > > >>>> [15030.001511] vmemdup_user+0x34/0x128
> > > >>>> [15030.005137] __sctp_setsockopt_connectx+0x44/0x128 [sctp]
> > > >>>> [15030.010586] sctp_setsockopt+0x764/0x2928 [sctp]
> > > >>>> [15030.015205] sock_common_setsockopt+0x6c/0x80
> > > >>>> [15030.019564] __arm64_sys_setsockopt+0x13c/0x1f0
> > > >>>> [15030.024096] el0_svc_handler+0xd4/0x198
> > > >>>> [15030.027933] el0_svc+0x8/0xc
> > > >>>> [15030.030814]
> > > >>>> [15030.032306] Freed by task 3025:
> > > >>>> [15030.035451] __kasan_slab_free+0x114/0x228
> > > >>>> [15030.039548] kasan_slab_free+0x10/0x18
> > > >>>> [15030.043299] kfree+0x114/0x408
> > > >>>> [15030.046357] selinux_sk_free_security+0x38/0x48
> > > >>>> [15030.050888] security_sk_free+0x3c/0x58
> > > >>>> [15030.054727] __sk_destruct+0x3e8/0x570
> > > >>>> [15030.058478] sk_destruct+0x4c/0x58
> > > >>>> [15030.061881] __sk_free+0x68/0x138
> > > >>>> [15030.065197] sk_free+0x3c/0x48
> > > >>>> [15030.068255] unix_release_sock+0x4a8/0x550
> > > >>>> [15030.072353] unix_release+0x34/0x50
> > > >>>> [15030.075843] __sock_release+0x74/0x110
> > > >>>> [15030.079593] sock_close+0x24/0x38
> > > >>>> [15030.082913] __fput+0x1b8/0x368
> > > >>>> [15030.086055] ____fput+0x20/0x30
> > > >>>> [15030.089199] task_work_run+0x14c/0x1a8
> > > >>>> [15030.092951] do_notify_resume+0x1e4/0x200
> > > >>>> [15030.096961] work_pending+0x8/0x14
> > > >>>
> > > >>> Any chance you have a reproducer for this? Or at the very least a
> > > >>> line number inside selinux_sctp_bind_connect()?
> > > >>>
> > > >> Yes, running trinity as non-root will trigger it all the time on this
> > > >> aarch64 server so far.
> > > >
> > > > Is it just aarch64, or are you seeing it on other arches as well?
> > >
> > > I only have an aarch64 server to test so far.
> >
> > Did you see similar problems with 4.20-rc1?
>
> I did not test on -rc1.

I ran trinity a few times on my test kernel and nothing terrible
happened; this was expected since I don't have KASAN enabled in my
kernel builds at the moment. I'm building a kernel with KASAN right
now to see if I can reproduce this on x86_64 (I don't have easy access
to a aarch64 system).

It might be helpful if you could also try to debug this issue just in
case it happens to be aarch64 specific or has something to do with
your particular configuration.

> > > >> $ trinity
> > > >>
> > > >> https://github.com/kernelslacker/trinity.git
> > > >>
> > > >> If you have a debug patch I am happy to try that as well if you
> > > >> need to gather more information.

--
paul moore
http://www.paul-moore.com

2018-11-13 15:19:15

by Ondrej Mosnacek

[permalink] [raw]
Subject: [PATCH] selinux: check length properly in SCTP bind hook

selinux_sctp_bind_connect() must verify if the address buffer has
sufficient length before accessing the 'sa_family' field. See
__sctp_connect() for a similar check.

The length of the whole address ('len') is already checked in the
callees.

Reported-by: Qian Cai <[email protected]>
Fixes: d452930fd3b9 ("selinux: Add SCTP support")
Cc: <[email protected]> # 4.17+
Cc: Richard Haines <[email protected]>
Signed-off-by: Ondrej Mosnacek <[email protected]>
---
Hi,

On Mon, Nov 12, 2018 at 8:39 PM Qian Cai <[email protected]> wrote:
> Running the trinity fuzzer on the latest mainline (rc2) generates this,
>
> [15029.879626] BUG: KASAN: slab-out-of-bounds in selinux_sctp_bind_connect+0x60/0x150
> [15029.887275] Read of size 2 at addr ffff801ec53c5080 by task trinity-main/18081
> [15029.887294]
> [15029.887304] CPU: 28 PID: 18081 Comm: trinity-main Tainted: G W OE 4.20.0-rc2+ #15
> [15029.887311] Hardware name: Huawei TaiShan 2280 /BC11SPCD, BIOS 1.50 06/01/2018
> [15000.084786] [15029.887320] Call trace:
> [15029.915511] dump_backtrace+0x0/0x2c8
> [15029.920046] show_stack+0x24/0x30
> [15029.923367] dump_stack+0x118/0x19c
> [15029.927539] print_address_description+0x68/0x2a0
> [15029.932245] kasan_report+0x1b4/0x348
> [15029.938760] __asan_load2+0x7c/0xa0
> [15029.945098] selinux_sctp_bind_connect+0x60/0x150
>
> [15029.950571] security_sctp_bind_connect+0x58/0x90
> [15029.955493] __sctp_setsockopt_connectx+0x68/0x128 [sctp]
> [15029.960943] sctp_setsockopt+0x764/0x2928 [sctp]
> [15029.965564] sock_common_setsockopt+0x6c/0x80
> [15029.969923] __arm64_sys_setsockopt+0x13c/0x1f0
> [15029.974456] el0_svc_handler+0xd4/0x198
> [15029.978293] el0_svc+0x8/0xc
> [15029.981174]
> [15029.982667] Allocated by task 18081:
> [15029.986245] kasan_kmalloc.part.1+0x40/0x108
> [15029.990517] kasan_kmalloc+0xb4/0xc8
> [15029.994094] __kmalloc_node+0x1c4/0x638
> [15029.997933] kvmalloc_node+0x98/0xa8
> [15030.001511] vmemdup_user+0x34/0x128
> [15030.005137] __sctp_setsockopt_connectx+0x44/0x128 [sctp]
> [15030.010586] sctp_setsockopt+0x764/0x2928 [sctp]
> [15030.015205] sock_common_setsockopt+0x6c/0x80
> [15030.019564] __arm64_sys_setsockopt+0x13c/0x1f0
> [15030.024096] el0_svc_handler+0xd4/0x198
> [15030.027933] el0_svc+0x8/0xc
> [15030.030814]
> [15030.032306] Freed by task 3025:
> [15030.035451] __kasan_slab_free+0x114/0x228
> [15030.039548] kasan_slab_free+0x10/0x18
> [15030.043299] kfree+0x114/0x408
> [15030.046357] selinux_sk_free_security+0x38/0x48
> [15030.050888] security_sk_free+0x3c/0x58
> [15030.054727] __sk_destruct+0x3e8/0x570
> [15030.058478] sk_destruct+0x4c/0x58
> [15030.061881] __sk_free+0x68/0x138
> [15030.065197] sk_free+0x3c/0x48
> [15030.068255] unix_release_sock+0x4a8/0x550
> [15030.072353] unix_release+0x34/0x50
> [15030.075843] __sock_release+0x74/0x110
> [15030.079593] sock_close+0x24/0x38
> [15030.082913] __fput+0x1b8/0x368
> [15030.086055] ____fput+0x20/0x30
> [15030.089199] task_work_run+0x14c/0x1a8
> [15030.092951] do_notify_resume+0x1e4/0x200
> [15030.096961] work_pending+0x8/0x14
> [15030.100363]
> [15030.101856] The buggy address belongs to the object at ffff801ec53c5080
> [15030.101856] which belongs to the cache kmalloc-128 of size 128
> [15030.114376] The buggy address is located 0 bytes inside of
> [15030.114376] 128-byte region [ffff801ec53c5080, ffff801ec53c5100)
> [15030.125939] The buggy address belongs to the page:
> [15030.130732] page:ffff7fe007b14f00 count:1 mapcount:0 mapping:ffff8016c0010480 index:0x0
> [15030.138738] flags: 0x5fffff0000000200(slab)
> [15030.142926] raw: 5fffff0000000200 ffff7fe007980608 ffff801ec000fd60 ffff8016c0010480
> [15030.150671] raw: 0000000000000000 0000000000660066 00000001ffffffff 0000000000000000
> [15030.158413] page dumped because: kasan: bad access detected
> [15030.163984]
> [15030.165476] Memory state around the buggy address:
> [15030.170269] ffff801ec53c4f80: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
> [15030.177491] ffff801ec53c5000: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
> [15030.184714] >ffff801ec53c5080: 01 fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
> [15030.191934] ^
> [15030.195164] ffff801ec53c5100: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
> [15030.202386] ffff801ec53c5180: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
> [15030.209607] ==================================================================
> [15030.216828] Disabling lock debugging due to kernel taint

I think I found the cause - Qian, can you test this patch if it fixes
the problem?

security/selinux/hooks.c | 3 +++
1 file changed, 3 insertions(+)

diff --git a/security/selinux/hooks.c b/security/selinux/hooks.c
index 7ce683259357..a67459eb62d5 100644
--- a/security/selinux/hooks.c
+++ b/security/selinux/hooks.c
@@ -5318,6 +5318,9 @@ static int selinux_sctp_bind_connect(struct sock *sk, int optname,
addr_buf = address;

while (walk_size < addrlen) {
+ if (walk_size + sizeof(sa_family_t) > addrlen)
+ return -EINVAL;
+
addr = addr_buf;
switch (addr->sa_family) {
case AF_UNSPEC:
--
2.17.2


2018-11-13 15:53:30

by Paul Moore

[permalink] [raw]
Subject: Re: [PATCH] selinux: check length properly in SCTP bind hook

On Tue, Nov 13, 2018 at 10:18 AM Ondrej Mosnacek <[email protected]> wrote:
>
> selinux_sctp_bind_connect() must verify if the address buffer has
> sufficient length before accessing the 'sa_family' field. See
> __sctp_connect() for a similar check.
>
> The length of the whole address ('len') is already checked in the
> callees.
>
> Reported-by: Qian Cai <[email protected]>
> Fixes: d452930fd3b9 ("selinux: Add SCTP support")
> Cc: <[email protected]> # 4.17+
> Cc: Richard Haines <[email protected]>
> Signed-off-by: Ondrej Mosnacek <[email protected]>
> ---
> Hi,
>
> On Mon, Nov 12, 2018 at 8:39 PM Qian Cai <[email protected]> wrote:
> > Running the trinity fuzzer on the latest mainline (rc2) generates this,
> >
> > [15029.879626] BUG: KASAN: slab-out-of-bounds in selinux_sctp_bind_connect+0x60/0x150
> > [15029.887275] Read of size 2 at addr ffff801ec53c5080 by task trinity-main/18081
> > [15029.887294]
> > [15029.887304] CPU: 28 PID: 18081 Comm: trinity-main Tainted: G W OE 4.20.0-rc2+ #15
> > [15029.887311] Hardware name: Huawei TaiShan 2280 /BC11SPCD, BIOS 1.50 06/01/2018
> > [15000.084786] [15029.887320] Call trace:
> > [15029.915511] dump_backtrace+0x0/0x2c8
> > [15029.920046] show_stack+0x24/0x30
> > [15029.923367] dump_stack+0x118/0x19c
> > [15029.927539] print_address_description+0x68/0x2a0
> > [15029.932245] kasan_report+0x1b4/0x348
> > [15029.938760] __asan_load2+0x7c/0xa0
> > [15029.945098] selinux_sctp_bind_connect+0x60/0x150
> >
> > [15029.950571] security_sctp_bind_connect+0x58/0x90
> > [15029.955493] __sctp_setsockopt_connectx+0x68/0x128 [sctp]
> > [15029.960943] sctp_setsockopt+0x764/0x2928 [sctp]
> > [15029.965564] sock_common_setsockopt+0x6c/0x80
> > [15029.969923] __arm64_sys_setsockopt+0x13c/0x1f0
> > [15029.974456] el0_svc_handler+0xd4/0x198
> > [15029.978293] el0_svc+0x8/0xc
> > [15029.981174]
> > [15029.982667] Allocated by task 18081:
> > [15029.986245] kasan_kmalloc.part.1+0x40/0x108
> > [15029.990517] kasan_kmalloc+0xb4/0xc8
> > [15029.994094] __kmalloc_node+0x1c4/0x638
> > [15029.997933] kvmalloc_node+0x98/0xa8
> > [15030.001511] vmemdup_user+0x34/0x128
> > [15030.005137] __sctp_setsockopt_connectx+0x44/0x128 [sctp]
> > [15030.010586] sctp_setsockopt+0x764/0x2928 [sctp]
> > [15030.015205] sock_common_setsockopt+0x6c/0x80
> > [15030.019564] __arm64_sys_setsockopt+0x13c/0x1f0
> > [15030.024096] el0_svc_handler+0xd4/0x198
> > [15030.027933] el0_svc+0x8/0xc
> > [15030.030814]
> > [15030.032306] Freed by task 3025:
> > [15030.035451] __kasan_slab_free+0x114/0x228
> > [15030.039548] kasan_slab_free+0x10/0x18
> > [15030.043299] kfree+0x114/0x408
> > [15030.046357] selinux_sk_free_security+0x38/0x48
> > [15030.050888] security_sk_free+0x3c/0x58
> > [15030.054727] __sk_destruct+0x3e8/0x570
> > [15030.058478] sk_destruct+0x4c/0x58
> > [15030.061881] __sk_free+0x68/0x138
> > [15030.065197] sk_free+0x3c/0x48
> > [15030.068255] unix_release_sock+0x4a8/0x550
> > [15030.072353] unix_release+0x34/0x50
> > [15030.075843] __sock_release+0x74/0x110
> > [15030.079593] sock_close+0x24/0x38
> > [15030.082913] __fput+0x1b8/0x368
> > [15030.086055] ____fput+0x20/0x30
> > [15030.089199] task_work_run+0x14c/0x1a8
> > [15030.092951] do_notify_resume+0x1e4/0x200
> > [15030.096961] work_pending+0x8/0x14
> > [15030.100363]
> > [15030.101856] The buggy address belongs to the object at ffff801ec53c5080
> > [15030.101856] which belongs to the cache kmalloc-128 of size 128
> > [15030.114376] The buggy address is located 0 bytes inside of
> > [15030.114376] 128-byte region [ffff801ec53c5080, ffff801ec53c5100)
> > [15030.125939] The buggy address belongs to the page:
> > [15030.130732] page:ffff7fe007b14f00 count:1 mapcount:0 mapping:ffff8016c0010480 index:0x0
> > [15030.138738] flags: 0x5fffff0000000200(slab)
> > [15030.142926] raw: 5fffff0000000200 ffff7fe007980608 ffff801ec000fd60 ffff8016c0010480
> > [15030.150671] raw: 0000000000000000 0000000000660066 00000001ffffffff 0000000000000000
> > [15030.158413] page dumped because: kasan: bad access detected
> > [15030.163984]
> > [15030.165476] Memory state around the buggy address:
> > [15030.170269] ffff801ec53c4f80: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
> > [15030.177491] ffff801ec53c5000: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
> > [15030.184714] >ffff801ec53c5080: 01 fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
> > [15030.191934] ^
> > [15030.195164] ffff801ec53c5100: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
> > [15030.202386] ffff801ec53c5180: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
> > [15030.209607] ==================================================================
> > [15030.216828] Disabling lock debugging due to kernel taint
>
> I think I found the cause - Qian, can you test this patch if it fixes
> the problem?
>
> security/selinux/hooks.c | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/security/selinux/hooks.c b/security/selinux/hooks.c
> index 7ce683259357..a67459eb62d5 100644
> --- a/security/selinux/hooks.c
> +++ b/security/selinux/hooks.c
> @@ -5318,6 +5318,9 @@ static int selinux_sctp_bind_connect(struct sock *sk, int optname,
> addr_buf = address;
>
> while (walk_size < addrlen) {
> + if (walk_size + sizeof(sa_family_t) > addrlen)
> + return -EINVAL;
> +
> addr = addr_buf;
> switch (addr->sa_family) {
> case AF_UNSPEC:

Good catch, I think you're right about this. I'll give Qian a bit to
see if he can verify this, but as of right now I'm going to plan on
merging this into selinux/stable-4.20.

--
paul moore
http://www.paul-moore.com

2018-11-13 19:22:37

by Qian Cai

[permalink] [raw]
Subject: Re: [PATCH] selinux: check length properly in SCTP bind hook

On Tue, 2018-11-13 at 16:16 +0100, Ondrej Mosnacek wrote:
> selinux_sctp_bind_connect() must verify if the address buffer has
> sufficient length before accessing the 'sa_family' field. See
> __sctp_connect() for a similar check.
>
> The length of the whole address ('len') is already checked in the
> callees.
>
> Reported-by: Qian Cai <[email protected]>
> Fixes: d452930fd3b9 ("selinux: Add SCTP support")
> Cc: <[email protected]> # 4.17+
> Cc: Richard Haines <[email protected]>
> Signed-off-by: Ondrej Mosnacek <[email protected]>
Tested-by: Qian Cai <[email protected]>
> ---
> Hi,
>
> On Mon, Nov 12, 2018 at 8:39 PM Qian Cai <[email protected]> wrote:
> > Running the trinity fuzzer on the latest mainline (rc2) generates this,
> >
> > [15029.879626] BUG: KASAN: slab-out-of-bounds in
> > selinux_sctp_bind_connect+0x60/0x150
> > [15029.887275] Read of size 2 at addr ffff801ec53c5080 by task trinity-
> > main/18081
> > [15029.887294] 
> > [15029.887304] CPU: 28 PID: 18081 Comm: trinity-main Tainted:
> > G        W  OE     4.20.0-rc2+ #15
> > [15029.887311] Hardware name: Huawei TaiShan 2280 /BC11SPCD, BIOS 1.50
> > 06/01/2018
> > [15000.084786] [15029.887320] Call trace:
> > [15029.915511]  dump_backtrace+0x0/0x2c8
> > [15029.920046]  show_stack+0x24/0x30
> > [15029.923367]  dump_stack+0x118/0x19c
> > [15029.927539]  print_address_description+0x68/0x2a0
> > [15029.932245]  kasan_report+0x1b4/0x348
> > [15029.938760]  __asan_load2+0x7c/0xa0
> > [15029.945098]  selinux_sctp_bind_connect+0x60/0x150
> >
> > [15029.950571]  security_sctp_bind_connect+0x58/0x90
> > [15029.955493]  __sctp_setsockopt_connectx+0x68/0x128 [sctp]
> > [15029.960943]  sctp_setsockopt+0x764/0x2928 [sctp]
> > [15029.965564]  sock_common_setsockopt+0x6c/0x80
> > [15029.969923]  __arm64_sys_setsockopt+0x13c/0x1f0
> > [15029.974456]  el0_svc_handler+0xd4/0x198
> > [15029.978293]  el0_svc+0x8/0xc
> > [15029.981174] 
> > [15029.982667] Allocated by task 18081:
> > [15029.986245]  kasan_kmalloc.part.1+0x40/0x108
> > [15029.990517]  kasan_kmalloc+0xb4/0xc8
> > [15029.994094]  __kmalloc_node+0x1c4/0x638
> > [15029.997933]  kvmalloc_node+0x98/0xa8
> > [15030.001511]  vmemdup_user+0x34/0x128
> > [15030.005137]  __sctp_setsockopt_connectx+0x44/0x128 [sctp]
> > [15030.010586]  sctp_setsockopt+0x764/0x2928 [sctp]
> > [15030.015205]  sock_common_setsockopt+0x6c/0x80
> > [15030.019564]  __arm64_sys_setsockopt+0x13c/0x1f0
> > [15030.024096]  el0_svc_handler+0xd4/0x198
> > [15030.027933]  el0_svc+0x8/0xc
> > [15030.030814] 
> > [15030.032306] Freed by task 3025:
> > [15030.035451]  __kasan_slab_free+0x114/0x228
> > [15030.039548]  kasan_slab_free+0x10/0x18
> > [15030.043299]  kfree+0x114/0x408
> > [15030.046357]  selinux_sk_free_security+0x38/0x48
> > [15030.050888]  security_sk_free+0x3c/0x58
> > [15030.054727]  __sk_destruct+0x3e8/0x570
> > [15030.058478]  sk_destruct+0x4c/0x58
> > [15030.061881]  __sk_free+0x68/0x138
> > [15030.065197]  sk_free+0x3c/0x48
> > [15030.068255]  unix_release_sock+0x4a8/0x550
> > [15030.072353]  unix_release+0x34/0x50
> > [15030.075843]  __sock_release+0x74/0x110
> > [15030.079593]  sock_close+0x24/0x38
> > [15030.082913]  __fput+0x1b8/0x368
> > [15030.086055]  ____fput+0x20/0x30
> > [15030.089199]  task_work_run+0x14c/0x1a8
> > [15030.092951]  do_notify_resume+0x1e4/0x200
> > [15030.096961]  work_pending+0x8/0x14
> > [15030.100363] 
> > [15030.101856] The buggy address belongs to the object at ffff801ec53c5080
> > [15030.101856]  which belongs to the cache kmalloc-128 of size 128
> > [15030.114376] The buggy address is located 0 bytes inside of
> > [15030.114376]  128-byte region [ffff801ec53c5080, ffff801ec53c5100)
> > [15030.125939] The buggy address belongs to the page:
> > [15030.130732] page:ffff7fe007b14f00 count:1 mapcount:0
> > mapping:ffff8016c0010480 index:0x0
> > [15030.138738] flags: 0x5fffff0000000200(slab)
> > [15030.142926] raw: 5fffff0000000200 ffff7fe007980608 ffff801ec000fd60
> > ffff8016c0010480
> > [15030.150671] raw: 0000000000000000 0000000000660066 00000001ffffffff
> > 0000000000000000
> > [15030.158413] page dumped because: kasan: bad access detected
> > [15030.163984] 
> > [15030.165476] Memory state around the buggy address:
> > [15030.170269]  ffff801ec53c4f80: fc fc fc fc fc fc fc fc fc fc fc fc fc fc
> > fc fc
> > [15030.177491]  ffff801ec53c5000: fc fc fc fc fc fc fc fc fc fc fc fc fc fc
> > fc fc
> > [15030.184714] >ffff801ec53c5080: 01 fc fc fc fc fc fc fc fc fc fc fc fc fc
> > fc fc
> > [15030.191934]                    ^
> > [15030.195164]  ffff801ec53c5100: fc fc fc fc fc fc fc fc fc fc fc fc fc fc
> > fc fc
> > [15030.202386]  ffff801ec53c5180: fc fc fc fc fc fc fc fc fc fc fc fc fc fc
> > fc fc
> > [15030.209607]
> > ==================================================================
> > [15030.216828] Disabling lock debugging due to kernel taint
>
> I think I found the cause - Qian, can you test this patch if it fixes
> the problem?
>
>  security/selinux/hooks.c | 3 +++
>  1 file changed, 3 insertions(+)
>
> diff --git a/security/selinux/hooks.c b/security/selinux/hooks.c
> index 7ce683259357..a67459eb62d5 100644
> --- a/security/selinux/hooks.c
> +++ b/security/selinux/hooks.c
> @@ -5318,6 +5318,9 @@ static int selinux_sctp_bind_connect(struct sock *sk,
> int optname,
>   addr_buf = address;
>  
>   while (walk_size < addrlen) {
> + if (walk_size + sizeof(sa_family_t) > addrlen)
> + return -EINVAL;
> +
>   addr = addr_buf;
>   switch (addr->sa_family) {
>   case AF_UNSPEC:

2018-11-13 20:15:48

by Paul Moore

[permalink] [raw]
Subject: Re: [PATCH] selinux: check length properly in SCTP bind hook

On Tue, Nov 13, 2018 at 2:20 PM Qian Cai <[email protected]> wrote:
> On Tue, 2018-11-13 at 16:16 +0100, Ondrej Mosnacek wrote:
> > selinux_sctp_bind_connect() must verify if the address buffer has
> > sufficient length before accessing the 'sa_family' field. See
> > __sctp_connect() for a similar check.
> >
> > The length of the whole address ('len') is already checked in the
> > callees.
> >
> > Reported-by: Qian Cai <[email protected]>
> > Fixes: d452930fd3b9 ("selinux: Add SCTP support")
> > Cc: <[email protected]> # 4.17+
> > Cc: Richard Haines <[email protected]>
> > Signed-off-by: Ondrej Mosnacek <[email protected]>
> Tested-by: Qian Cai <[email protected]>

Thanks guys. I'm in the process of building a test kernel right now,
assuming everything else passes (I can't see why this change would
cause a problem) I'll send this up to Linus.

> > ---
> > Hi,
> >
> > On Mon, Nov 12, 2018 at 8:39 PM Qian Cai <[email protected]> wrote:
> > > Running the trinity fuzzer on the latest mainline (rc2) generates this,
> > >
> > > [15029.879626] BUG: KASAN: slab-out-of-bounds in
> > > selinux_sctp_bind_connect+0x60/0x150
> > > [15029.887275] Read of size 2 at addr ffff801ec53c5080 by task trinity-
> > > main/18081
> > > [15029.887294]
> > > [15029.887304] CPU: 28 PID: 18081 Comm: trinity-main Tainted:
> > > G W OE 4.20.0-rc2+ #15
> > > [15029.887311] Hardware name: Huawei TaiShan 2280 /BC11SPCD, BIOS 1.50
> > > 06/01/2018
> > > [15000.084786] [15029.887320] Call trace:
> > > [15029.915511] dump_backtrace+0x0/0x2c8
> > > [15029.920046] show_stack+0x24/0x30
> > > [15029.923367] dump_stack+0x118/0x19c
> > > [15029.927539] print_address_description+0x68/0x2a0
> > > [15029.932245] kasan_report+0x1b4/0x348
> > > [15029.938760] __asan_load2+0x7c/0xa0
> > > [15029.945098] selinux_sctp_bind_connect+0x60/0x150
> > >
> > > [15029.950571] security_sctp_bind_connect+0x58/0x90
> > > [15029.955493] __sctp_setsockopt_connectx+0x68/0x128 [sctp]
> > > [15029.960943] sctp_setsockopt+0x764/0x2928 [sctp]
> > > [15029.965564] sock_common_setsockopt+0x6c/0x80
> > > [15029.969923] __arm64_sys_setsockopt+0x13c/0x1f0
> > > [15029.974456] el0_svc_handler+0xd4/0x198
> > > [15029.978293] el0_svc+0x8/0xc
> > > [15029.981174]
> > > [15029.982667] Allocated by task 18081:
> > > [15029.986245] kasan_kmalloc.part.1+0x40/0x108
> > > [15029.990517] kasan_kmalloc+0xb4/0xc8
> > > [15029.994094] __kmalloc_node+0x1c4/0x638
> > > [15029.997933] kvmalloc_node+0x98/0xa8
> > > [15030.001511] vmemdup_user+0x34/0x128
> > > [15030.005137] __sctp_setsockopt_connectx+0x44/0x128 [sctp]
> > > [15030.010586] sctp_setsockopt+0x764/0x2928 [sctp]
> > > [15030.015205] sock_common_setsockopt+0x6c/0x80
> > > [15030.019564] __arm64_sys_setsockopt+0x13c/0x1f0
> > > [15030.024096] el0_svc_handler+0xd4/0x198
> > > [15030.027933] el0_svc+0x8/0xc
> > > [15030.030814]
> > > [15030.032306] Freed by task 3025:
> > > [15030.035451] __kasan_slab_free+0x114/0x228
> > > [15030.039548] kasan_slab_free+0x10/0x18
> > > [15030.043299] kfree+0x114/0x408
> > > [15030.046357] selinux_sk_free_security+0x38/0x48
> > > [15030.050888] security_sk_free+0x3c/0x58
> > > [15030.054727] __sk_destruct+0x3e8/0x570
> > > [15030.058478] sk_destruct+0x4c/0x58
> > > [15030.061881] __sk_free+0x68/0x138
> > > [15030.065197] sk_free+0x3c/0x48
> > > [15030.068255] unix_release_sock+0x4a8/0x550
> > > [15030.072353] unix_release+0x34/0x50
> > > [15030.075843] __sock_release+0x74/0x110
> > > [15030.079593] sock_close+0x24/0x38
> > > [15030.082913] __fput+0x1b8/0x368
> > > [15030.086055] ____fput+0x20/0x30
> > > [15030.089199] task_work_run+0x14c/0x1a8
> > > [15030.092951] do_notify_resume+0x1e4/0x200
> > > [15030.096961] work_pending+0x8/0x14
> > > [15030.100363]
> > > [15030.101856] The buggy address belongs to the object at ffff801ec53c5080
> > > [15030.101856] which belongs to the cache kmalloc-128 of size 128
> > > [15030.114376] The buggy address is located 0 bytes inside of
> > > [15030.114376] 128-byte region [ffff801ec53c5080, ffff801ec53c5100)
> > > [15030.125939] The buggy address belongs to the page:
> > > [15030.130732] page:ffff7fe007b14f00 count:1 mapcount:0
> > > mapping:ffff8016c0010480 index:0x0
> > > [15030.138738] flags: 0x5fffff0000000200(slab)
> > > [15030.142926] raw: 5fffff0000000200 ffff7fe007980608 ffff801ec000fd60
> > > ffff8016c0010480
> > > [15030.150671] raw: 0000000000000000 0000000000660066 00000001ffffffff
> > > 0000000000000000
> > > [15030.158413] page dumped because: kasan: bad access detected
> > > [15030.163984]
> > > [15030.165476] Memory state around the buggy address:
> > > [15030.170269] ffff801ec53c4f80: fc fc fc fc fc fc fc fc fc fc fc fc fc fc
> > > fc fc
> > > [15030.177491] ffff801ec53c5000: fc fc fc fc fc fc fc fc fc fc fc fc fc fc
> > > fc fc
> > > [15030.184714] >ffff801ec53c5080: 01 fc fc fc fc fc fc fc fc fc fc fc fc fc
> > > fc fc
> > > [15030.191934] ^
> > > [15030.195164] ffff801ec53c5100: fc fc fc fc fc fc fc fc fc fc fc fc fc fc
> > > fc fc
> > > [15030.202386] ffff801ec53c5180: fc fc fc fc fc fc fc fc fc fc fc fc fc fc
> > > fc fc
> > > [15030.209607]
> > > ==================================================================
> > > [15030.216828] Disabling lock debugging due to kernel taint
> >
> > I think I found the cause - Qian, can you test this patch if it fixes
> > the problem?
> >
> > security/selinux/hooks.c | 3 +++
> > 1 file changed, 3 insertions(+)
> >
> > diff --git a/security/selinux/hooks.c b/security/selinux/hooks.c
> > index 7ce683259357..a67459eb62d5 100644
> > --- a/security/selinux/hooks.c
> > +++ b/security/selinux/hooks.c
> > @@ -5318,6 +5318,9 @@ static int selinux_sctp_bind_connect(struct sock *sk,
> > int optname,
> > addr_buf = address;
> >
> > while (walk_size < addrlen) {
> > + if (walk_size + sizeof(sa_family_t) > addrlen)
> > + return -EINVAL;
> > +
> > addr = addr_buf;
> > switch (addr->sa_family) {
> > case AF_UNSPEC:



--
paul moore
http://www.paul-moore.com