On Wed, Feb 1, 2017 at 5:50 PM, David Howells wrote:
> Do you reboot the system between running individual programs? If not, the
> programs will be influencing each other. Further, only those calls with valid
> type and matching description values are relevant, I think. This means those
> that
Do you reboot the system between running individual programs? If not, the
programs will be influencing each other. Further, only those calls with valid
type and matching description values are relevant, I think. This means those
that use:
static const char type_2[] = "user";
sta
On Wed, Feb 1, 2017 at 4:42 PM, David Howells wrote:
> Dmitry Vyukov wrote:
>
>> >> I actually know what were the arguments to the syscall.
>
> The program resolves to the attached C file. I can't see how you can tell
> which of the six request_key() calls triggered.
These are 3 separate progra
Dmitry Vyukov wrote:
> >> I actually know what were the arguments to the syscall.
The program resolves to the attached C file. I can't see how you can tell
which of the six request_key() calls triggered.
Also, what OS are running this on? If you have PAM set up properly, none of
the request_k
On Wed, Feb 1, 2017 at 3:54 PM, David Howells wrote:
> Dmitry Vyukov wrote:
>
>> > Can you disassemble this function for me? There are several possible paths
>> > and without the argument to the syscall and whether there's a key that was
>> > matched, it's hard to say which path is being taken -
Dmitry Vyukov wrote:
> > Can you disassemble this function for me? There are several possible paths
> > and without the argument to the syscall and whether there's a key that was
> > matched, it's hard to say which path is being taken - but this might help
> > determine that.
>
> Here it is:
>
On Wed, Feb 1, 2017 at 2:48 PM, David Howells wrote:
> Dmitry Vyukov wrote:
>
>> request_key_and_link+0x2d8/0x1150 security/keys/request_key.c:549
>
> Can you disassemble this function for me? There are several possible paths
> and without the argument to the syscall and whether there's a key t
Dmitry Vyukov wrote:
> request_key_and_link+0x2d8/0x1150 security/keys/request_key.c:549
Can you disassemble this function for me? There are several possible paths
and without the argument to the syscall and whether there's a key that was
matched, it's hard to say which path is being taken - b
On Wed, Feb 1, 2017 at 2:11 PM, David Howells wrote:
> Dmitry Vyukov wrote:
>
>> Code: 41 54 49 89 f4 53 49 89 d7 48 89 fb 48 83 ec 08 e8 d1 50 67 ff
>> 49 8d 7c 24 10 48 b8 00 00 00 00 00 fc ff df 48 89 fa 48 c1 ea 03 <80>
>> 3c 02 00 0f 85 35 02 00 00 49 83 7c 24 10 00 0f 84 bb 01 00
>
> This d
Dmitry Vyukov wrote:
> The line causes the crash is:
> BUG_ON(index_key->desc_len == 0);
>
> The addresses that the line tried to access are:
>
> RDI: ca29fa68
> RDI: d7236a28
> RDI: 7d19ed68
These are all calculated from R12:
lea0x10(%r12),%rdi
Dmitry Vyukov wrote:
> Code: 41 54 49 89 f4 53 49 89 d7 48 89 fb 48 83 ec 08 e8 d1 50 67 ff
> 49 8d 7c 24 10 48 b8 00 00 00 00 00 fc ff df 48 89 fa 48 c1 ea 03 <80>
> 3c 02 00 0f 85 35 02 00 00 49 83 7c 24 10 00 0f 84 bb 01 00
This disassembles to:
0: 41 54 push %r12
Hello,
I am seeing the following crashes in request_key while running
syzkaller fuzzer. This is observed on upstream commits
566cf877a1fcb6d6dc0126b076aad062054c2637,
f9a42e0d58cf0fe3d902e63d4582f2ea4cd2bb8b and
a2ca3d617944417e9dd5f09fc8a4549cda115f4f. Unfortunately this is not
reproducible (prob
12 matches
Mail list logo
