Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
- sound/pci/hda/hda_controller.c | 2 +-
+ sound/pci/hda/hda_controller.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
-diff --git a/sound/pci/hda/hda_controller.c b/sound/pci/hda/hda_controller.c
-index 9cdf86f04e03..a25e34b2f82a 100644
--- a/sound/pci/hda/hda_controller.c
+++ b/sound/pci/hda/hda_controller.c
-@@ -673,7 +673,7 @@ static int azx_rirb_get_response(struct hdac_bus *bus, unsigned int addr,
+@@ -673,7 +673,7 @@ static int azx_rirb_get_response(struct
return -EAGAIN; /* give a chance to retry */
}
"azx_get_response timeout, switching to single_cmd mode: last cmd=0x%08x\n",
bus->last_cmd[addr]);
chip->single_cmd = 1;
---
-2.20.1
-
--- /dev/null
+From b9959c7a347d6adbb558fba7e36e9fef3cba3b07 Mon Sep 17 00:00:00 2001
+From: Linus Torvalds <torvalds@linux-foundation.org>
+Date: Fri, 18 Oct 2019 18:41:16 -0400
+Subject: filldir[64]: remove WARN_ON_ONCE() for bad directory entries
+
+From: Linus Torvalds <torvalds@linux-foundation.org>
+
+commit b9959c7a347d6adbb558fba7e36e9fef3cba3b07 upstream.
+
+This was always meant to be a temporary thing, just for testing and to
+see if it actually ever triggered.
+
+The only thing that reported it was syzbot doing disk image fuzzing, and
+then that warning is expected. So let's just remove it before -rc4,
+because the extra sanity testing should probably go to -stable, but we
+don't want the warning to do so.
+
+Reported-by: syzbot+3031f712c7ad5dd4d926@syzkaller.appspotmail.com
+Fixes: 8a23eb804ca4 ("Make filldir[64]() verify the directory entry filename is valid")
+Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
+Signed-off-by: Siddharth Chandrasekaran <csiddharth@vmware.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ fs/readdir.c | 4 ++--
+ 1 file changed, 2 insertions(+), 2 deletions(-)
+
+--- a/fs/readdir.c
++++ b/fs/readdir.c
+@@ -77,9 +77,9 @@ EXPORT_SYMBOL(iterate_dir);
+ */
+ static int verify_dirent_name(const char *name, int len)
+ {
+- if (WARN_ON_ONCE(!len))
++ if (!len)
+ return -EIO;
+- if (WARN_ON_ONCE(memchr(name, '/', len)))
++ if (memchr(name, '/', len))
+ return -EIO;
+ return 0;
+ }
--- /dev/null
+From 8a23eb804ca4f2be909e372cf5a9e7b30ae476cd Mon Sep 17 00:00:00 2001
+From: Linus Torvalds <torvalds@linux-foundation.org>
+Date: Sat, 5 Oct 2019 11:32:52 -0700
+Subject: Make filldir[64]() verify the directory entry filename is valid
+
+From: Linus Torvalds <torvalds@linux-foundation.org>
+
+commit 8a23eb804ca4f2be909e372cf5a9e7b30ae476cd upstream.
+
+This has been discussed several times, and now filesystem people are
+talking about doing it individually at the filesystem layer, so head
+that off at the pass and just do it in getdents{64}().
+
+This is partially based on a patch by Jann Horn, but checks for NUL
+bytes as well, and somewhat simplified.
+
+There's also commentary about how it might be better if invalid names
+due to filesystem corruption don't cause an immediate failure, but only
+an error at the end of the readdir(), so that people can still see the
+filenames that are ok.
+
+There's also been discussion about just how much POSIX strictly speaking
+requires this since it's about filesystem corruption. It's really more
+"protect user space from bad behavior" as pointed out by Jann. But
+since Eric Biederman looked up the POSIX wording, here it is for context:
+
+ "From readdir:
+
+ The readdir() function shall return a pointer to a structure
+ representing the directory entry at the current position in the
+ directory stream specified by the argument dirp, and position the
+ directory stream at the next entry. It shall return a null pointer
+ upon reaching the end of the directory stream. The structure dirent
+ defined in the <dirent.h> header describes a directory entry.
+
+ From definitions:
+
+ 3.129 Directory Entry (or Link)
+
+ An object that associates a filename with a file. Several directory
+ entries can associate names with the same file.
+
+ ...
+
+ 3.169 Filename
+
+ A name consisting of 1 to {NAME_MAX} bytes used to name a file. The
+ characters composing the name may be selected from the set of all
+ character values excluding the slash character and the null byte. The
+ filenames dot and dot-dot have special meaning. A filename is
+ sometimes referred to as a 'pathname component'."
+
+Note that I didn't bother adding the checks to any legacy interfaces
+that nobody uses.
+
+Also note that if this ends up being noticeable as a performance
+regression, we can fix that to do a much more optimized model that
+checks for both NUL and '/' at the same time one word at a time.
+
+We haven't really tended to optimize 'memchr()', and it only checks for
+one pattern at a time anyway, and we really _should_ check for NUL too
+(but see the comment about "soft errors" in the code about why it
+currently only checks for '/')
+
+See the CONFIG_DCACHE_WORD_ACCESS case of hash_name() for how the name
+lookup code looks for pathname terminating characters in parallel.
+
+Link: https://lore.kernel.org/lkml/20190118161440.220134-2-jannh@google.com/
+Cc: Alexander Viro <viro@zeniv.linux.org.uk>
+Cc: Jann Horn <jannh@google.com>
+Cc: Eric W. Biederman <ebiederm@xmission.com>
+Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
+Signed-off-by: Siddharth Chandrasekaran <csiddharth@vmware.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ fs/readdir.c | 40 ++++++++++++++++++++++++++++++++++++++++
+ 1 file changed, 40 insertions(+)
+
+--- a/fs/readdir.c
++++ b/fs/readdir.c
+@@ -51,6 +51,40 @@ out:
+ EXPORT_SYMBOL(iterate_dir);
+
+ /*
++ * POSIX says that a dirent name cannot contain NULL or a '/'.
++ *
++ * It's not 100% clear what we should really do in this case.
++ * The filesystem is clearly corrupted, but returning a hard
++ * error means that you now don't see any of the other names
++ * either, so that isn't a perfect alternative.
++ *
++ * And if you return an error, what error do you use? Several
++ * filesystems seem to have decided on EUCLEAN being the error
++ * code for EFSCORRUPTED, and that may be the error to use. Or
++ * just EIO, which is perhaps more obvious to users.
++ *
++ * In order to see the other file names in the directory, the
++ * caller might want to make this a "soft" error: skip the
++ * entry, and return the error at the end instead.
++ *
++ * Note that this should likely do a "memchr(name, 0, len)"
++ * check too, since that would be filesystem corruption as
++ * well. However, that case can't actually confuse user space,
++ * which has to do a strlen() on the name anyway to find the
++ * filename length, and the above "soft error" worry means
++ * that it's probably better left alone until we have that
++ * issue clarified.
++ */
++static int verify_dirent_name(const char *name, int len)
++{
++ if (WARN_ON_ONCE(!len))
++ return -EIO;
++ if (WARN_ON_ONCE(memchr(name, '/', len)))
++ return -EIO;
++ return 0;
++}
++
++/*
+ * Traditional linux readdir() handling..
+ *
+ * "count=1" is a special case, meaning that the buffer is one
+@@ -159,6 +193,9 @@ static int filldir(struct dir_context *c
+ int reclen = ALIGN(offsetof(struct linux_dirent, d_name) + namlen + 2,
+ sizeof(long));
+
++ buf->error = verify_dirent_name(name, namlen);
++ if (unlikely(buf->error))
++ return buf->error;
+ buf->error = -EINVAL; /* only used if we fail.. */
+ if (reclen > buf->count)
+ return -EINVAL;
+@@ -243,6 +280,9 @@ static int filldir64(struct dir_context
+ int reclen = ALIGN(offsetof(struct linux_dirent64, d_name) + namlen + 1,
+ sizeof(u64));
+
++ buf->error = verify_dirent_name(name, namlen);
++ if (unlikely(buf->error))
++ return buf->error;
+ buf->error = -EINVAL; /* only used if we fail.. */
+ if (reclen > buf->count)
+ return -EINVAL;
--- /dev/null
+From 84092996673211f16ef3b942a191d7952e9dfea9 Mon Sep 17 00:00:00 2001
+From: Arnd Bergmann <arnd@arndb.de>
+Date: Fri, 29 Jan 2016 12:39:10 +0100
+Subject: net: davinci_cpdma: use dma_addr_t for DMA address
+
+From: Arnd Bergmann <arnd@arndb.de>
+
+commit 84092996673211f16ef3b942a191d7952e9dfea9 upstream.
+
+The davinci_cpdma mixes up physical addresses as seen from the CPU
+and DMA addresses as seen from a DMA master, since it can operate
+on both normal memory or an on-chip buffer. If dma_addr_t is
+different from phys_addr_t, this means we get a compile-time warning
+about the type mismatch:
+
+ethernet/ti/davinci_cpdma.c: In function 'cpdma_desc_pool_create':
+ethernet/ti/davinci_cpdma.c:182:48: error: passing argument 3 of 'dma_alloc_coherent' from incompatible pointer type [-Werror=incompatible-pointer-types]
+ pool->cpumap = dma_alloc_coherent(dev, size, &pool->phys,
+In file included from ethernet/ti/davinci_cpdma.c:21:0:
+dma-mapping.h:398:21: note: expected 'dma_addr_t * {aka long long unsigned int *}' but argument is of type 'phys_addr_t * {aka unsigned int *}'
+ static inline void *dma_alloc_coherent(struct device *dev, size_t size,
+
+This slightly restructures the code so the address we use for
+mapping RAM into a DMA address is always a dma_addr_t, avoiding
+the warning. The code is correct even if both types are 32-bit
+because the DMA master in this device only supports 32-bit addressing
+anyway, independent of the types that are used.
+
+We still assign this value to pool->phys, and that is wrong if
+the driver is ever used with an IOMMU, but that value appears to
+be never used, so there is no problem really. I've added a couple
+of comments about where we do things that are slightly violating
+the API.
+
+Signed-off-by: Arnd Bergmann <arnd@arndb.de>
+Signed-off-by: David S. Miller <davem@davemloft.net>
+Signed-off-by: Daniel Wagner <dwagner@suse.de>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/net/ethernet/ti/davinci_cpdma.c | 12 ++++++------
+ 1 file changed, 6 insertions(+), 6 deletions(-)
+
+--- a/drivers/net/ethernet/ti/davinci_cpdma.c
++++ b/drivers/net/ethernet/ti/davinci_cpdma.c
+@@ -82,7 +82,7 @@ struct cpdma_desc {
+
+ struct cpdma_desc_pool {
+ phys_addr_t phys;
+- u32 hw_addr;
++ dma_addr_t hw_addr;
+ void __iomem *iomap; /* ioremap map */
+ void *cpumap; /* dma_alloc map */
+ int desc_size, mem_size;
+@@ -152,7 +152,7 @@ struct cpdma_chan {
+ * abstract out these details
+ */
+ static struct cpdma_desc_pool *
+-cpdma_desc_pool_create(struct device *dev, u32 phys, u32 hw_addr,
++cpdma_desc_pool_create(struct device *dev, u32 phys, dma_addr_t hw_addr,
+ int size, int align)
+ {
+ int bitmap_size;
+@@ -176,13 +176,13 @@ cpdma_desc_pool_create(struct device *de
+
+ if (phys) {
+ pool->phys = phys;
+- pool->iomap = ioremap(phys, size);
++ pool->iomap = ioremap(phys, size); /* should be memremap? */
+ pool->hw_addr = hw_addr;
+ } else {
+- pool->cpumap = dma_alloc_coherent(dev, size, &pool->phys,
++ pool->cpumap = dma_alloc_coherent(dev, size, &pool->hw_addr,
+ GFP_KERNEL);
+- pool->iomap = pool->cpumap;
+- pool->hw_addr = pool->phys;
++ pool->iomap = (void __iomem __force *)pool->cpumap;
++ pool->phys = pool->hw_addr; /* assumes no IOMMU, don't use this value */
+ }
+
+ if (pool->iomap)
ocfs2-fix-passing-zero-to-ptr_err-warning.patch
kernel-sysctl-make-drop_caches-write-only.patch
alsa-hda-downgrade-error-message-for-single-cmd-fall.patch
+make-filldir-verify-the-directory-entry-filename-is-valid.patch
+filldir-remove-warn_on_once-for-bad-directory-entries.patch
+net-davinci_cpdma-use-dma_addr_t-for-dma-address.patch
projects / thirdparty / kernel / stable-queue.git / commitdiff
