Dear Stable,
[NB: Re-poking Stable with the correct contact address this time! :)]
> > > area_cache_get() is used to distribute cache->area and set cache->id,
> > > and if cache->id is not 0 and cache->area->kref refcount is 0, it will
> > > release the cache->area by nfp_cpp_area_release(). area_cache_get()
> > > set cache->id before cpp->op->area_init() and nfp_cpp_area_acquire().
> > >
> > > But if area_init() or nfp_cpp_area_acquire() fails, the cache->id is
> > > is already set but the refcount is not increased as expected. At this
> > > time, calling the nfp_cpp_area_release() will cause use-after-free.
> > >
> > > To avoid the use-after-free, set cache->id after area_init() and
> > > nfp_cpp_area_acquire() complete successfully.
> > >
> > > Note: This vulnerability is triggerable by providing emulated device
> > > equipped with specified configuration.
> > >
> > > BUG: KASAN: use-after-free in nfp6000_area_init (/home/user/Kernel/v5.19
> > > /x86_64/src/drivers/net/ethernet/netronome/nfp/nfpcore/nfp6000_pcie.c:760)
> > > Write of size 4 at addr ffff888005b7f4a0 by task swapper/0/1
> > >
> > > Call Trace:
> > > <TASK>
> > > nfp6000_area_init (/home/user/Kernel/v5.19/x86_64/src/drivers/net
> > > /ethernet/netronome/nfp/nfpcore/nfp6000_pcie.c:760)
> > > area_cache_get.constprop.8 (/home/user/Kernel/v5.19/x86_64/src/drivers
> > > /net/ethernet/netronome/nfp/nfpcore/nfp_cppcore.c:884)
> > >
> > > Allocated by task 1:
> > > nfp_cpp_area_alloc_with_name (/home/user/Kernel/v5.19/x86_64/src/drivers
> > > /net/ethernet/netronome/nfp/nfpcore/nfp_cppcore.c:303)
> > > nfp_cpp_area_cache_add (/home/user/Kernel/v5.19/x86_64/src/drivers/net
> > > /ethernet/netronome/nfp/nfpcore/nfp_cppcore.c:802)
> > > nfp6000_init (/home/user/Kernel/v5.19/x86_64/src/drivers/net/ethernet
> > > /netronome/nfp/nfpcore/nfp6000_pcie.c:1230)
> > > nfp_cpp_from_operations (/home/user/Kernel/v5.19/x86_64/src/drivers/net
> > > /ethernet/netronome/nfp/nfpcore/nfp_cppcore.c:1215)
> > > nfp_pci_probe (/home/user/Kernel/v5.19/x86_64/src/drivers/net/ethernet
> > > /netronome/nfp/nfp_main.c:744)
> > >
> > > Freed by task 1:
> > > kfree (/home/user/Kernel/v5.19/x86_64/src/mm/slub.c:4562)
> > > area_cache_get.constprop.8 (/home/user/Kernel/v5.19/x86_64/src/drivers
> > > /net/ethernet/netronome/nfp/nfpcore/nfp_cppcore.c:873)
> > > nfp_cpp_read (/home/user/Kernel/v5.19/x86_64/src/drivers/net/ethernet
> > > /netronome/nfp/nfpcore/nfp_cppcore.c:924 /home/user/Kernel/v5.19/x86_64
> > > /src/drivers/net/ethernet/netronome/nfp/nfpcore/nfp_cppcore.c:973)
> > > nfp_cpp_readl (/home/user/Kernel/v5.19/x86_64/src/drivers/net/ethernet
> > > /netronome/nfp/nfpcore/nfp_cpplib.c:48)
> > >
> > > Signed-off-by: Jialiang Wang <wangjialiang0806(a)163.com>
> >
> > Any reason why this doesn't have a Fixes: tag applied and/or didn't
> > get sent to Stable?
> >
> > Looks as if this needs to go back as far as v4.19.
> >
> > Fixes: 4cb584e0ee7df ("nfp: add CPP access core")
> >
> > commit 02e1a114fdb71e59ee6770294166c30d437bf86a upstream.
Would you be able to take this with the information provided please?
--
Lee Jones [李琼斯]
From: Miklos Szeredi <mszeredi(a)redhat.com>
commit df8629af293493757beccac2d3168fe5a315636e upstream.
Failure to do so may result in EEXIST even if the file only exists in the
cache and not in the filesystem.
The atomic nature of O_EXCL mandates that the cached state should be
ignored and existence verified anew.
Change-Id: I0f173de6f9f1af05d6e816246b5c56b670ec079c
Reported-by: Ken Schalk <kschalk(a)nvidia.com>
Signed-off-by: Miklos Szeredi <mszeredi(a)redhat.com>
Signed-off-by: Wu Bo <bo.wu(a)vivo.com>
---
fs/fuse/dir.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/fs/fuse/dir.c b/fs/fuse/dir.c
index 8e95a75a4559..80a9e50392a0 100644
--- a/fs/fuse/dir.c
+++ b/fs/fuse/dir.c
@@ -205,7 +205,7 @@ static int fuse_dentry_revalidate(struct dentry *entry, unsigned int flags)
if (inode && fuse_is_bad(inode))
goto invalid;
else if (time_before64(fuse_dentry_time(entry), get_jiffies_64()) ||
- (flags & LOOKUP_REVAL)) {
+ (flags & (LOOKUP_EXCL | LOOKUP_REVAL))) {
struct fuse_entry_out outarg;
FUSE_ARGS(args);
struct fuse_forget_link *forget;
--
2.35.3
Greg,
The recent history of copy_file_range() API is somewhat convoluted.
The API changes are documented in copy_file_range(2) man page.
I've just posted a man page update patch [1] to fix some wrong kernel
version references in the man page.
The problem is that it took many kernel releases to get reports on the
regression from v5.3 and yet more releases (v5.12..v5.19) to work on
the solution and get it merged.
This situation leads to confusion among users as can be seen in [2].
You've already picked the patch [1/2] to 5.15.y and I sent you a
request to pick patch [2/2] (from v6.1) as well.
Following are backports of the two patches to 5.10.y, which I verified
with the relevant test in fstests.
Backport to 5.4.y is more challenging because Darrick did a lot of
cleanup in that area between v5.4..v5.10, so I did not do it.
Thanks,
Amir.
[1] https://lore.kernel.org/linux-fsdevel/20221213120834.948163-1-amir73il@gmai…
[2] https://bugzilla.kernel.org/show_bug.cgi?id=216800
Amir Goldstein (2):
vfs: fix copy_file_range() regression in cross-fs copies
vfs: fix copy_file_range() averts filesystem freeze protection
fs/nfsd/vfs.c | 8 ++++-
fs/read_write.c | 90 +++++++++++++++++++++++++++++++++---------------------
include/linux/fs.h | 8 +++++
3 files changed, 70 insertions(+), 36 deletions(-)
--
2.16.5
v5.11 changes the blkdev lookup mechanism completely since commit
22ae8ce8b892 ("block: simplify bdev/disk lookup in blkdev_get"),
and small part of the change is to unhash part bdev inode when
deleting partition. Turns out this kind of change does fix one
nasty issue in case of BLOCK_EXT_MAJOR:
1) when one partition is deleted & closed, disk_put_part() is always
called before bdput(bdev), see blkdev_put(); so the part's devt can
be freed & re-used before the inode is dropped
2) then new partition with same devt can be created just before the
inode in 1) is dropped, then the old inode/bdev structurein 1) is
re-used for this new partition, this way causes use-after-free and
kernel panic.
It isn't possible to backport the whole big patchset of "merge struct
block_device and struct hd_struct v4" for addressing this issue.
https://lore.kernel.org/linux-block/20201128161510.347752-1-hch@lst.de/
So fixes it by unhashing part bdev in delete_partition(), and this way
is actually aligned with v5.11+'s behavior.
Backported from the following 5.10.y commit:
5f2f77560591 ("block: unhash blkdev part inode when the part is deleted")
Reported-by: Shiwei Cui <cuishw(a)inspur.com>
Tested-by: Shiwei Cui <cuishw(a)inspur.com>
Cc: Christoph Hellwig <hch(a)lst.de>
Cc: Jan Kara <jack(a)suse.cz>
Signed-off-by: Ming Lei <ming.lei(a)redhat.com>
---
block/partition-generic.c | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/block/partition-generic.c b/block/partition-generic.c
index 298c05f8b5e3..434c122cb958 100644
--- a/block/partition-generic.c
+++ b/block/partition-generic.c
@@ -254,6 +254,7 @@ void delete_partition(struct gendisk *disk, int partno)
{
struct disk_part_tbl *ptbl = disk->part_tbl;
struct hd_struct *part;
+ struct block_device *bdev;
if (partno >= ptbl->len)
return;
@@ -267,6 +268,11 @@ void delete_partition(struct gendisk *disk, int partno)
kobject_put(part->holder_dir);
device_del(part_to_dev(part));
+ bdev = bdget(part_devt(part));
+ if (bdev) {
+ remove_inode_hash(bdev->bd_inode);
+ bdput(bdev);
+ }
hd_struct_kill(part);
}
--
2.38.1