* BUG: KASAN: slab-out-of-bounds in selinux_sctp_bind_connect+0x60/0x150
@ 2018-11-12 19:38 Qian Cai
2018-11-13 0:41 ` Paul Moore
2018-11-13 15:16 ` [PATCH] selinux: check length properly in SCTP bind hook Ondrej Mosnacek
0 siblings, 2 replies; 12+ messages in thread
From: Qian Cai @ 2018-11-12 19:38 UTC (permalink / raw)
To: linux kernel; +Cc: selinux, Paul Moore, Stephen Smalley, Eric Paris
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
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: BUG: KASAN: slab-out-of-bounds in selinux_sctp_bind_connect+0x60/0x150
2018-11-12 19:38 BUG: KASAN: slab-out-of-bounds in selinux_sctp_bind_connect+0x60/0x150 Qian Cai
@ 2018-11-13 0:41 ` Paul Moore
2018-11-13 0:58 ` Qian Cai
2018-11-13 15:16 ` [PATCH] selinux: check length properly in SCTP bind hook Ondrej Mosnacek
1 sibling, 1 reply; 12+ messages in thread
From: Paul Moore @ 2018-11-13 0:41 UTC (permalink / raw)
To: cai; +Cc: linux-kernel, selinux, Stephen Smalley, Eric Paris
On Mon, Nov 12, 2018 at 2:39 PM Qian Cai <cai@gmx.us> 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
www.paul-moore.com
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: BUG: KASAN: slab-out-of-bounds in selinux_sctp_bind_connect+0x60/0x150
2018-11-13 0:41 ` Paul Moore
@ 2018-11-13 0:58 ` Qian Cai
2018-11-13 3:09 ` Paul Moore
0 siblings, 1 reply; 12+ messages in thread
From: Qian Cai @ 2018-11-13 0:58 UTC (permalink / raw)
To: Paul Moore; +Cc: linux kernel, selinux, Stephen Smalley, Eric Paris
> On Nov 12, 2018, at 7:41 PM, Paul Moore <paul@paul-moore.com> wrote:
>
> On Mon, Nov 12, 2018 at 2:39 PM Qian Cai <cai@gmx.us> 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.
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: BUG: KASAN: slab-out-of-bounds in selinux_sctp_bind_connect+0x60/0x150
2018-11-13 0:58 ` Qian Cai
@ 2018-11-13 3:09 ` Paul Moore
2018-11-13 3:11 ` Qian Cai
0 siblings, 1 reply; 12+ messages in thread
From: Paul Moore @ 2018-11-13 3:09 UTC (permalink / raw)
To: cai; +Cc: linux-kernel, selinux, Stephen Smalley, Eric Paris
On Mon, Nov 12, 2018 at 7:59 PM Qian Cai <cai@gmx.us> wrote:
> > On Nov 12, 2018, at 7:41 PM, Paul Moore <paul@paul-moore.com> wrote:
> > On Mon, Nov 12, 2018 at 2:39 PM Qian Cai <cai@gmx.us> 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
www.paul-moore.com
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: BUG: KASAN: slab-out-of-bounds in selinux_sctp_bind_connect+0x60/0x150
2018-11-13 3:09 ` Paul Moore
@ 2018-11-13 3:11 ` Qian Cai
2018-11-13 13:33 ` Paul Moore
0 siblings, 1 reply; 12+ messages in thread
From: Qian Cai @ 2018-11-13 3:11 UTC (permalink / raw)
To: Paul Moore; +Cc: linux kernel, selinux, Stephen Smalley, Eric Paris
> On Nov 12, 2018, at 10:09 PM, Paul Moore <paul@paul-moore.com> wrote:
>
> On Mon, Nov 12, 2018 at 7:59 PM Qian Cai <cai@gmx.us> wrote:
>>> On Nov 12, 2018, at 7:41 PM, Paul Moore <paul@paul-moore.com> wrote:
>>> On Mon, Nov 12, 2018 at 2:39 PM Qian Cai <cai@gmx.us> 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
> www.paul-moore.com
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: BUG: KASAN: slab-out-of-bounds in selinux_sctp_bind_connect+0x60/0x150
2018-11-13 3:11 ` Qian Cai
@ 2018-11-13 13:33 ` Paul Moore
2018-11-13 13:52 ` Qian Cai
0 siblings, 1 reply; 12+ messages in thread
From: Paul Moore @ 2018-11-13 13:33 UTC (permalink / raw)
To: cai; +Cc: linux-kernel, selinux, Stephen Smalley, Eric Paris
On Mon, Nov 12, 2018 at 10:11 PM Qian Cai <cai@gmx.us> wrote:
> > On Nov 12, 2018, at 10:09 PM, Paul Moore <paul@paul-moore.com> wrote:
> >
> > On Mon, Nov 12, 2018 at 7:59 PM Qian Cai <cai@gmx.us> wrote:
> >>> On Nov 12, 2018, at 7:41 PM, Paul Moore <paul@paul-moore.com> wrote:
> >>> On Mon, Nov 12, 2018 at 2:39 PM Qian Cai <cai@gmx.us> 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
www.paul-moore.com
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: BUG: KASAN: slab-out-of-bounds in selinux_sctp_bind_connect+0x60/0x150
2018-11-13 13:33 ` Paul Moore
@ 2018-11-13 13:52 ` Qian Cai
2018-11-13 14:29 ` Paul Moore
0 siblings, 1 reply; 12+ messages in thread
From: Qian Cai @ 2018-11-13 13:52 UTC (permalink / raw)
To: Paul Moore; +Cc: Eric Paris, linux-kernel, selinux, Stephen Smalley
On 11/13/18 at 8:33 AM, Paul Moore wrote:
> On Mon, Nov 12, 2018 at 10:11 PM Qian Cai <cai@gmx.us> wrote:
> > > On Nov 12, 2018, at 10:09 PM, Paul Moore <paul@paul-moore.com> wrote:
> > >
> > > On Mon, Nov 12, 2018 at 7:59 PM Qian Cai <cai@gmx.us> wrote:
> > >>> On Nov 12, 2018, at 7:41 PM, Paul Moore <paul@paul-moore.com> wrote:
> > >>> On Mon, Nov 12, 2018 at 2:39 PM Qian Cai <cai@gmx.us> 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
> www.paul-moore.com
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: BUG: KASAN: slab-out-of-bounds in selinux_sctp_bind_connect+0x60/0x150
2018-11-13 13:52 ` Qian Cai
@ 2018-11-13 14:29 ` Paul Moore
0 siblings, 0 replies; 12+ messages in thread
From: Paul Moore @ 2018-11-13 14:29 UTC (permalink / raw)
To: cai; +Cc: Eric Paris, linux-kernel, selinux, Stephen Smalley
On Tue, Nov 13, 2018 at 8:52 AM Qian Cai <cai@gmx.us> wrote:
> On 11/13/18 at 8:33 AM, Paul Moore wrote:
> > On Mon, Nov 12, 2018 at 10:11 PM Qian Cai <cai@gmx.us> wrote:
> > > > On Nov 12, 2018, at 10:09 PM, Paul Moore <paul@paul-moore.com> wrote:
> > > >
> > > > On Mon, Nov 12, 2018 at 7:59 PM Qian Cai <cai@gmx.us> wrote:
> > > >>> On Nov 12, 2018, at 7:41 PM, Paul Moore <paul@paul-moore.com> wrote:
> > > >>> On Mon, Nov 12, 2018 at 2:39 PM Qian Cai <cai@gmx.us> 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
www.paul-moore.com
^ permalink raw reply [flat|nested] 12+ messages in thread
* [PATCH] selinux: check length properly in SCTP bind hook
2018-11-12 19:38 BUG: KASAN: slab-out-of-bounds in selinux_sctp_bind_connect+0x60/0x150 Qian Cai
2018-11-13 0:41 ` Paul Moore
@ 2018-11-13 15:16 ` Ondrej Mosnacek
2018-11-13 15:51 ` Paul Moore
2018-11-13 19:20 ` Qian Cai
1 sibling, 2 replies; 12+ messages in thread
From: Ondrej Mosnacek @ 2018-11-13 15:16 UTC (permalink / raw)
To: selinux, Paul Moore
Cc: Qian Cai, Stephen Smalley, Eric Paris, linux-kernel,
Ondrej Mosnacek, stable, Richard Haines
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 <cai@gmx.us>
Fixes: d452930fd3b9 ("selinux: Add SCTP support")
Cc: <stable@vger.kernel.org> # 4.17+
Cc: Richard Haines <richard_c_haines@btinternet.com>
Signed-off-by: Ondrej Mosnacek <omosnace@redhat.com>
---
Hi,
On Mon, Nov 12, 2018 at 8:39 PM Qian Cai <cai@gmx.us> 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
^ permalink raw reply related [flat|nested] 12+ messages in thread
* Re: [PATCH] selinux: check length properly in SCTP bind hook
2018-11-13 15:16 ` [PATCH] selinux: check length properly in SCTP bind hook Ondrej Mosnacek
@ 2018-11-13 15:51 ` Paul Moore
2018-11-13 19:20 ` Qian Cai
1 sibling, 0 replies; 12+ messages in thread
From: Paul Moore @ 2018-11-13 15:51 UTC (permalink / raw)
To: omosnace
Cc: selinux, cai, Stephen Smalley, Eric Paris, linux-kernel, stable,
richard_c_haines
On Tue, Nov 13, 2018 at 10:18 AM Ondrej Mosnacek <omosnace@redhat.com> 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 <cai@gmx.us>
> Fixes: d452930fd3b9 ("selinux: Add SCTP support")
> Cc: <stable@vger.kernel.org> # 4.17+
> Cc: Richard Haines <richard_c_haines@btinternet.com>
> Signed-off-by: Ondrej Mosnacek <omosnace@redhat.com>
> ---
> Hi,
>
> On Mon, Nov 12, 2018 at 8:39 PM Qian Cai <cai@gmx.us> 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
www.paul-moore.com
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [PATCH] selinux: check length properly in SCTP bind hook
2018-11-13 15:16 ` [PATCH] selinux: check length properly in SCTP bind hook Ondrej Mosnacek
2018-11-13 15:51 ` Paul Moore
@ 2018-11-13 19:20 ` Qian Cai
2018-11-13 20:13 ` Paul Moore
1 sibling, 1 reply; 12+ messages in thread
From: Qian Cai @ 2018-11-13 19:20 UTC (permalink / raw)
To: Ondrej Mosnacek, selinux, Paul Moore
Cc: Stephen Smalley, Eric Paris, linux-kernel, stable, Richard Haines
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 <cai@gmx.us>
> Fixes: d452930fd3b9 ("selinux: Add SCTP support")
> Cc: <stable@vger.kernel.org> # 4.17+
> Cc: Richard Haines <richard_c_haines@btinternet.com>
> Signed-off-by: Ondrej Mosnacek <omosnace@redhat.com>
Tested-by: Qian Cai <cai@gmx.us>
> ---
> Hi,
>
> On Mon, Nov 12, 2018 at 8:39 PM Qian Cai <cai@gmx.us> 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:
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [PATCH] selinux: check length properly in SCTP bind hook
2018-11-13 19:20 ` Qian Cai
@ 2018-11-13 20:13 ` Paul Moore
0 siblings, 0 replies; 12+ messages in thread
From: Paul Moore @ 2018-11-13 20:13 UTC (permalink / raw)
To: cai
Cc: omosnace, selinux, Stephen Smalley, Eric Paris, linux-kernel,
stable, richard_c_haines
On Tue, Nov 13, 2018 at 2:20 PM Qian Cai <cai@gmx.us> 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 <cai@gmx.us>
> > Fixes: d452930fd3b9 ("selinux: Add SCTP support")
> > Cc: <stable@vger.kernel.org> # 4.17+
> > Cc: Richard Haines <richard_c_haines@btinternet.com>
> > Signed-off-by: Ondrej Mosnacek <omosnace@redhat.com>
> Tested-by: Qian Cai <cai@gmx.us>
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 <cai@gmx.us> 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
www.paul-moore.com
^ permalink raw reply [flat|nested] 12+ messages in thread
end of thread, other threads:[~2018-11-13 20:13 UTC | newest]
Thread overview: 12+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2018-11-12 19:38 BUG: KASAN: slab-out-of-bounds in selinux_sctp_bind_connect+0x60/0x150 Qian Cai
2018-11-13 0:41 ` Paul Moore
2018-11-13 0:58 ` Qian Cai
2018-11-13 3:09 ` Paul Moore
2018-11-13 3:11 ` Qian Cai
2018-11-13 13:33 ` Paul Moore
2018-11-13 13:52 ` Qian Cai
2018-11-13 14:29 ` Paul Moore
2018-11-13 15:16 ` [PATCH] selinux: check length properly in SCTP bind hook Ondrej Mosnacek
2018-11-13 15:51 ` Paul Moore
2018-11-13 19:20 ` Qian Cai
2018-11-13 20:13 ` Paul Moore
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).