Bisection is inconclusive: the first bad commit could be any of:
2c43838c sched/isolation: Enable CONFIG_CPU_ISOLATION=y by default
bf29cb23 sched/isolation: Make CONFIG_NO_HZ_FULL select CONFIG_CPU_ISOLATION
d94d1053 sched/isolation: Document boot parameters dependency on
On 2019/3/17 3:42, Andrea Arcangeli wrote:
> On Sat, Mar 16, 2019 at 05:38:54PM +0800, zhong jiang wrote:
>> On 2019/3/16 5:39, Andrea Arcangeli wrote:
>>> On Fri, Mar 08, 2019 at 03:10:08PM +0800, zhong jiang wrote:
I can reproduce the issue in arm64 qemu machine. The issue will leave
On Sat, Mar 16, 2019 at 05:38:54PM +0800, zhong jiang wrote:
> On 2019/3/16 5:39, Andrea Arcangeli wrote:
> > On Fri, Mar 08, 2019 at 03:10:08PM +0800, zhong jiang wrote:
> >> I can reproduce the issue in arm64 qemu machine. The issue will leave
> >> after applying the
> >> patch.
> >>
> >>
On 2019/3/16 5:39, Andrea Arcangeli wrote:
> On Fri, Mar 08, 2019 at 03:10:08PM +0800, zhong jiang wrote:
>> I can reproduce the issue in arm64 qemu machine. The issue will leave after
>> applying the
>> patch.
>>
>> Tested-by: zhong jiang
> Thanks a lot for the quick testing!
>
>> Meanwhile,
On Fri, Mar 08, 2019 at 03:10:08PM +0800, zhong jiang wrote:
> I can reproduce the issue in arm64 qemu machine. The issue will leave after
> applying the
> patch.
>
> Tested-by: zhong jiang
Thanks a lot for the quick testing!
> Meanwhile, I just has a little doubt whether it is necessary to
On 2019/3/6 10:05, Andrea Arcangeli wrote:
> Hello everyone,
>
> [ CC'ed Mike and Peter ]
>
> On Tue, Mar 05, 2019 at 02:42:00PM +0800, zhong jiang wrote:
>> On 2019/3/5 14:26, Dmitry Vyukov wrote:
>>> On Mon, Mar 4, 2019 at 4:32 PM zhong jiang wrote:
On 2019/3/4 22:11, Dmitry Vyukov wrote:
On 2019/3/7 2:29, Andrea Arcangeli wrote:
> Hello Zhong,
>
> On Wed, Mar 06, 2019 at 09:07:00PM +0800, zhong jiang wrote:
>> The patch use call_rcu to delay free the task_struct, but It is possible to
>> free the task_struct
>> ahead of get_mem_cgroup_from_mm. is it right?
> Yes it is possible to
Hello Zhong,
On Wed, Mar 06, 2019 at 09:07:00PM +0800, zhong jiang wrote:
> The patch use call_rcu to delay free the task_struct, but It is possible to
> free the task_struct
> ahead of get_mem_cgroup_from_mm. is it right?
Yes it is possible to free before get_mem_cgroup_from_mm, but if it's
On 2019/3/6 16:12, Peter Xu wrote:
> On Wed, Mar 06, 2019 at 03:41:06PM +0800, zhong jiang wrote:
>> On 2019/3/6 14:26, Mike Rapoport wrote:
>>> Hi,
>>>
>>> On Wed, Mar 06, 2019 at 01:53:12PM +0800, zhong jiang wrote:
On 2019/3/6 10:05, Andrea Arcangeli wrote:
> Hello everyone,
>
On Wed, Mar 06, 2019 at 03:41:06PM +0800, zhong jiang wrote:
> On 2019/3/6 14:26, Mike Rapoport wrote:
> > Hi,
> >
> > On Wed, Mar 06, 2019 at 01:53:12PM +0800, zhong jiang wrote:
> >> On 2019/3/6 10:05, Andrea Arcangeli wrote:
> >>> Hello everyone,
> >>>
> >>> [ CC'ed Mike and Peter ]
> >>>
> >>>
On Wed, Mar 06, 2019 at 03:41:06PM +0800, zhong jiang wrote:
> On 2019/3/6 14:26, Mike Rapoport wrote:
> > Hi,
> >
> > On Wed, Mar 06, 2019 at 01:53:12PM +0800, zhong jiang wrote:
> >> On 2019/3/6 10:05, Andrea Arcangeli wrote:
> >>> Hello everyone,
> >>>
> >>> [ CC'ed Mike and Peter ]
> >>>
> >>>
On 2019/3/6 14:26, Mike Rapoport wrote:
> Hi,
>
> On Wed, Mar 06, 2019 at 01:53:12PM +0800, zhong jiang wrote:
>> On 2019/3/6 10:05, Andrea Arcangeli wrote:
>>> Hello everyone,
>>>
>>> [ CC'ed Mike and Peter ]
>>>
>>> On Tue, Mar 05, 2019 at 02:42:00PM +0800, zhong jiang wrote:
On 2019/3/5
Hi,
On Wed, Mar 06, 2019 at 01:53:12PM +0800, zhong jiang wrote:
> On 2019/3/6 10:05, Andrea Arcangeli wrote:
> > Hello everyone,
> >
> > [ CC'ed Mike and Peter ]
> >
> > On Tue, Mar 05, 2019 at 02:42:00PM +0800, zhong jiang wrote:
> >> On 2019/3/5 14:26, Dmitry Vyukov wrote:
> >>> On Mon, Mar 4,
On 2019/3/6 10:05, Andrea Arcangeli wrote:
> Hello everyone,
>
> [ CC'ed Mike and Peter ]
>
> On Tue, Mar 05, 2019 at 02:42:00PM +0800, zhong jiang wrote:
>> On 2019/3/5 14:26, Dmitry Vyukov wrote:
>>> On Mon, Mar 4, 2019 at 4:32 PM zhong jiang wrote:
On 2019/3/4 22:11, Dmitry Vyukov wrote:
Hello everyone,
[ CC'ed Mike and Peter ]
On Tue, Mar 05, 2019 at 02:42:00PM +0800, zhong jiang wrote:
> On 2019/3/5 14:26, Dmitry Vyukov wrote:
> > On Mon, Mar 4, 2019 at 4:32 PM zhong jiang wrote:
> >> On 2019/3/4 22:11, Dmitry Vyukov wrote:
> >>> On Mon, Mar 4, 2019 at 3:00 PM zhong jiang
On 2019/3/5 14:26, Dmitry Vyukov wrote:
> On Mon, Mar 4, 2019 at 4:32 PM zhong jiang wrote:
>> On 2019/3/4 22:11, Dmitry Vyukov wrote:
>>> On Mon, Mar 4, 2019 at 3:00 PM zhong jiang wrote:
On 2019/3/4 15:40, Dmitry Vyukov wrote:
> On Sun, Mar 3, 2019 at 5:19 PM zhong jiang wrote:
On Mon, Mar 4, 2019 at 4:32 PM zhong jiang wrote:
>
> On 2019/3/4 22:11, Dmitry Vyukov wrote:
> > On Mon, Mar 4, 2019 at 3:00 PM zhong jiang wrote:
> >> On 2019/3/4 15:40, Dmitry Vyukov wrote:
> >>> On Sun, Mar 3, 2019 at 5:19 PM zhong jiang wrote:
> Hi, guys
>
> I also hit the
On 2019/3/5 5:51, Matthew Wilcox wrote:
> On Mon, Mar 04, 2019 at 12:19:32AM +0800, zhong jiang wrote:
>> I also hit the following issue. but it fails to reproduce the issue by the
>> log.
>>
>> it seems to the case that we access the mm->owner and deference it will
>> result in the UAF.
>> But
On Mon, Mar 04, 2019 at 12:19:32AM +0800, zhong jiang wrote:
> I also hit the following issue. but it fails to reproduce the issue by the
> log.
>
> it seems to the case that we access the mm->owner and deference it will
> result in the UAF.
> But it should not be possible that we specify the
On 2019/3/4 22:11, Dmitry Vyukov wrote:
> On Mon, Mar 4, 2019 at 3:00 PM zhong jiang wrote:
>> On 2019/3/4 15:40, Dmitry Vyukov wrote:
>>> On Sun, Mar 3, 2019 at 5:19 PM zhong jiang wrote:
Hi, guys
I also hit the following issue. but it fails to reproduce the issue by the
On Mon, Mar 4, 2019 at 3:00 PM zhong jiang wrote:
>
> On 2019/3/4 15:40, Dmitry Vyukov wrote:
> > On Sun, Mar 3, 2019 at 5:19 PM zhong jiang wrote:
> >> Hi, guys
> >>
> >> I also hit the following issue. but it fails to reproduce the issue by the
> >> log.
> >>
> >> it seems to the case that we
On 2019/3/4 15:40, Dmitry Vyukov wrote:
> On Sun, Mar 3, 2019 at 5:19 PM zhong jiang wrote:
>> Hi, guys
>>
>> I also hit the following issue. but it fails to reproduce the issue by the
>> log.
>>
>> it seems to the case that we access the mm->owner and deference it will
>> result in the UAF.
>>
On Sun, Mar 3, 2019 at 5:19 PM zhong jiang wrote:
>
> Hi, guys
>
> I also hit the following issue. but it fails to reproduce the issue by the
> log.
>
> it seems to the case that we access the mm->owner and deference it will
> result in the UAF.
> But it should not be possible that we specify
Hi, guys
I also hit the following issue. but it fails to reproduce the issue by the log.
it seems to the case that we access the mm->owner and deference it will result
in the UAF.
But it should not be possible that we specify the incomplete process to be the
mm->owner.
Any thoughts?
Thanks,
syzbot has found a reproducer for the following crash on:
HEAD commit:0072a0c14d5b Merge tag 'media/v4.20-4' of git://git.kernel..
git tree: upstream
console output: https://syzkaller.appspot.com/x/log.txt?x=11c885a340
kernel config:
syzbot has found a reproducer for the following crash on:
HEAD commit:0072a0c14d5b Merge tag 'media/v4.20-4' of git://git.kernel..
git tree: upstream
console output: https://syzkaller.appspot.com/x/log.txt?x=11c885a340
kernel config:
Hello,
syzbot found the following crash on:
HEAD commit:83650fd58a93 Merge tag 'arm64-upstream' of git://git.kerne..
git tree: upstream
console output: https://syzkaller.appspot.com/x/log.txt?x=12ce682b40
kernel config: https://syzkaller.appspot.com/x/.config?x=9384ecb1c973baed
Hello,
syzbot found the following crash on:
HEAD commit:83650fd58a93 Merge tag 'arm64-upstream' of git://git.kerne..
git tree: upstream
console output: https://syzkaller.appspot.com/x/log.txt?x=12ce682b40
kernel config: https://syzkaller.appspot.com/x/.config?x=9384ecb1c973baed
28 matches
Mail list logo
