Identify if we have the software, in 16.09, 17.03, and unstable. Then determine if we are vulnerable, and make a comment with your findings. It can also be helpful to specify if you think there is a patch, or if it can be fixed via a general update.
Example:
unstable: we are not vulnerable (link to the package)
17.03: we are vulnerable (link to the package)
16.09: we don't have it packaged
IMPORTANT: If you believe there are possibly related issues, bring them up on the parent issue!
Patching
Start by commenting on this issue saying you're working on a patch. This way, we don't duplicate work.
If you open a pull request, tag this issue and the master issue for the roundup.
If you commit the patch directly to a branch, please leave a comment on this issue with the branch and the commit hash, example:
Tue, 7 Mar 2017 13:06:55 -0800 Dan Williams , CAPcyv4h6sA6Sx4wmY_XH0VoTNeVYu0Szd4hdmAdfsNZzwX-H-w@mail.gmail.com
The patch below fixes a high severity, but limited exposure, security
issue in the direct-I/O support for DAX mappings. High severity in
that any file that can be read can be written, limited exposure in
that it requires uncommon platform resources (persistent memory),
usage of the still flagged "experimental" DAX support in XFS/EXT4, and
non-default configuration to enable direct-I/O for DAX mappings
(details below).
It has been posted publicly on the Linux kernel development mailing list here:
https://lkml.org/lkml/2017/2/25/108
---
mm: fix gup_pte_range() vs DAX mappings
gup_pte_range() fails to check pte_allows_gup() before translating a DAX
pte entry, pte_devmap(), to a page. This allows writes to read-only
mappings, and bypasses the DAX cacheline dirty tracking due to missed
'mkwrite' faults. The gup_huge_pmd() path and the gup_huge_pud() path
correctly check pte_allows_gup() before checking for _devmap() entries.
Cc: <stable@vger.kernel.org>
Cc: Dave Hansen <dave.hansen@linux.intel.com>
Reported-by: Xiong Zhou <xzhou@redhat.com>
Reported-by: Ross Zwisler <ross.zwisler@linux.intel.com>
Fixes: 3565fce3a659 ("mm, x86: get_user_pages() for dax mappings")
Signed-off-by: Ross Zwisler <ross.zwisler@linux.intel.com>
Signed-off-by: Dan Williams <dan.j.williams@intel.com>
---
arch/x86/mm/gup.c | 8 ++++++--
1 file changed, 6 insertions(+), 2 deletions(-)
diff --git a/arch/x86/mm/gup.c b/arch/x86/mm/gup.c
index 99c7805a9693..9d32ee608807 100644
--- a/arch/x86/mm/gup.c
+++ b/arch/x86/mm/gup.c
@@ -120,6 +120,11 @@ static noinline int gup_pte_range(pmd_t pmd,
unsigned long addr,
return 0;
}
+ if (!pte_allows_gup(pte_val(pte), write)) {
+ pte_unmap(ptep);
+ return 0;
+ }
+
if (pte_devmap(pte)) {
pgmap = get_dev_pagemap(pte_pfn(pte), pgmap);
if (unlikely(!pgmap)) {
@@ -127,8 +132,7 @@ static noinline int gup_pte_range(pmd_t pmd,
unsigned long addr,
pte_unmap(ptep);
return 0;
}
- } else if (!pte_allows_gup(pte_val(pte), write) ||
- pte_special(pte)) {
+ } else if (pte_special(pte)) {
pte_unmap(ptep);
return 0;
}
--
2.7.4
---
The vulnerability was introduced in kernel v4.5. It requires the
following configuration options to be enabled
CONFIG_ZONE_DEVICE
CONFIG_FS_DAX
CONFIG_BLK_DEV_PMEM
The above three options plus defining persistent memory with the
memmap=ss!nn kernel command line parameter creates a pmem block device
that will expose the failing condition if an xfs or ext4 filesytem is
mounted on it with the "-o dax" mount option.
CONFIG_ACPI_NFIT
CONFIG_NVDIMM_PFN
The memmap=ss!nn method of defining persistent memory is primarily
used for testing. Starting with ACPI 6, platform firmware publishes an
NFIT (NVDIMM Firmware Interface Table) to describe persistent memory
resources. Persistent memory described by an NFIT does not support
direct-I/O by default and the CONFIG_NVDIMM_PFN mechanism must be used
to enable direct-I/O. The "ndctl" utility is used to reconfigure an
NFIT-defined pmem device with direct-I/O support [1]
[1]: https://lists.01.org/pipermail/linux-nvdimm/2017-February/008808.html
Here is a report from the oss-security mailing list for Vulnerability Roundup 27.
Skip to First Email
Instructions:
Identification
Identify if we have the software, in 16.09, 17.03, and unstable. Then determine if we are vulnerable, and make a comment with your findings. It can also be helpful to specify if you think there is a patch, or if it can be fixed via a general update.
Example:
IMPORTANT: If you believe there are possibly related issues, bring them up on the parent issue!
Patching
Start by commenting on this issue saying you're working on a patch. This way, we don't duplicate work.
If you open a pull request, tag this issue and the master issue for the roundup.
If you commit the patch directly to a branch, please leave a comment on this issue with the branch and the commit hash, example:
Skip to First Email
Upon Completion ...
Info
Triage Indicator:
Should the search term be changed from
linux-kernel
? Suggest a new package search by commenting:Known CVEs:
Skip to End
Tue, 7 Mar 2017 13:06:55 -0800 Dan Williams,
CAPcyv4h6sA6Sx4wmY_XH0VoTNeVYu0Szd4hdmAdfsNZzwX-H-w@mail.gmail.com
Skip to End