dri-devel Archive on lore.kernel.org
 help / color / Atom feed
From: bugzilla-daemon@bugzilla.kernel.org
To: dri-devel@lists.freedesktop.org
Subject: [Bug 207383] [Regression] 5.7 amdgpu/polaris11 gpf: amdgpu_atomic_commit_tail
Date: Tue, 21 Jul 2020 21:16:03 +0000
Message-ID: <bug-207383-2300-znmrvEwL7a@https.bugzilla.kernel.org/> (raw)
In-Reply-To: <bug-207383-2300@https.bugzilla.kernel.org/>

https://bugzilla.kernel.org/show_bug.cgi?id=207383

--- Comment #79 from mnrzk@protonmail.com ---
(In reply to Kees Cook from comment #78)
> (In reply to mnrzk from comment #76)
> > If my understanding is correct, base would have previously been filled with
> > the freelist pointer (since it's the first 8 bytes). Now since the freelist
> > pointer is being put in the middle (rounded to the nearest sizeof(void*),
> >  or 8 bytes), it's being put in the last 8 bytes of *dm_state
> > (or dm_state->context).
> > 
> > I'll place a void* for padding in the middle of struct dm_atomic_state* and
> > if my hypothesis is correct, the padding will be filled with garbage data
> > instead of context and the bug should be fixed. Of course, there would
> > still be a use-after-free bug in the code which may cause other issues in
> > the future so I wouldn't really consider it a solution.
> 
> Agreed: that should make it disappear again, but as you say, it's just
> kicking the problem down the road since now the failing condition is losing
> a race with kfree()+kmalloc()+new contents.
> 
> And if you want to detect without crashing, you can just zero the padding at
> init time and report when it's non-NULL at workqueue run time... I wonder if
> KASAN can run in a mode where the allocation/freeing tracking happens, but
> without the heavy checking instrumentation? Then when the corruption is
> detected, it could dump a traceback about who did the early kfree()... hmmm.

So far I've been testing it by passing my GPU to my VM via vfio-pci and
attaching kgdb to the guest. To test if the context was invalid, I added
a check to make sure the context pointer wasn't garbage data (by checking
if dc_state was not null and the upper 16 bits were set on dc_state).

I wonder if there's any way to set a watchpoint to see where exactly the
dm_atomic_state gets filled with garbage data.

Also, since I'm not too familiar with freelists, do freelist pointers look
like regular pointers? On a regular pointer on a system with a 48-bit
virtual address space, regular pointers would be something like
0xffffXXXXXXXXXXXX. I've noticed that the data being inserted never
followed this format. Is this something valuable to note or is that just
the nature of freelist pointers?

-- 
You are receiving this mail because:
You are watching the assignee of the bug.
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

  parent reply index

Thread overview: 121+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-04-21  9:51 [Bug 207383] New: [Regression] 5.7-rc: " bugzilla-daemon
2020-04-21  9:57 ` [Bug 207383] " bugzilla-daemon
2020-04-21 10:04 ` bugzilla-daemon
2020-04-23  4:59 ` bugzilla-daemon
2020-04-27 19:24 ` bugzilla-daemon
2020-04-27 19:42 ` bugzilla-daemon
2020-04-27 19:43 ` bugzilla-daemon
2020-05-01  8:20 ` bugzilla-daemon
2020-05-01  8:28 ` bugzilla-daemon
2020-05-02 16:03 ` bugzilla-daemon
2020-05-03 15:10 ` bugzilla-daemon
2020-05-05  4:23 ` bugzilla-daemon
2020-05-06 17:46 ` bugzilla-daemon
2020-05-06 22:06 ` bugzilla-daemon
2020-06-03  0:04 ` [Bug 207383] [Regression] 5.7 " bugzilla-daemon
2020-06-21  7:01 ` bugzilla-daemon
2020-06-22 15:20 ` bugzilla-daemon
2020-06-22 17:44 ` bugzilla-daemon
2020-06-22 17:57 ` bugzilla-daemon
2020-06-22 19:36 ` bugzilla-daemon
2020-06-22 20:00 ` bugzilla-daemon
2020-06-23 15:36 ` bugzilla-daemon
2020-06-23 23:41 ` bugzilla-daemon
2020-06-24  8:55 ` bugzilla-daemon
2020-06-27  4:37 ` bugzilla-daemon
2020-06-27  4:38 ` bugzilla-daemon
2020-06-27  5:16 ` bugzilla-daemon
2020-06-27  6:08 ` bugzilla-daemon
2020-06-27  7:07 ` bugzilla-daemon
2020-06-27 22:26 ` bugzilla-daemon
2020-06-28  1:12 ` bugzilla-daemon
2020-06-28 10:48 ` bugzilla-daemon
2020-06-28 15:30 ` bugzilla-daemon
2020-06-29  7:39 ` bugzilla-daemon
2020-06-29 22:09 ` bugzilla-daemon
2020-07-01 19:08 ` bugzilla-daemon
2020-07-04 19:57 ` bugzilla-daemon
2020-07-04 20:13 ` bugzilla-daemon
2020-07-05 16:58 ` bugzilla-daemon
2020-07-05 22:08 ` bugzilla-daemon
2020-07-06 16:24 ` bugzilla-daemon
2020-07-06 23:57 ` bugzilla-daemon
2020-07-07  0:37 ` bugzilla-daemon
2020-07-07  3:01 ` bugzilla-daemon
2020-07-07 11:01 ` bugzilla-daemon
2020-07-07 12:43 ` bugzilla-daemon
2020-07-07 15:27 ` bugzilla-daemon
2020-07-07 19:05 ` bugzilla-daemon
2020-07-08  0:25 ` bugzilla-daemon
2020-07-08  1:25 ` bugzilla-daemon
2020-07-08 20:16 ` bugzilla-daemon
2020-07-08 20:17 ` bugzilla-daemon
2020-07-09  7:45 ` bugzilla-daemon
2020-07-10  7:23 ` bugzilla-daemon
2020-07-10  7:36 ` bugzilla-daemon
2020-07-10  8:10 ` bugzilla-daemon
2020-07-10 10:55 ` bugzilla-daemon
2020-07-10 11:25 ` bugzilla-daemon
2020-07-10 14:31 ` bugzilla-daemon
2020-07-12  5:20 ` bugzilla-daemon
2020-07-12  5:47 ` bugzilla-daemon
2020-07-12  7:47 ` bugzilla-daemon
2020-07-14 23:36 ` bugzilla-daemon
2020-07-15 16:49 ` bugzilla-daemon
2020-07-15 17:12 ` bugzilla-daemon
2020-07-16  2:12 ` bugzilla-daemon
2020-07-16  6:37 ` bugzilla-daemon
2020-07-16  9:35 ` bugzilla-daemon
2020-07-16 10:24 ` bugzilla-daemon
2020-07-16 10:30 ` bugzilla-daemon
2020-07-16 10:32 ` bugzilla-daemon
2020-07-17 12:39 ` bugzilla-daemon
2020-07-20  2:20 ` bugzilla-daemon
2020-07-21 16:40 ` bugzilla-daemon
2020-07-21 16:57 ` bugzilla-daemon
2020-07-21 19:32 ` bugzilla-daemon
2020-07-21 20:33 ` bugzilla-daemon
2020-07-21 20:49 ` bugzilla-daemon
2020-07-21 20:56 ` bugzilla-daemon
2020-07-21 21:16 ` bugzilla-daemon [this message]
2020-07-22  2:03 ` bugzilla-daemon
2020-07-22  2:05 ` bugzilla-daemon
2020-07-22  3:37 ` bugzilla-daemon
2020-07-22  7:27 ` bugzilla-daemon
2020-07-22 13:04 ` bugzilla-daemon
2020-07-23  0:48 ` bugzilla-daemon
2020-07-23  5:46 ` bugzilla-daemon
2020-07-23 21:30 ` bugzilla-daemon
2020-07-23 21:34 ` bugzilla-daemon
2020-07-24  7:18 ` bugzilla-daemon
2020-07-24  7:24 ` bugzilla-daemon
2020-07-24 19:08 ` bugzilla-daemon
2020-07-24 21:00 ` bugzilla-daemon
2020-07-25  2:38 ` bugzilla-daemon
2020-07-26  6:47 ` bugzilla-daemon
2020-07-26 18:40 ` bugzilla-daemon
2020-07-26 19:55 ` bugzilla-daemon
2020-07-26 22:52 ` bugzilla-daemon
2020-07-26 23:30 ` bugzilla-daemon
2020-07-26 23:52 ` bugzilla-daemon
2020-07-27  6:11 ` bugzilla-daemon
2020-07-27 16:55 ` bugzilla-daemon
2020-07-28  2:29 ` bugzilla-daemon
2020-07-28  3:21 ` bugzilla-daemon
2020-07-28  3:39 ` bugzilla-daemon
2020-07-28  7:14 ` bugzilla-daemon
2020-07-29  2:33 ` bugzilla-daemon
2020-07-29  6:41 ` bugzilla-daemon
2020-07-29 16:02 ` bugzilla-daemon
2020-07-29 16:37 ` bugzilla-daemon
2020-07-29 16:45 ` bugzilla-daemon
2020-07-29 20:32 ` bugzilla-daemon
2020-07-31 16:38 ` bugzilla-daemon
2020-08-02  1:40 ` bugzilla-daemon
2020-08-02 13:06 ` bugzilla-daemon
2020-08-03 13:51 ` bugzilla-daemon
2020-08-05 16:10 ` bugzilla-daemon
2020-08-17  5:45 ` bugzilla-daemon
2021-01-06  6:36 ` bugzilla-daemon
2021-01-06 12:05 ` bugzilla-daemon
2021-01-06 18:59 ` bugzilla-daemon

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=bug-207383-2300-znmrvEwL7a@https.bugzilla.kernel.org/ \
    --to=bugzilla-daemon@bugzilla.kernel.org \
    --cc=dri-devel@lists.freedesktop.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

dri-devel Archive on lore.kernel.org

Archives are clonable:
	git clone --mirror https://lore.kernel.org/dri-devel/0 dri-devel/git/0.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 dri-devel dri-devel/ https://lore.kernel.org/dri-devel \
		dri-devel@lists.freedesktop.org
	public-inbox-index dri-devel

Example config snippet for mirrors

Newsgroup available over NNTP:
	nntp://nntp.lore.kernel.org/org.freedesktop.lists.dri-devel


AGPL code for this site: git clone https://public-inbox.org/public-inbox.git