October 2024 - Linux-stable-mirror

+ fixes-null-pointer-dereference-in-pfnmap_lockdep_assert.patch added to mm-hotfixes-unstable branch

by Andrew Morton

The patch titled Subject: mm: fix null pointer dereference in pfnmap_lockdep_assert has been added to the -mm mm-hotfixes-unstable branch. Its filename is fixes-null-pointer-dereference-in-pfnmap_lockdep_assert.patch This patch will shortly appear at https://git.kernel.org/pub/scm/linux/kernel/git/akpm/25-new.git/tree/patche… This patch will later appear in the mm-hotfixes-unstable branch at git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm Before you just go and hit "reply", please: a) Consider who else should be cc'ed b) Prefer to cc a suitable mailing list as well c) Ideally: find the original patch on the mailing list and do a reply-to-all to that, adding suitable additional cc's *** Remember to use Documentation/process/submit-checklist.rst when testing your code *** The -mm tree is included into linux-next via the mm-everything branch at git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm and is updated there every 2-3 working days ------------------------------------------------------ From: Manas <manas18244(a)iiitd.ac.in> Subject: mm: fix null pointer dereference in pfnmap_lockdep_assert Date: Fri, 04 Oct 2024 23:12:16 +0530 syzbot has pointed to a possible null pointer dereference in pfnmap_lockdep_assert. vm_file member of vm_area_struct is being dereferenced without any checks. This fix assigns mapping only if vm_file is not NULL. Peter said (https://lkml.kernel.org/r/Zv8HRA5mnhVevBN_@x1n): : If I read the stack right, the crash was before mmap() of the new vma : happens, instead it's during unmap() of one existing vma which existed and : overlapped with the new vma's mapping range: : : follow_phys arch/x86/mm/pat/memtype.c:956 [inline] : get_pat_info+0x182/0x3f0 arch/x86/mm/pat/memtype.c:988 : untrack_pfn+0x327/0x640 arch/x86/mm/pat/memtype.c:1101 : unmap_single_vma+0x1f6/0x2b0 mm/memory.c:1834 : unmap_vmas+0x3cc/0x5f0 mm/memory.c:1900 : unmap_region+0x214/0x380 mm/vma.c:354 <--------------- here : mmap_region+0x22f9/0x2990 mm/mmap.c:1573 : do_mmap+0x8f0/0x1000 mm/mmap.c:496 : vm_mmap_pgoff+0x1dd/0x3d0 mm/util.c:588 : ksys_mmap_pgoff+0x4eb/0x720 mm/mmap.c:542 : do_syscall_x64 arch/x86/entry/common.c:52 [inline] : do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83 : entry_SYSCALL_64_after_hwframe+0x77/0x7f : : It looks like the vma that was overwritten by the new file vma mapping : could be a VM_PFNMAP vma (I'm guessing vvar or something similar..), : that's where untrack_pfn() got kicked off. In this case, the vma being : overwritten and to be unmapped can have ->vm_file==NULL (while ->vm_ops : non-NULL; /me looking at __install_special_mapping()). Link: https://lkml.kernel.org/r/20241004-fix-null-deref-v4-1-d0a8ec01ac85@iiitd.a… Reported-by: syzbot+093d096417e7038a689b(a)syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=093d096417e7038a689b Cc: Anup Sharma <anupnewsmail(a)gmail.com> Cc: Shuah Khan <skhan(a)linuxfoundation.org> Cc: Matthew Wilcox <willy(a)infradead.org> Cc: <stable(a)vger.kernel.org> Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> --- mm/memory.c | 7 +++++-- 1 file changed, 5 insertions(+), 2 deletions(-) --- a/mm/memory.c~fixes-null-pointer-dereference-in-pfnmap_lockdep_assert +++ a/mm/memory.c @@ -6355,10 +6355,13 @@ static inline void pfnmap_args_setup(str static inline void pfnmap_lockdep_assert(struct vm_area_struct *vma) { #ifdef CONFIG_LOCKDEP - struct address_space *mapping = vma->vm_file->f_mapping; + struct address_space *mapping = NULL; + + if (vma->vm_file) + mapping = vma->vm_file->f_mapping; if (mapping) - lockdep_assert(lockdep_is_held(&vma->vm_file->f_mapping->i_mmap_rwsem) || + lockdep_assert(lockdep_is_held(&mapping->i_mmap_rwsem) || lockdep_is_held(&vma->vm_mm->mmap_lock)); else lockdep_assert(lockdep_is_held(&vma->vm_mm->mmap_lock)); _ Patches currently in -mm which might be from manas18244(a)iiitd.ac.in are fixes-null-pointer-dereference-in-pfnmap_lockdep_assert.patch

7 months, 1 week

1
0
0 0

[PATCH 1/2] firmware: qcom: scm: suppress download mode error

by Johan Hovold

Stop spamming the logs with errors about missing mechanism for setting the so called download (or dump) mode for users that have not requested that feature to be enabled in the first place. This avoids the follow error being logged on boot as well as on shutdown when the feature it not available and download mode has not been enabled on the kernel command line: qcom_scm firmware:scm: No available mechanism for setting download mode Fixes: 79cb2cb8d89b ("firmware: qcom: scm: Disable SDI and write no dump to dump mode") Fixes: 781d32d1c970 ("firmware: qcom_scm: Clear download bit during reboot") Cc: Mukesh Ojha <quic_mojha(a)quicinc.com> Cc: stable(a)vger.kernel.org # 6.4 Signed-off-by: Johan Hovold <johan+linaro(a)kernel.org> --- drivers/firmware/qcom/qcom_scm.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/firmware/qcom/qcom_scm.c b/drivers/firmware/qcom/qcom_scm.c index 10986cb11ec0..e2ac595902ed 100644 --- a/drivers/firmware/qcom/qcom_scm.c +++ b/drivers/firmware/qcom/qcom_scm.c @@ -545,7 +545,7 @@ static void qcom_scm_set_download_mode(u32 dload_mode) } else if (__qcom_scm_is_call_available(__scm->dev, QCOM_SCM_SVC_BOOT, QCOM_SCM_BOOT_SET_DLOAD_MODE)) { ret = __qcom_scm_set_dload_mode(__scm->dev, !!dload_mode); - } else { + } else if (dload_mode) { dev_err(__scm->dev, "No available mechanism for setting download mode\n"); } -- 2.45.2

7 months, 1 week

2
1
0 0

[PATCH] drm/amd/display: fix hibernate entry for DCN35+

by Hamza Mahfooz

Since, two suspend-resume cycles are required to enter hibernate and, since we only need to enable idle optimizations in the first cycle (which is pretty much equivalent to s2idle). We can check in_s0ix, to prevent the system from entering idle optimizations before it actually enters hibernate (from display's perspective). Cc: stable(a)vger.kernel.org # 6.10+ Signed-off-by: Hamza Mahfooz <hamza.mahfooz(a)amd.com> --- drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 7 ++++--- 1 file changed, 4 insertions(+), 3 deletions(-) diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c index 4651b884d8d9..546a168a2fbf 100644 --- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c +++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c @@ -2996,10 +2996,11 @@ static int dm_suspend(struct amdgpu_ip_block *ip_block) hpd_rx_irq_work_suspend(dm); - if (adev->dm.dc->caps.ips_support) - dc_allow_idle_optimizations(adev->dm.dc, true); - dc_set_power_state(dm->dc, DC_ACPI_CM_POWER_STATE_D3); + + if (dm->dc->caps.ips_support && adev->in_s0ix) + dc_allow_idle_optimizations(dm->dc, true); + dc_dmub_srv_set_power_state(dm->dc->ctx->dmub_srv, DC_ACPI_CM_POWER_STATE_D3); return 0; -- 2.46.0

7 months, 1 week

2
3
0 0

[PATCH 4.19] f2fs: Require FMODE_WRITE for atomic write ioctls

by Eric Biggers

From: Jann Horn <jannh(a)google.com> commit 4f5a100f87f32cb65d4bb1ad282a08c92f6f591e upstream. The F2FS ioctls for starting and committing atomic writes check for inode_owner_or_capable(), but this does not give LSMs like SELinux or Landlock an opportunity to deny the write access - if the caller's FSUID matches the inode's UID, inode_owner_or_capable() immediately returns true. There are scenarios where LSMs want to deny a process the ability to write particular files, even files that the FSUID of the process owns; but this can currently partially be bypassed using atomic write ioctls in two ways: - F2FS_IOC_START_ATOMIC_REPLACE + F2FS_IOC_COMMIT_ATOMIC_WRITE can truncate an inode to size 0 - F2FS_IOC_START_ATOMIC_WRITE + F2FS_IOC_ABORT_ATOMIC_WRITE can revert changes another process concurrently made to a file Fix it by requiring FMODE_WRITE for these operations, just like for F2FS_IOC_MOVE_RANGE. Since any legitimate caller should only be using these ioctls when intending to write into the file, that seems unlikely to break anything. Fixes: 88b88a667971 ("f2fs: support atomic writes") Cc: stable(a)vger.kernel.org Signed-off-by: Jann Horn <jannh(a)google.com> Reviewed-by: Chao Yu <chao(a)kernel.org> Reviewed-by: Eric Biggers <ebiggers(a)google.com> Signed-off-by: Jaegeuk Kim <jaegeuk(a)kernel.org> Signed-off-by: Eric Biggers <ebiggers(a)google.com> --- fs/f2fs/file.c | 15 +++++++++++++++ 1 file changed, 15 insertions(+) diff --git a/fs/f2fs/file.c b/fs/f2fs/file.c index 043ce96ac1270..0cc2f41e81243 100644 --- a/fs/f2fs/file.c +++ b/fs/f2fs/file.c @@ -1709,10 +1709,13 @@ static int f2fs_ioc_getversion(struct file *filp, unsigned long arg) static int f2fs_ioc_start_atomic_write(struct file *filp) { struct inode *inode = file_inode(filp); int ret; + if (!(filp->f_mode & FMODE_WRITE)) + return -EBADF; + if (!inode_owner_or_capable(inode)) return -EACCES; if (!S_ISREG(inode->i_mode)) return -EINVAL; @@ -1766,10 +1769,13 @@ static int f2fs_ioc_start_atomic_write(struct file *filp) static int f2fs_ioc_commit_atomic_write(struct file *filp) { struct inode *inode = file_inode(filp); int ret; + if (!(filp->f_mode & FMODE_WRITE)) + return -EBADF; + if (!inode_owner_or_capable(inode)) return -EACCES; ret = mnt_want_write_file(filp); if (ret) @@ -1811,10 +1817,13 @@ static int f2fs_ioc_commit_atomic_write(struct file *filp) static int f2fs_ioc_start_volatile_write(struct file *filp) { struct inode *inode = file_inode(filp); int ret; + if (!(filp->f_mode & FMODE_WRITE)) + return -EBADF; + if (!inode_owner_or_capable(inode)) return -EACCES; if (!S_ISREG(inode->i_mode)) return -EINVAL; @@ -1846,10 +1855,13 @@ static int f2fs_ioc_start_volatile_write(struct file *filp) static int f2fs_ioc_release_volatile_write(struct file *filp) { struct inode *inode = file_inode(filp); int ret; + if (!(filp->f_mode & FMODE_WRITE)) + return -EBADF; + if (!inode_owner_or_capable(inode)) return -EACCES; ret = mnt_want_write_file(filp); if (ret) @@ -1875,10 +1887,13 @@ static int f2fs_ioc_release_volatile_write(struct file *filp) static int f2fs_ioc_abort_volatile_write(struct file *filp) { struct inode *inode = file_inode(filp); int ret; + if (!(filp->f_mode & FMODE_WRITE)) + return -EBADF; + if (!inode_owner_or_capable(inode)) return -EACCES; ret = mnt_want_write_file(filp); if (ret) base-commit: de2cffe297563c815c840cfa14b77a0868b61e53 -- 2.47.0.rc0.187.ge670bccf7e-goog

7 months, 1 week

1
0
0 0

[PATCH 5.4] f2fs: Require FMODE_WRITE for atomic write ioctls

by Eric Biggers

From: Jann Horn <jannh(a)google.com> commit 4f5a100f87f32cb65d4bb1ad282a08c92f6f591e upstream. The F2FS ioctls for starting and committing atomic writes check for inode_owner_or_capable(), but this does not give LSMs like SELinux or Landlock an opportunity to deny the write access - if the caller's FSUID matches the inode's UID, inode_owner_or_capable() immediately returns true. There are scenarios where LSMs want to deny a process the ability to write particular files, even files that the FSUID of the process owns; but this can currently partially be bypassed using atomic write ioctls in two ways: - F2FS_IOC_START_ATOMIC_REPLACE + F2FS_IOC_COMMIT_ATOMIC_WRITE can truncate an inode to size 0 - F2FS_IOC_START_ATOMIC_WRITE + F2FS_IOC_ABORT_ATOMIC_WRITE can revert changes another process concurrently made to a file Fix it by requiring FMODE_WRITE for these operations, just like for F2FS_IOC_MOVE_RANGE. Since any legitimate caller should only be using these ioctls when intending to write into the file, that seems unlikely to break anything. Fixes: 88b88a667971 ("f2fs: support atomic writes") Cc: stable(a)vger.kernel.org Signed-off-by: Jann Horn <jannh(a)google.com> Reviewed-by: Chao Yu <chao(a)kernel.org> Reviewed-by: Eric Biggers <ebiggers(a)google.com> Signed-off-by: Jaegeuk Kim <jaegeuk(a)kernel.org> Signed-off-by: Eric Biggers <ebiggers(a)google.com> --- fs/f2fs/file.c | 15 +++++++++++++++ 1 file changed, 15 insertions(+) diff --git a/fs/f2fs/file.c b/fs/f2fs/file.c index 2330600dbe02e..738d65abde510 100644 --- a/fs/f2fs/file.c +++ b/fs/f2fs/file.c @@ -1855,10 +1855,13 @@ static int f2fs_ioc_start_atomic_write(struct file *filp) struct inode *inode = file_inode(filp); struct f2fs_inode_info *fi = F2FS_I(inode); struct f2fs_sb_info *sbi = F2FS_I_SB(inode); int ret; + if (!(filp->f_mode & FMODE_WRITE)) + return -EBADF; + if (!inode_owner_or_capable(inode)) return -EACCES; if (!S_ISREG(inode->i_mode)) return -EINVAL; @@ -1921,10 +1924,13 @@ static int f2fs_ioc_start_atomic_write(struct file *filp) static int f2fs_ioc_commit_atomic_write(struct file *filp) { struct inode *inode = file_inode(filp); int ret; + if (!(filp->f_mode & FMODE_WRITE)) + return -EBADF; + if (!inode_owner_or_capable(inode)) return -EACCES; ret = mnt_want_write_file(filp); if (ret) @@ -1963,10 +1969,13 @@ static int f2fs_ioc_commit_atomic_write(struct file *filp) static int f2fs_ioc_start_volatile_write(struct file *filp) { struct inode *inode = file_inode(filp); int ret; + if (!(filp->f_mode & FMODE_WRITE)) + return -EBADF; + if (!inode_owner_or_capable(inode)) return -EACCES; if (!S_ISREG(inode->i_mode)) return -EINVAL; @@ -1998,10 +2007,13 @@ static int f2fs_ioc_start_volatile_write(struct file *filp) static int f2fs_ioc_release_volatile_write(struct file *filp) { struct inode *inode = file_inode(filp); int ret; + if (!(filp->f_mode & FMODE_WRITE)) + return -EBADF; + if (!inode_owner_or_capable(inode)) return -EACCES; ret = mnt_want_write_file(filp); if (ret) @@ -2027,10 +2039,13 @@ static int f2fs_ioc_release_volatile_write(struct file *filp) static int f2fs_ioc_abort_volatile_write(struct file *filp) { struct inode *inode = file_inode(filp); int ret; + if (!(filp->f_mode & FMODE_WRITE)) + return -EBADF; + if (!inode_owner_or_capable(inode)) return -EACCES; ret = mnt_want_write_file(filp); if (ret) base-commit: 661f109c057497c8baf507a2562ceb9f9fb3cbc2 -- 2.47.0.rc0.187.ge670bccf7e-goog

7 months, 1 week

1
0
0 0

[PATCH 5.10] f2fs: Require FMODE_WRITE for atomic write ioctls

by Eric Biggers

From: Jann Horn <jannh(a)google.com> commit 4f5a100f87f32cb65d4bb1ad282a08c92f6f591e upstream. The F2FS ioctls for starting and committing atomic writes check for inode_owner_or_capable(), but this does not give LSMs like SELinux or Landlock an opportunity to deny the write access - if the caller's FSUID matches the inode's UID, inode_owner_or_capable() immediately returns true. There are scenarios where LSMs want to deny a process the ability to write particular files, even files that the FSUID of the process owns; but this can currently partially be bypassed using atomic write ioctls in two ways: - F2FS_IOC_START_ATOMIC_REPLACE + F2FS_IOC_COMMIT_ATOMIC_WRITE can truncate an inode to size 0 - F2FS_IOC_START_ATOMIC_WRITE + F2FS_IOC_ABORT_ATOMIC_WRITE can revert changes another process concurrently made to a file Fix it by requiring FMODE_WRITE for these operations, just like for F2FS_IOC_MOVE_RANGE. Since any legitimate caller should only be using these ioctls when intending to write into the file, that seems unlikely to break anything. Fixes: 88b88a667971 ("f2fs: support atomic writes") Cc: stable(a)vger.kernel.org Signed-off-by: Jann Horn <jannh(a)google.com> Reviewed-by: Chao Yu <chao(a)kernel.org> Reviewed-by: Eric Biggers <ebiggers(a)google.com> Signed-off-by: Jaegeuk Kim <jaegeuk(a)kernel.org> Signed-off-by: Eric Biggers <ebiggers(a)google.com> --- fs/f2fs/file.c | 15 +++++++++++++++ 1 file changed, 15 insertions(+) diff --git a/fs/f2fs/file.c b/fs/f2fs/file.c index 50514962771a1..e25788e643bbd 100644 --- a/fs/f2fs/file.c +++ b/fs/f2fs/file.c @@ -2047,10 +2047,13 @@ static int f2fs_ioc_start_atomic_write(struct file *filp) struct inode *inode = file_inode(filp); struct f2fs_inode_info *fi = F2FS_I(inode); struct f2fs_sb_info *sbi = F2FS_I_SB(inode); int ret; + if (!(filp->f_mode & FMODE_WRITE)) + return -EBADF; + if (!inode_owner_or_capable(inode)) return -EACCES; if (!S_ISREG(inode->i_mode)) return -EINVAL; @@ -2117,10 +2120,13 @@ static int f2fs_ioc_start_atomic_write(struct file *filp) static int f2fs_ioc_commit_atomic_write(struct file *filp) { struct inode *inode = file_inode(filp); int ret; + if (!(filp->f_mode & FMODE_WRITE)) + return -EBADF; + if (!inode_owner_or_capable(inode)) return -EACCES; ret = mnt_want_write_file(filp); if (ret) @@ -2159,10 +2165,13 @@ static int f2fs_ioc_commit_atomic_write(struct file *filp) static int f2fs_ioc_start_volatile_write(struct file *filp) { struct inode *inode = file_inode(filp); int ret; + if (!(filp->f_mode & FMODE_WRITE)) + return -EBADF; + if (!inode_owner_or_capable(inode)) return -EACCES; if (!S_ISREG(inode->i_mode)) return -EINVAL; @@ -2194,10 +2203,13 @@ static int f2fs_ioc_start_volatile_write(struct file *filp) static int f2fs_ioc_release_volatile_write(struct file *filp) { struct inode *inode = file_inode(filp); int ret; + if (!(filp->f_mode & FMODE_WRITE)) + return -EBADF; + if (!inode_owner_or_capable(inode)) return -EACCES; ret = mnt_want_write_file(filp); if (ret) @@ -2223,10 +2235,13 @@ static int f2fs_ioc_release_volatile_write(struct file *filp) static int f2fs_ioc_abort_volatile_write(struct file *filp) { struct inode *inode = file_inode(filp); int ret; + if (!(filp->f_mode & FMODE_WRITE)) + return -EBADF; + if (!inode_owner_or_capable(inode)) return -EACCES; ret = mnt_want_write_file(filp); if (ret) base-commit: ceb091e2c4ccf93b1ee0e0e8a202476a433784ff -- 2.47.0.rc0.187.ge670bccf7e-goog

7 months, 1 week

1
0
0 0

[PATCH 5.15] f2fs: Require FMODE_WRITE for atomic write ioctls

by Eric Biggers

From: Jann Horn <jannh(a)google.com> commit 4f5a100f87f32cb65d4bb1ad282a08c92f6f591e upstream. The F2FS ioctls for starting and committing atomic writes check for inode_owner_or_capable(), but this does not give LSMs like SELinux or Landlock an opportunity to deny the write access - if the caller's FSUID matches the inode's UID, inode_owner_or_capable() immediately returns true. There are scenarios where LSMs want to deny a process the ability to write particular files, even files that the FSUID of the process owns; but this can currently partially be bypassed using atomic write ioctls in two ways: - F2FS_IOC_START_ATOMIC_REPLACE + F2FS_IOC_COMMIT_ATOMIC_WRITE can truncate an inode to size 0 - F2FS_IOC_START_ATOMIC_WRITE + F2FS_IOC_ABORT_ATOMIC_WRITE can revert changes another process concurrently made to a file Fix it by requiring FMODE_WRITE for these operations, just like for F2FS_IOC_MOVE_RANGE. Since any legitimate caller should only be using these ioctls when intending to write into the file, that seems unlikely to break anything. Fixes: 88b88a667971 ("f2fs: support atomic writes") Cc: stable(a)vger.kernel.org Signed-off-by: Jann Horn <jannh(a)google.com> Reviewed-by: Chao Yu <chao(a)kernel.org> Reviewed-by: Eric Biggers <ebiggers(a)google.com> Signed-off-by: Jaegeuk Kim <jaegeuk(a)kernel.org> Signed-off-by: Eric Biggers <ebiggers(a)google.com> --- fs/f2fs/file.c | 15 +++++++++++++++ 1 file changed, 15 insertions(+) diff --git a/fs/f2fs/file.c b/fs/f2fs/file.c index be9536815e50d..fd369db1e47b5 100644 --- a/fs/f2fs/file.c +++ b/fs/f2fs/file.c @@ -2005,10 +2005,13 @@ static int f2fs_ioc_start_atomic_write(struct file *filp) struct inode *inode = file_inode(filp); struct f2fs_inode_info *fi = F2FS_I(inode); struct f2fs_sb_info *sbi = F2FS_I_SB(inode); int ret; + if (!(filp->f_mode & FMODE_WRITE)) + return -EBADF; + if (!inode_owner_or_capable(&init_user_ns, inode)) return -EACCES; if (!S_ISREG(inode->i_mode)) return -EINVAL; @@ -2075,10 +2078,13 @@ static int f2fs_ioc_start_atomic_write(struct file *filp) static int f2fs_ioc_commit_atomic_write(struct file *filp) { struct inode *inode = file_inode(filp); int ret; + if (!(filp->f_mode & FMODE_WRITE)) + return -EBADF; + if (!inode_owner_or_capable(&init_user_ns, inode)) return -EACCES; ret = mnt_want_write_file(filp); if (ret) @@ -2117,10 +2123,13 @@ static int f2fs_ioc_commit_atomic_write(struct file *filp) static int f2fs_ioc_start_volatile_write(struct file *filp) { struct inode *inode = file_inode(filp); int ret; + if (!(filp->f_mode & FMODE_WRITE)) + return -EBADF; + if (!inode_owner_or_capable(&init_user_ns, inode)) return -EACCES; if (!S_ISREG(inode->i_mode)) return -EINVAL; @@ -2152,10 +2161,13 @@ static int f2fs_ioc_start_volatile_write(struct file *filp) static int f2fs_ioc_release_volatile_write(struct file *filp) { struct inode *inode = file_inode(filp); int ret; + if (!(filp->f_mode & FMODE_WRITE)) + return -EBADF; + if (!inode_owner_or_capable(&init_user_ns, inode)) return -EACCES; ret = mnt_want_write_file(filp); if (ret) @@ -2181,10 +2193,13 @@ static int f2fs_ioc_release_volatile_write(struct file *filp) static int f2fs_ioc_abort_volatile_write(struct file *filp) { struct inode *inode = file_inode(filp); int ret; + if (!(filp->f_mode & FMODE_WRITE)) + return -EBADF; + if (!inode_owner_or_capable(&init_user_ns, inode)) return -EACCES; ret = mnt_want_write_file(filp); if (ret) base-commit: 3a5928702e7120f83f703fd566082bfb59f1a57e -- 2.47.0.rc0.187.ge670bccf7e-goog

7 months, 1 week

1
0
0 0

[PATCH AUTOSEL 4.19 01/16] bpf: Check percpu map value size first

by Sasha Levin

From: Tao Chen <chen.dylane(a)gmail.com> [ Upstream commit 1d244784be6b01162b732a5a7d637dfc024c3203 ] Percpu map is often used, but the map value size limit often ignored, like issue: https://github.com/iovisor/bcc/issues/2519. Actually, percpu map value size is bound by PCPU_MIN_UNIT_SIZE, so we can check the value size whether it exceeds PCPU_MIN_UNIT_SIZE first, like percpu map of local_storage. Maybe the error message seems clearer compared with "cannot allocate memory". Signed-off-by: Jinke Han <jinkehan(a)didiglobal.com> Signed-off-by: Tao Chen <chen.dylane(a)gmail.com> Signed-off-by: Andrii Nakryiko <andrii(a)kernel.org> Acked-by: Jiri Olsa <jolsa(a)kernel.org> Acked-by: Andrii Nakryiko <andrii(a)kernel.org> Link: https://lore.kernel.org/bpf/20240910144111.1464912-2-chen.dylane@gmail.com Signed-off-by: Sasha Levin <sashal(a)kernel.org> --- kernel/bpf/arraymap.c | 3 +++ kernel/bpf/hashtab.c | 3 +++ 2 files changed, 6 insertions(+) diff --git a/kernel/bpf/arraymap.c b/kernel/bpf/arraymap.c index 44f53c06629e2..03e244b11f5a0 100644 --- a/kernel/bpf/arraymap.c +++ b/kernel/bpf/arraymap.c @@ -71,6 +71,9 @@ int array_map_alloc_check(union bpf_attr *attr) * access the elements. */ return -E2BIG; + /* percpu map value size is bound by PCPU_MIN_UNIT_SIZE */ + if (percpu && round_up(attr->value_size, 8) > PCPU_MIN_UNIT_SIZE) + return -E2BIG; return 0; } diff --git a/kernel/bpf/hashtab.c b/kernel/bpf/hashtab.c index 16081d8384bfc..bca3287030460 100644 --- a/kernel/bpf/hashtab.c +++ b/kernel/bpf/hashtab.c @@ -291,6 +291,9 @@ static int htab_map_alloc_check(union bpf_attr *attr) * kmalloc-able later in htab_map_update_elem() */ return -E2BIG; + /* percpu map value size is bound by PCPU_MIN_UNIT_SIZE */ + if (percpu && round_up(attr->value_size, 8) > PCPU_MIN_UNIT_SIZE) + return -E2BIG; return 0; } -- 2.43.0

7 months, 1 week

1
15
0 0

[PATCH AUTOSEL 5.4 01/21] bpf: Check percpu map value size first

by Sasha Levin

From: Tao Chen <chen.dylane(a)gmail.com> [ Upstream commit 1d244784be6b01162b732a5a7d637dfc024c3203 ] Percpu map is often used, but the map value size limit often ignored, like issue: https://github.com/iovisor/bcc/issues/2519. Actually, percpu map value size is bound by PCPU_MIN_UNIT_SIZE, so we can check the value size whether it exceeds PCPU_MIN_UNIT_SIZE first, like percpu map of local_storage. Maybe the error message seems clearer compared with "cannot allocate memory". Signed-off-by: Jinke Han <jinkehan(a)didiglobal.com> Signed-off-by: Tao Chen <chen.dylane(a)gmail.com> Signed-off-by: Andrii Nakryiko <andrii(a)kernel.org> Acked-by: Jiri Olsa <jolsa(a)kernel.org> Acked-by: Andrii Nakryiko <andrii(a)kernel.org> Link: https://lore.kernel.org/bpf/20240910144111.1464912-2-chen.dylane@gmail.com Signed-off-by: Sasha Levin <sashal(a)kernel.org> --- kernel/bpf/arraymap.c | 3 +++ kernel/bpf/hashtab.c | 3 +++ 2 files changed, 6 insertions(+) diff --git a/kernel/bpf/arraymap.c b/kernel/bpf/arraymap.c index 81ed9b79f4019..af90c4498e80e 100644 --- a/kernel/bpf/arraymap.c +++ b/kernel/bpf/arraymap.c @@ -64,6 +64,9 @@ int array_map_alloc_check(union bpf_attr *attr) * access the elements. */ return -E2BIG; + /* percpu map value size is bound by PCPU_MIN_UNIT_SIZE */ + if (percpu && round_up(attr->value_size, 8) > PCPU_MIN_UNIT_SIZE) + return -E2BIG; return 0; } diff --git a/kernel/bpf/hashtab.c b/kernel/bpf/hashtab.c index 34c4f709b1ede..0d14a2a11463a 100644 --- a/kernel/bpf/hashtab.c +++ b/kernel/bpf/hashtab.c @@ -288,6 +288,9 @@ static int htab_map_alloc_check(union bpf_attr *attr) * kmalloc-able later in htab_map_update_elem() */ return -E2BIG; + /* percpu map value size is bound by PCPU_MIN_UNIT_SIZE */ + if (percpu && round_up(attr->value_size, 8) > PCPU_MIN_UNIT_SIZE) + return -E2BIG; return 0; } -- 2.43.0

7 months, 1 week

1
20
0 0

[PATCH AUTOSEL 5.10 01/26] bpf: Check percpu map value size first

by Sasha Levin

From: Tao Chen <chen.dylane(a)gmail.com> [ Upstream commit 1d244784be6b01162b732a5a7d637dfc024c3203 ] Percpu map is often used, but the map value size limit often ignored, like issue: https://github.com/iovisor/bcc/issues/2519. Actually, percpu map value size is bound by PCPU_MIN_UNIT_SIZE, so we can check the value size whether it exceeds PCPU_MIN_UNIT_SIZE first, like percpu map of local_storage. Maybe the error message seems clearer compared with "cannot allocate memory". Signed-off-by: Jinke Han <jinkehan(a)didiglobal.com> Signed-off-by: Tao Chen <chen.dylane(a)gmail.com> Signed-off-by: Andrii Nakryiko <andrii(a)kernel.org> Acked-by: Jiri Olsa <jolsa(a)kernel.org> Acked-by: Andrii Nakryiko <andrii(a)kernel.org> Link: https://lore.kernel.org/bpf/20240910144111.1464912-2-chen.dylane@gmail.com Signed-off-by: Sasha Levin <sashal(a)kernel.org> --- kernel/bpf/arraymap.c | 3 +++ kernel/bpf/hashtab.c | 3 +++ 2 files changed, 6 insertions(+) diff --git a/kernel/bpf/arraymap.c b/kernel/bpf/arraymap.c index 5102338129d5f..3d92e42c3895a 100644 --- a/kernel/bpf/arraymap.c +++ b/kernel/bpf/arraymap.c @@ -74,6 +74,9 @@ int array_map_alloc_check(union bpf_attr *attr) * access the elements. */ return -E2BIG; + /* percpu map value size is bound by PCPU_MIN_UNIT_SIZE */ + if (percpu && round_up(attr->value_size, 8) > PCPU_MIN_UNIT_SIZE) + return -E2BIG; return 0; } diff --git a/kernel/bpf/hashtab.c b/kernel/bpf/hashtab.c index 72bc5f5752543..4c7cab79d90e5 100644 --- a/kernel/bpf/hashtab.c +++ b/kernel/bpf/hashtab.c @@ -404,6 +404,9 @@ static int htab_map_alloc_check(union bpf_attr *attr) * kmalloc-able later in htab_map_update_elem() */ return -E2BIG; + /* percpu map value size is bound by PCPU_MIN_UNIT_SIZE */ + if (percpu && round_up(attr->value_size, 8) > PCPU_MIN_UNIT_SIZE) + return -E2BIG; return 0; } -- 2.43.0

7 months, 1 week

1
25
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror October 2024