linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: David Hildenbrand <david@redhat.com>
To: Hans de Goede <hdegoede@redhat.com>
Cc: "linux-mm@kvack.org" <linux-mm@kvack.org>,
	Mauro Carvalho Chehab <mchehab@kernel.org>,
	"linux-media@vger.kernel.org" <linux-media@vger.kernel.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	Sakari Ailus <sakari.ailus@linux.intel.com>,
	Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Subject: Dubious usage of VM_SHARED in atomisp_fops.c
Date: Wed, 14 Dec 2022 11:22:39 +0100	[thread overview]
Message-ID: <fbefc16e-84d3-8afc-8c8e-4229bded0c8a@redhat.com> (raw)

Hi,

going over all VM_SHARED and VM_MAYSHARE user in the kernel, I stumbled 
over the following dubious code in 
drivers/staging/media/atomisp/pci/atomisp_fops.c:


if (!(vma->vm_flags & (VM_WRITE | VM_READ)))
	return -EACCES;

...

if (!(vma->vm_flags & VM_SHARED)) {
	/* Map private buffer.
	 * Set VM_SHARED to the flags since we need
	 * to map the buffer page by page.
	 * Without VM_SHARED, remap_pfn_range() treats
	 * this kind of mapping as invalid.
	 */
	vma->vm_flags |= VM_SHARED;
	ret = hmm_mmap(vma, vma->vm_pgoff << PAGE_SHIFT);
	...
}


We're converting a writable MAP_PRIVATE mapping ("COW mapping") into a 
writable MAP_SHARED mapping, to hack around the is_cow_mapping() check 
in remap_pfn_range_notrack().

We're not even setting VM_MAYSHARE and turn the mapping silently into 
something with completely different semantics.


That code has to go.


One approach would be to reject such mappings (no idea if user space 
relies on private mappings), the other one would be to remove this 
driver. Judging that the driver already was marked broken in 2020 
(ad85094b293e ("Revert "media: staging: atomisp: Remove driver"")), 
maybe it's time for the driver to go.

Thoughts?

-- 
Thanks,

David / dhildenb



             reply	other threads:[~2022-12-14 10:22 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-12-14 10:22 David Hildenbrand [this message]
2022-12-14 11:07 ` Hans de Goede
2022-12-14 11:08   ` David Hildenbrand
2022-12-14 11:39 ` Andy Shevchenko

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=fbefc16e-84d3-8afc-8c8e-4229bded0c8a@redhat.com \
    --to=david@redhat.com \
    --cc=andriy.shevchenko@linux.intel.com \
    --cc=hdegoede@redhat.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-media@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=mchehab@kernel.org \
    --cc=sakari.ailus@linux.intel.com \
    /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
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox