linux-ntfs-dev — Development discussions and bug reports.

[Linux-NTFS-Dev] [PATCH AUTOSEL 5.16 20/20] ntfs: add sanity check on allocation size

[Sasha L. <sa...@ke...>]

From: Dongliang Mu <mud...@gm...>

[ Upstream commit 714fbf2647b1a33d914edd695d4da92029c7e7c0 ]

ntfs_read_inode_mount invokes ntfs_malloc_nofs with zero allocation
size.  It triggers one BUG in the __ntfs_malloc function.

Fix this by adding sanity check on ni->attr_list_size.

Link: https://lkml.kernel.org/r/202...@hu...
Reported-by: syz...@sy...
Signed-off-by: Dongliang Mu <mud...@gm...>
Acked-by: Anton Altaparmakov <an...@tu...>
Signed-off-by: Andrew Morton <ak...@li...>
Signed-off-by: Linus Torvalds <tor...@li...>
Signed-off-by: Sasha Levin <sa...@ke...>
---
 fs/ntfs/inode.c | 4 ++++
 1 file changed, 4 insertions(+)

diff --git a/fs/ntfs/inode.c b/fs/ntfs/inode.c
index 4474adb393ca..517b71c73aa9 100644
--- a/fs/ntfs/inode.c
+++ b/fs/ntfs/inode.c
@@ -1881,6 +1881,10 @@ int ntfs_read_inode_mount(struct inode *vi)
 		}
 		/* Now allocate memory for the attribute list. */
 		ni->attr_list_size = (u32)ntfs_attr_size(a);
+		if (!ni->attr_list_size) {
+			ntfs_error(sb, "Attr_list_size is zero");
+			goto put_err_out;
+		}
 		ni->attr_list = ntfs_malloc_nofs(ni->attr_list_size);
 		if (!ni->attr_list) {
 			ntfs_error(sb, "Not enough memory to allocate buffer "
-- 
2.34.1

[Linux-NTFS-Dev] [PATCH AUTOSEL 5.17 21/21] ntfs: add sanity check on allocation size

[Sasha L. <sa...@ke...>]

From: Dongliang Mu <mud...@gm...>

[ Upstream commit 714fbf2647b1a33d914edd695d4da92029c7e7c0 ]

ntfs_read_inode_mount invokes ntfs_malloc_nofs with zero allocation
size.  It triggers one BUG in the __ntfs_malloc function.

Fix this by adding sanity check on ni->attr_list_size.

Link: https://lkml.kernel.org/r/202...@hu...
Reported-by: syz...@sy...
Signed-off-by: Dongliang Mu <mud...@gm...>
Acked-by: Anton Altaparmakov <an...@tu...>
Signed-off-by: Andrew Morton <ak...@li...>
Signed-off-by: Linus Torvalds <tor...@li...>
Signed-off-by: Sasha Levin <sa...@ke...>
---
 fs/ntfs/inode.c | 4 ++++
 1 file changed, 4 insertions(+)

diff --git a/fs/ntfs/inode.c b/fs/ntfs/inode.c
index 4474adb393ca..517b71c73aa9 100644
--- a/fs/ntfs/inode.c
+++ b/fs/ntfs/inode.c
@@ -1881,6 +1881,10 @@ int ntfs_read_inode_mount(struct inode *vi)
 		}
 		/* Now allocate memory for the attribute list. */
 		ni->attr_list_size = (u32)ntfs_attr_size(a);
+		if (!ni->attr_list_size) {
+			ntfs_error(sb, "Attr_list_size is zero");
+			goto put_err_out;
+		}
 		ni->attr_list = ntfs_malloc_nofs(ni->attr_list_size);
 		if (!ni->attr_list) {
 			ntfs_error(sb, "Not enough memory to allocate buffer "
-- 
2.34.1

[Linux-NTFS-Dev] [PATCH] fs/ntfs: fix comments mentioning i_mutex

[Hongnan Li <hon...@li...>]

From: hongnanli <hon...@li...>

inode->i_mutex has been replaced with inode->i_rwsem long ago. Fix
comments still mentioning i_mutex.

Signed-off-by: hongnanli <hon...@li...>
---
 fs/ntfs/attrib.c |  4 ++--
 fs/ntfs/dir.c    |  8 ++++----
 fs/ntfs/file.c   | 10 +++++-----
 fs/ntfs/index.c  |  6 +++---
 fs/ntfs/inode.c  |  4 ++--
 fs/ntfs/namei.c  |  4 ++--
 6 files changed, 18 insertions(+), 18 deletions(-)

diff --git a/fs/ntfs/attrib.c b/fs/ntfs/attrib.c
index 2911c04a33e0..fc2cb551265b 100644
--- a/fs/ntfs/attrib.c
+++ b/fs/ntfs/attrib.c
@@ -1516,7 +1516,7 @@ int ntfs_resident_attr_value_resize(MFT_RECORD *m, ATTR_RECORD *a,
  * NOTE to self: No changes in the attribute list are required to move from
  *		 a resident to a non-resident attribute.
  *
- * Locking: - The caller must hold i_mutex on the inode.
+ * Locking: - The caller must hold i_rwsem on the inode.
  */
 int ntfs_attr_make_non_resident(ntfs_inode *ni, const u32 data_size)
 {
@@ -1721,7 +1721,7 @@ int ntfs_attr_make_non_resident(ntfs_inode *ni, const u32 data_size)
 	/*
 	 * This needs to be last since the address space operations ->readpage
 	 * and ->writepage can run concurrently with us as they are not
-	 * serialized on i_mutex.  Note, we are not allowed to fail once we flip
+	 * serialized on i_rwsem.  Note, we are not allowed to fail once we flip
 	 * this switch, which is another reason to do this last.
 	 */
 	NInoSetNonResident(ni);
diff --git a/fs/ntfs/dir.c b/fs/ntfs/dir.c
index cd96083a12c8..26ac22528bd8 100644
--- a/fs/ntfs/dir.c
+++ b/fs/ntfs/dir.c
@@ -56,7 +56,7 @@ ntfschar I30[5] = { cpu_to_le16('$'), cpu_to_le16('I'),
  * work but we don't care for how quickly one can access them. This also fixes
  * the dcache aliasing issues.
  *
- * Locking:  - Caller must hold i_mutex on the directory.
+ * Locking:  - Caller must hold i_rwsem on the directory.
  *	     - Each page cache page in the index allocation mapping must be
  *	       locked whilst being accessed otherwise we may find a corrupt
  *	       page due to it being under ->writepage at the moment which
@@ -1071,11 +1071,11 @@ static inline int ntfs_filldir(ntfs_volume *vol,
  * While this will return the names in random order this doesn't matter for
  * ->readdir but OTOH results in a faster ->readdir.
  *
- * VFS calls ->readdir without BKL but with i_mutex held. This protects the VFS
+ * VFS calls ->readdir without BKL but with i_rwsem held. This protects the VFS
  * parts (e.g. ->f_pos and ->i_size, and it also protects against directory
  * modifications).
  *
- * Locking:  - Caller must hold i_mutex on the directory.
+ * Locking:  - Caller must hold i_rwsem on the directory.
  *	     - Each page cache page in the index allocation mapping must be
  *	       locked whilst being accessed otherwise we may find a corrupt
  *	       page due to it being under ->writepage at the moment which
@@ -1477,7 +1477,7 @@ static int ntfs_dir_open(struct inode *vi, struct file *filp)
  * Note: In the past @filp could be NULL so we ignore it as we don't need it
  * anyway.
  *
- * Locking: Caller must hold i_mutex on the inode.
+ * Locking: Caller must hold i_rwsem on the inode.
  *
  * TODO: We should probably also write all attribute/index inodes associated
  * with this inode but since we have no simple way of getting to them we ignore
diff --git a/fs/ntfs/file.c b/fs/ntfs/file.c
index 2ae25e48a41a..82cba5c967fe 100644
--- a/fs/ntfs/file.c
+++ b/fs/ntfs/file.c
@@ -90,7 +90,7 @@ static int ntfs_file_open(struct inode *vi, struct file *filp)
  * this is the case, the necessary zeroing will also have happened and that all
  * metadata is self-consistent.
  *
- * Locking: i_mutex on the vfs inode corrseponsind to the ntfs inode @ni must be
+ * Locking: i_rwsem on the vfs inode corrseponsind to the ntfs inode @ni must be
  *	    held by the caller.
  */
 static int ntfs_attr_extend_initialized(ntfs_inode *ni, const s64 new_init_size)
@@ -458,7 +458,7 @@ static ssize_t ntfs_prepare_file_for_write(struct kiocb *iocb,
 	if (pos > ll) {
 		/*
 		 * Wait for ongoing direct i/o to complete before proceeding.
-		 * New direct i/o cannot start as we hold i_mutex.
+		 * New direct i/o cannot start as we hold i_rwsem.
 		 */
 		inode_dio_wait(vi);
 		err = ntfs_attr_extend_initialized(ni, pos);
@@ -548,7 +548,7 @@ static inline int ntfs_submit_bh_for_read(struct buffer_head *bh)
  * @bytes:	number of bytes to be written
  *
  * This is called for non-resident attributes from ntfs_file_buffered_write()
- * with i_mutex held on the inode (@pages[0]->mapping->host).  There are
+ * with i_rwsem held on the inode (@pages[0]->mapping->host).  There are
  * @nr_pages pages in @pages which are locked but not kmap()ped.  The source
  * data has not yet been copied into the @pages.
  * 
@@ -1505,7 +1505,7 @@ static inline int ntfs_commit_pages_after_non_resident_write(
  * @pos:	byte position in file at which the write begins
  * @bytes:	number of bytes to be written
  *
- * This is called from ntfs_file_buffered_write() with i_mutex held on the inode
+ * This is called from ntfs_file_buffered_write() with i_rwsem held on the inode
  * (@pages[0]->mapping->host).  There are @nr_pages pages in @pages which are
  * locked but not kmap()ped.  The source data has already been copied into the
  * @page.  ntfs_prepare_pages_for_non_resident_write() has been called before
@@ -1946,7 +1946,7 @@ static ssize_t ntfs_file_write_iter(struct kiocb *iocb, struct iov_iter *from)
  * Also, if @datasync is true, we do not wait on the inode to be written out
  * but we always wait on the page cache pages to be written out.
  *
- * Locking: Caller must hold i_mutex on the inode.
+ * Locking: Caller must hold i_rwsem on the inode.
  *
  * TODO: We should probably also write all attribute/index inodes associated
  * with this inode but since we have no simple way of getting to them we ignore
diff --git a/fs/ntfs/index.c b/fs/ntfs/index.c
index d46c2c03a032..170eec12d83e 100644
--- a/fs/ntfs/index.c
+++ b/fs/ntfs/index.c
@@ -20,7 +20,7 @@
  * Allocate a new index context, initialize it with @idx_ni and return it.
  * Return NULL if allocation failed.
  *
- * Locking:  Caller must hold i_mutex on the index inode.
+ * Locking:  Caller must hold i_rwsem on the index inode.
  */
 ntfs_index_context *ntfs_index_ctx_get(ntfs_inode *idx_ni)
 {
@@ -38,7 +38,7 @@ ntfs_index_context *ntfs_index_ctx_get(ntfs_inode *idx_ni)
  *
  * Release the index context @ictx, releasing all associated resources.
  *
- * Locking:  Caller must hold i_mutex on the index inode.
+ * Locking:  Caller must hold i_rwsem on the index inode.
  */
 void ntfs_index_ctx_put(ntfs_index_context *ictx)
 {
@@ -94,7 +94,7 @@ void ntfs_index_ctx_put(ntfs_index_context *ictx)
  * or ntfs_index_entry_write() before the call to ntfs_index_ctx_put() to
  * ensure that the changes are written to disk.
  *
- * Locking:  - Caller must hold i_mutex on the index inode.
+ * Locking:  - Caller must hold i_rwsem on the index inode.
  *	     - Each page cache page in the index allocation mapping must be
  *	       locked whilst being accessed otherwise we may find a corrupt
  *	       page due to it being under ->writepage at the moment which
diff --git a/fs/ntfs/inode.c b/fs/ntfs/inode.c
index 4474adb393ca..f1f76c7f2984 100644
--- a/fs/ntfs/inode.c
+++ b/fs/ntfs/inode.c
@@ -2339,7 +2339,7 @@ static const char *es = "  Leaving inconsistent metadata.  Unmount and run "
  *
  * Returns 0 on success or -errno on error.
  *
- * Called with ->i_mutex held.
+ * Called with ->i_rwsem held.
  */
 int ntfs_truncate(struct inode *vi)
 {
@@ -2865,7 +2865,7 @@ void ntfs_truncate_vfs(struct inode *vi) {
  * We also abort all changes of user, group, and mode as we do not implement
  * the NTFS ACLs yet.
  *
- * Called with ->i_mutex held.
+ * Called with ->i_rwsem held.
  */
 int ntfs_setattr(struct user_namespace *mnt_userns, struct dentry *dentry,
 		 struct iattr *attr)
diff --git a/fs/ntfs/namei.c b/fs/ntfs/namei.c
index 4e6a44bc654c..9e66805f3640 100644
--- a/fs/ntfs/namei.c
+++ b/fs/ntfs/namei.c
@@ -84,7 +84,7 @@
  *    name. We then convert the name to the current NLS code page, and proceed
  *    searching for a dentry with this name, etc, as in case 2), above.
  *
- * Locking: Caller must hold i_mutex on the directory.
+ * Locking: Caller must hold i_rwsem on the directory.
  */
 static struct dentry *ntfs_lookup(struct inode *dir_ino, struct dentry *dent,
 		unsigned int flags)
@@ -278,7 +278,7 @@ const struct inode_operations ntfs_dir_inode_ops = {
  * The code is based on the ext3 ->get_parent() implementation found in
  * fs/ext3/namei.c::ext3_get_parent().
  *
- * Note: ntfs_get_parent() is called with @d_inode(child_dent)->i_mutex down.
+ * Note: ntfs_get_parent() is called with @d_inode(child_dent)->i_rwsem down.
  *
  * Return the dentry of the parent directory on success or the error code on
  * error (IS_ERR() is true).
-- 
2.19.1.6.gb485710b

Re: [Linux-NTFS-Dev] [PATCH] ntfs: add sanity check on allocation size

[Anton A. <an...@tu...>]

Hi Andrew,

Please could you merge this?  Thanks a lot in advance!

Dongliang, that looks good, thanks!

Best regards,

Anton

On 20 Jan 2022, at 09:49, Dongliang Mu <dz...@hu...<mailto:dz...@hu...>> wrote:

From: Dongliang Mu <mud...@gm...<mailto:mud...@gm...>>

ntfs_read_inode_mount invokes ntfs_malloc_nofs with zero allocation size. It triggers one BUG in the __ntfs_malloc function.

Fix this by adding sanity check on ni->attr_list_size.

Reported-by: syz...@sy...<mailto:syz...@sy...>
Signed-off-by: Dongliang Mu <mud...@gm...<mailto:mud...@gm...>>
Acked-by: Anton Altaparmakov <an...@tu...<mailto:an...@tu...>>
---
fs/ntfs/inode.c | 4 ++++
1 file changed, 4 insertions(+)

diff --git a/fs/ntfs/inode.c b/fs/ntfs/inode.c
index 4474adb393ca..517b71c73aa9 100644
--- a/fs/ntfs/inode.c
+++ b/fs/ntfs/inode.c
@@ -1881,6 +1881,10 @@ int ntfs_read_inode_mount(struct inode *vi)
}
/* Now allocate memory for the attribute list. */
ni->attr_list_size = (u32)ntfs_attr_size(a);
+ if (!ni->attr_list_size) {
+ ntfs_error(sb, "Attr_list_size is zero");
+ goto put_err_out;
+ }
ni->attr_list = ntfs_malloc_nofs(ni->attr_list_size);
if (!ni->attr_list) {
ntfs_error(sb, "Not enough memory to allocate buffer "
--
2.25.1


--
Anton Altaparmakov <anton at tuxera.com<http://tuxera.com>> (replace at with @)
Lead in File System Development, Tuxera Inc., http://www.tuxera.com/
Linux NTFS maintainer

[Linux-NTFS-Dev] [PATCH] ntfs: add sanity check on allocation size

[Dongliang Mu <dz...@hu...>]

From: Dongliang Mu <mud...@gm...>

ntfs_read_inode_mount invokes ntfs_malloc_nofs with zero allocation size. It triggers one BUG in the __ntfs_malloc function.

Fix this by adding sanity check on ni->attr_list_size.

Reported-by: syz...@sy...
Signed-off-by: Dongliang Mu <mud...@gm...>
---
 fs/ntfs/inode.c | 4 ++++
 1 file changed, 4 insertions(+)

diff --git a/fs/ntfs/inode.c b/fs/ntfs/inode.c
index 4474adb393ca..517b71c73aa9 100644
--- a/fs/ntfs/inode.c
+++ b/fs/ntfs/inode.c
@@ -1881,6 +1881,10 @@ int ntfs_read_inode_mount(struct inode *vi)
 		}
 		/* Now allocate memory for the attribute list. */
 		ni->attr_list_size = (u32)ntfs_attr_size(a);
+		if (!ni->attr_list_size) {
+			ntfs_error(sb, "Attr_list_size is zero");
+			goto put_err_out;
+		}
 		ni->attr_list = ntfs_malloc_nofs(ni->attr_list_size);
 		if (!ni->attr_list) {
 			ntfs_error(sb, "Not enough memory to allocate buffer "
-- 
2.25.1

Re: [Linux-NTFS-Dev] [syzbot] kernel BUG in ntfs_read_inode_mount

[Pavel S. <pas...@gm...>]

On 1/17/22 22:02, Pavel Skripkin wrote:
> On 1/17/22 13:09, syzbot wrote:
>> Hello,
>> 
>> syzbot found the following issue on:
>> 
>> HEAD commit:    d0a231f01e5b Merge tag 'pci-v5.17-changes' of git://git.ke..
>> git tree:       upstream
>> console output: https://syzkaller.appspot.com/x/log.txt?x=11f83837b00000
>> kernel config:  https://syzkaller.appspot.com/x/.config?x=986ed422f1741853
>> dashboard link: https://syzkaller.appspot.com/bug?extid=3c765c5248797356edaa
>> compiler:       gcc (Debian 10.2.1-6) 10.2.1 20210110, GNU ld (GNU Binutils for Debian) 2.35.2
>> 
>> Unfortunately, I don't have any reproducer for this issue yet.
>> 
> 
> Sad :(
> 
>> IMPORTANT: if you fix the issue, please add the following tag to the commit:
>> Reported-by: syz...@sy...
>> 
> 
> __ntfs_malloc() calls BUG_ON() in case of requested size is equal to
> zero. Seems like syzbot has once again crafted malicious fs image that
> has attr_list_size == 0
> 
> Just for thoughts
> 
> 

Clicked 'Send' button too early, sorry

With regards,
Pavel Skripkin

Re: [Linux-NTFS-Dev] [syzbot] kernel BUG in ntfs_read_inode_mount

[Pavel S. <pas...@gm...>]

On 1/17/22 13:09, syzbot wrote:
> Hello,
> 
> syzbot found the following issue on:
> 
> HEAD commit:    d0a231f01e5b Merge tag 'pci-v5.17-changes' of git://git.ke..
> git tree:       upstream
> console output: https://syzkaller.appspot.com/x/log.txt?x=11f83837b00000
> kernel config:  https://syzkaller.appspot.com/x/.config?x=986ed422f1741853
> dashboard link: https://syzkaller.appspot.com/bug?extid=3c765c5248797356edaa
> compiler:       gcc (Debian 10.2.1-6) 10.2.1 20210110, GNU ld (GNU Binutils for Debian) 2.35.2
> 
> Unfortunately, I don't have any reproducer for this issue yet.
> 

Sad :(

> IMPORTANT: if you fix the issue, please add the following tag to the commit:
> Reported-by: syz...@sy...
> 

__ntfs_malloc() calls BUG_ON() in case of requested size is equal to 
zero. Seems like syzbot has once again crafted malicious fs image that 
has attr_list_size == 0

Just for thoughts


With regards,
Pavel Skripkin

[Linux-NTFS-Dev] [syzbot] kernel BUG in ntfs_read_inode_mount

[syzbot <syz...@sy...>]

Hello,

syzbot found the following issue on:

HEAD commit:    d0a231f01e5b Merge tag 'pci-v5.17-changes' of git://git.ke..
git tree:       upstream
console output: https://syzkaller.appspot.com/x/log.txt?x=11f83837b00000
kernel config:  https://syzkaller.appspot.com/x/.config?x=986ed422f1741853
dashboard link: https://syzkaller.appspot.com/bug?extid=3c765c5248797356edaa
compiler:       gcc (Debian 10.2.1-6) 10.2.1 20210110, GNU ld (GNU Binutils for Debian) 2.35.2

Unfortunately, I don't have any reproducer for this issue yet.

IMPORTANT: if you fix the issue, please add the following tag to the commit:
Reported-by: syz...@sy...

------------[ cut here ]------------
kernel BUG at fs/ntfs/malloc.h:31!
invalid opcode: 0000 [#1] PREEMPT SMP KASAN
CPU: 0 PID: 13085 Comm: syz-executor.4 Not tainted 5.16.0-syzkaller #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
RIP: 0010:__ntfs_malloc fs/ntfs/malloc.h:31 [inline]
RIP: 0010:ntfs_malloc_nofs fs/ntfs/malloc.h:52 [inline]
RIP: 0010:ntfs_read_inode_mount+0x1df3/0x2490 fs/ntfs/inode.c:1884
Code: 24 30 48 39 c3 0f 83 e2 01 00 00 e8 87 85 e5 fe 48 89 ef be 42 0c 00 00 e8 ba c9 21 ff 48 89 c5 e9 59 f4 ff ff e8 6d 85 e5 fe <0f> 0b 4c 8b 7c 24 30 e8 61 85 e5 fe 48 c7 c2 c0 b3 df 89 48 c7 c7
RSP: 0018:ffffc90003a37a80 EFLAGS: 00010212
RAX: 0000000000003063 RBX: 0000000000000000 RCX: ffffc9000fc69000
RDX: 0000000000040000 RSI: ffffffff82924583 RDI: 0000000000000003
RBP: 0000000000000000 R08: 0000000000000000 R09: 0000000000000000
R10: ffffffff82923991 R11: 0000000000000000 R12: ffff88807d0f4038
R13: ffff88807d0f4040 R14: ffff888071f5f6a0 R15: ffff88801e2ca000
FS:  00007f29a2160700(0000) GS:ffff8880b9c00000(0000) knlGS:0000000000000000
CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 0000555555c25708 CR3: 00000000793be000 CR4: 0000000000350ef0
Call Trace:
 <TASK>
 ntfs_fill_super+0xa2f/0x8440 fs/ntfs/super.c:2854
 mount_bdev+0x34d/0x410 fs/super.c:1370
 legacy_get_tree+0x105/0x220 fs/fs_context.c:610
 vfs_get_tree+0x89/0x2f0 fs/super.c:1500
 do_new_mount fs/namespace.c:2994 [inline]
 path_mount+0x1320/0x1fa0 fs/namespace.c:3324
 do_mount fs/namespace.c:3337 [inline]
 __do_sys_mount fs/namespace.c:3545 [inline]
 __se_sys_mount fs/namespace.c:3522 [inline]
 __x64_sys_mount+0x27f/0x300 fs/namespace.c:3522
 do_syscall_x64 arch/x86/entry/common.c:50 [inline]
 do_syscall_64+0x35/0xb0 arch/x86/entry/common.c:80
 entry_SYSCALL_64_after_hwframe+0x44/0xae
RIP: 0033:0x7f29a37ec51a
Code: 48 c7 c2 bc ff ff ff f7 d8 64 89 02 b8 ff ff ff ff eb d2 e8 b8 04 00 00 0f 1f 84 00 00 00 00 00 49 89 ca b8 a5 00 00 00 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 bc ff ff ff f7 d8 64 89 01 48
RSP: 002b:00007f29a215ff88 EFLAGS: 00000206 ORIG_RAX: 00000000000000a5
RAX: ffffffffffffffda RBX: 0000000020000200 RCX: 00007f29a37ec51a
RDX: 0000000020000000 RSI: 0000000020000100 RDI: 00007f29a215ffe0
RBP: 00007f29a2160020 R08: 00007f29a2160020 R09: 0000000020000000
R10: 0000000000000000 R11: 0000000000000206 R12: 0000000020000000
R13: 0000000020000100 R14: 00007f29a215ffe0 R15: 000000002007dd00
 </TASK>
Modules linked in:
---[ end trace 20309b23609f3571 ]---
RIP: 0010:__ntfs_malloc fs/ntfs/malloc.h:31 [inline]
RIP: 0010:ntfs_malloc_nofs fs/ntfs/malloc.h:52 [inline]
RIP: 0010:ntfs_read_inode_mount+0x1df3/0x2490 fs/ntfs/inode.c:1884
Code: 24 30 48 39 c3 0f 83 e2 01 00 00 e8 87 85 e5 fe 48 89 ef be 42 0c 00 00 e8 ba c9 21 ff 48 89 c5 e9 59 f4 ff ff e8 6d 85 e5 fe <0f> 0b 4c 8b 7c 24 30 e8 61 85 e5 fe 48 c7 c2 c0 b3 df 89 48 c7 c7
RSP: 0018:ffffc90003a37a80 EFLAGS: 00010212
RAX: 0000000000003063 RBX: 0000000000000000 RCX: ffffc9000fc69000
RDX: 0000000000040000 RSI: ffffffff82924583 RDI: 0000000000000003
RBP: 0000000000000000 R08: 0000000000000000 R09: 0000000000000000
R10: ffffffff82923991 R11: 0000000000000000 R12: ffff88807d0f4038
R13: ffff88807d0f4040 R14: ffff888071f5f6a0 R15: ffff88801e2ca000
FS:  00007f29a2160700(0000) GS:ffff8880b9d00000(0000) knlGS:0000000000000000
CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00007f8b9a64ffc8 CR3: 00000000793be000 CR4: 0000000000350ee0


---
This report is generated by a bot. It may contain errors.
See https://goo.gl/tpsmEJ for more information about syzbot.
syzbot engineers can be reached at syz...@go....

syzbot will keep track of this issue. See:
https://goo.gl/tpsmEJ#status for how to communicate with syzbot.

Re: [Linux-NTFS-Dev] [PATCH -next] NTFS: Fix one kernel-doc comment

[Randy D. <rd...@in...>]

On 1/5/22 17:51, Yang Li wrote:
> /**
>  * attrib.c - NTFS attribute operations.  Part of the Linux-NTFS
> 
> The comments for the file should not be in kernel-doc format, which causes
> it to be incorrectly identified for function ntfs_map_runlist_nolock(),
> causing some warnings found by running scripts/kernel-doc.
> 
> fs/ntfs/attrib.c:25: warning: Incorrect use of kernel-doc format:  *
> ntfs_map_runlist_nolock - map (a part of) a runlist of an ntfs inode
> fs/ntfs/attrib.c:71: warning: Function parameter or member 'ni' not
> described in 'ntfs_map_runlist_nolock'
> fs/ntfs/attrib.c:71: warning: Function parameter or member 'vcn' not
> described in 'ntfs_map_runlist_nolock'
> fs/ntfs/attrib.c:71: warning: Function parameter or member 'ctx' not
> described in 'ntfs_map_runlist_nolock'
> fs/ntfs/attrib.c:71: warning: expecting prototype for attrib.c - NTFS
> attribute operations.  Part of the Linux(). Prototype was for
> ntfs_map_runlist_nolock() instead
> 
> Reported-by: Abaci Robot <ab...@li...>
> Signed-off-by: Yang Li <yan...@li...>

Acked-by: Randy Dunlap <rd...@in...>

Thanks.

[adding akpm]

> ---
>  fs/ntfs/attrib.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/fs/ntfs/attrib.c b/fs/ntfs/attrib.c
> index d563abc3e136..2911c04a33e0 100644
> --- a/fs/ntfs/attrib.c
> +++ b/fs/ntfs/attrib.c
> @@ -1,5 +1,5 @@
>  // SPDX-License-Identifier: GPL-2.0-or-later
> -/**
> +/*
>   * attrib.c - NTFS attribute operations.  Part of the Linux-NTFS project.
>   *
>   * Copyright (c) 2001-2012 Anton Altaparmakov and Tuxera Inc.

-- 
~Randy

[Linux-NTFS-Dev] [PATCH -next] NTFS: Fix one kernel-doc comment

[Yang Li <yan...@li...>]

/**
 * attrib.c - NTFS attribute operations.  Part of the Linux-NTFS

The comments for the file should not be in kernel-doc format, which causes
it to be incorrectly identified for function ntfs_map_runlist_nolock(),
causing some warnings found by running scripts/kernel-doc.

fs/ntfs/attrib.c:25: warning: Incorrect use of kernel-doc format:  *
ntfs_map_runlist_nolock - map (a part of) a runlist of an ntfs inode
fs/ntfs/attrib.c:71: warning: Function parameter or member 'ni' not
described in 'ntfs_map_runlist_nolock'
fs/ntfs/attrib.c:71: warning: Function parameter or member 'vcn' not
described in 'ntfs_map_runlist_nolock'
fs/ntfs/attrib.c:71: warning: Function parameter or member 'ctx' not
described in 'ntfs_map_runlist_nolock'
fs/ntfs/attrib.c:71: warning: expecting prototype for attrib.c - NTFS
attribute operations.  Part of the Linux(). Prototype was for
ntfs_map_runlist_nolock() instead

Reported-by: Abaci Robot <ab...@li...>
Signed-off-by: Yang Li <yan...@li...>
---
 fs/ntfs/attrib.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/fs/ntfs/attrib.c b/fs/ntfs/attrib.c
index d563abc3e136..2911c04a33e0 100644
--- a/fs/ntfs/attrib.c
+++ b/fs/ntfs/attrib.c
@@ -1,5 +1,5 @@
 // SPDX-License-Identifier: GPL-2.0-or-later
-/**
+/*
  * attrib.c - NTFS attribute operations.  Part of the Linux-NTFS project.
  *
  * Copyright (c) 2001-2012 Anton Altaparmakov and Tuxera Inc.
-- 
2.20.1.7.g153144c

[Linux-NTFS-Dev] [PATCH] ntfs: remove redundant variable idx

[Colin I. K. <col...@gm...>]

Variable idx is being assigned a value but it is never read. The
variable is redundant and can be removed.

Signed-off-by: Colin Ian King <col...@gm...>
---
 fs/ntfs/file.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/fs/ntfs/file.c b/fs/ntfs/file.c
index 2ae25e48a41a..329fca1fa619 100644
--- a/fs/ntfs/file.c
+++ b/fs/ntfs/file.c
@@ -1772,11 +1772,11 @@ static ssize_t ntfs_perform_write(struct file *file, struct iov_iter *i,
 	last_vcn = -1;
 	do {
 		VCN vcn;
-		pgoff_t idx, start_idx;
+		pgoff_t start_idx;
 		unsigned ofs, do_pages, u;
 		size_t copied;
 
-		start_idx = idx = pos >> PAGE_SHIFT;
+		start_idx = pos >> PAGE_SHIFT;
 		ofs = pos & ~PAGE_MASK;
 		bytes = PAGE_SIZE - ofs;
 		do_pages = 1;
-- 
2.33.1

Re: [Linux-NTFS-Dev] [PATCH v2 00/13] Unify asm/unaligned.h around struct helper

[Segher B. <se...@ke...>]

On Fri, Dec 17, 2021 at 12:34:53PM +0000, David Laight wrote:
> From: Segher Boessenkool
> > Sent: 16 December 2021 18:56
> ...
> > > The only remaining problem here is reinterpreting a char* pointer to a
> > > u32*, e.g., for accessing the IP address in an Ethernet frame when
> > > NET_IP_ALIGN == 2, which could suffer from the same UB problem again,
> > > as I understand it.
> > 
> > The problem is never casting a pointer to pointer to character type, and
> > then later back to an appriopriate pointer type.
> > These things are both required to work.
> 
> I think that is true of 'void *', not 'char *'.

No, see 6.3.2.3/7.  Both are allowed (and behave the same in fact).

> 'char' is special in that 'strict aliasing' doesn't apply to it.
> (Which is actually a pain sometimes.)

That has nothing to do with it.  Yes, you can validly access any memory
as a character type, but that has nothing to do with what pointer casts
are allowed and which are not.

> > The problem always is accessing something as if it
> > was something of another type, which is not valid C.  This however is
> > exactly what -fno-strict-aliasing allows, so that works as well.
> 
> IIRC the C language only allows you to have pointers to valid data items.
> (Since they can only be generated by the & operator on a valid item.)

Not so.  For example you are explicitly allowed to have pointers one
past the last element of an array (and do arithmetic on that!), and of
course null pointers are a thing.

C allows you to make up pointers from integers as well.  This is
perfectly fine to do.  Accessing anything via such pointers might well
be not standard C, of course.

> Indirecting any other pointer is probably UB!

If a pointer points to an object, indirecting it gives an lvalue of that
object.  It does not matter how you got that pointer, all that matters
is that it points at a valid object.

> This (sort of) allows the compiler to 'look through' casts to find
> what the actual type is (or might be).
> It can then use that information to make optimisation choices.
> This has caused grief with memcpy() calls that are trying to copy
> a structure that the coder knows is misaligned to an aligned buffer.

This is 6.5/7.

Alignment is 6.2.8 but it doesn't actually come into play at all here.

> So while *(unaligned_ptr *)char_ptr probably has to work.

Only if the original pointer points to an object that is correct
(including correctly aligned) for such an lvalue.

> If the compiler can see *(unaligned_ptr *)(char *)int_ptr it can
> assume the alignment of the 'int_ptr' and do a single aligned access.

It is undefined behaviour to have an address in int_ptr that is not
correctly aligned for whatever type it points to.


Segher

Re: [Linux-NTFS-Dev] [PATCH v2 00/13] Unify asm/unaligned.h around struct helper

[David L. <Dav...@AC...>]

From: Segher Boessenkool
> Sent: 16 December 2021 18:56
...
> > The only remaining problem here is reinterpreting a char* pointer to a
> > u32*, e.g., for accessing the IP address in an Ethernet frame when
> > NET_IP_ALIGN == 2, which could suffer from the same UB problem again,
> > as I understand it.
> 
> The problem is never casting a pointer to pointer to character type, and
> then later back to an appriopriate pointer type.
> These things are both required to work.

I think that is true of 'void *', not 'char *'.
'char' is special in that 'strict aliasing' doesn't apply to it.
(Which is actually a pain sometimes.)

> The problem always is accessing something as if it
> was something of another type, which is not valid C.  This however is
> exactly what -fno-strict-aliasing allows, so that works as well.

IIRC the C language only allows you to have pointers to valid data items.
(Since they can only be generated by the & operator on a valid item.)
Indirecting any other pointer is probably UB!

This (sort of) allows the compiler to 'look through' casts to find
what the actual type is (or might be).
It can then use that information to make optimisation choices.
This has caused grief with memcpy() calls that are trying to copy
a structure that the coder knows is misaligned to an aligned buffer.

So while *(unaligned_ptr *)char_ptr probably has to work.
If the compiler can see *(unaligned_ptr *)(char *)int_ptr it can
assume the alignment of the 'int_ptr' and do a single aligned access.

	David

-
Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK
Registration No: 1397386 (Wales)

Re: [Linux-NTFS-Dev] [PATCH v2 00/13] Unify asm/unaligned.h around struct helper

[Segher B. <se...@ke...>]

On Thu, Dec 16, 2021 at 06:29:40PM +0100, Ard Biesheuvel wrote:
> I think this series is a huge improvement, but it does not solve the
> UB problem completely. As we found, there are open issues in the GCC
> bugzilla regarding assumptions in the compiler that aligned quantities
> either overlap entirely or not at all. (e.g.,
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100363)

That isn't open, it was closed as INVALID back in May.

(Naturally) aligned quantities only overlap if they are the same datum.
This follows directly from the definition of (naturally) aligned.  There
is no mystery here.

All unaligned data need to be marked up properly.

> CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS is used in many places to
> conditionally emit code that violates C alignment rules.

Most of this is ABI, not C.  It is the ABI that requires certain
alignments.  Ignoring that plain does not work, but even if it would
you will end up with much slower generated code.

> whereas the following pattern makes more sense, I think, and does not
> violate any C rules in the common case:
> 
> #ifdef CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS
>   // use unaligned accessors, which are cheap or even entirely free
> #else
>   // avoid unaligned accessors, as they are expensive; instead, reorganize
>   // the data so we don't need them (similar to setting NET_IP_ALIGN to 2)
> #endif

Yes, this looks more reasonable.

> The only remaining problem here is reinterpreting a char* pointer to a
> u32*, e.g., for accessing the IP address in an Ethernet frame when
> NET_IP_ALIGN == 2, which could suffer from the same UB problem again,
> as I understand it.

The problem is never casting a pointer to pointer to character type, and
then later back to an appriopriate pointer type.  These things are both
required to work.  The problem always is accessing something as if it
was something of another type, which is not valid C.  This however is
exactly what -fno-strict-aliasing allows, so that works as well.

But this does not have much to do with alignment.


Segher

Re: [Linux-NTFS-Dev] [PATCH v2 00/13] Unify asm/unaligned.h around struct helper

[Linus T. <tor...@li...>]

On Thu, Dec 16, 2021 at 9:29 AM Ard Biesheuvel <ar...@ke...> wrote:
>
> CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS is used in many places to
> conditionally emit code that violates C alignment rules. E.g., there
> is this example in Documentation/core-api/unaligned-memory-access.rst:
>
> bool ether_addr_equal(const u8 *addr1, const u8 *addr2)
> {
> #ifdef CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS
>   u32 fold = ((*(const u32 *)addr1) ^ (*(const u32 *)addr2)) |
>              ((*(const u16 *)(addr1 + 4)) ^ (*(const u16 *)(addr2 + 4)));
>   return fold == 0;
> #else

It probably works fine in practice - the one case we had was really
pretty special, and about the vectorizer doing odd things.

But I think we should strive to convert these to use
"get_unaligned()", since code generation is fine. It still often makes
sense to have that test for the config variable, simply because the
approach might be different if we know unaligned accesses are slow.

So I'll happily take patches that do obvious conversions to
get_unaligned() where they make sense, but I don't think we should
consider this some huge hard requirement.

                 Linus

Re: [Linux-NTFS-Dev] [PATCH v2 00/13] Unify asm/unaligned.h around struct helper

[David L. <Dav...@AC...>]

From: Ard Biesheuvel
> Sent: 16 December 2021 17:30
> 
> Hi Arnd,
> 
> (replying to an old thread as this came up in the discussion regarding
> misaligned loads and stored in siphash() when compiled for ARM
> [f7e5b9bfa6c8820407b64eabc1f29c9a87e8993d])
> 
> On Fri, 14 May 2021 at 12:02, Arnd Bergmann <ar...@ke...> wrote:
> >
> > From: Arnd Bergmann <ar...@ar...>
> >
> > The get_unaligned()/put_unaligned() helpers are traditionally architecture
> > specific, with the two main variants being the "access-ok.h" version
> > that assumes unaligned pointer accesses always work on a particular
> > architecture, and the "le-struct.h" version that casts the data to a
> > byte aligned type before dereferencing, for architectures that cannot
> > always do unaligned accesses in hardware.

I'm pretty sure the compiler is allowed to 'read through' that cast
and still do an aligned access.
It has always been hard to get the compiler to 'forget' about known/expected
alignment - typically trying to stop memcpy() faulting on sparc.
Real function calls are usually required - but LTO may scupper that.

> >
> > Based on the discussion linked below, it appears that the access-ok
> > version is not realiable on any architecture, but the struct version
> > probably has no downsides. This series changes the code to use the
> > same implementation on all architectures, addressing the few exceptions
> > separately.
> >
> > I've included this version in the asm-generic tree for 5.14 already,
> > addressing the few issues that were pointed out in the RFC. If there
> > are any remaining problems, I hope those can be addressed as follow-up
> > patches.
> >
> 
> I think this series is a huge improvement, but it does not solve the
> UB problem completely. As we found, there are open issues in the GCC
> bugzilla regarding assumptions in the compiler that aligned quantities
> either overlap entirely or not at all. (e.g.,
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100363)

I think we can stop the compiler merging unaligned requests by adding a byte-sized
memory barrier for the base address before and after the access.
That should still support complex addressing modes (esp on x86).

Another option is to do the misaligned access from within an asm statement.
While architecture dependant, it only really depends on the syntax of the ld/st
instruction.
The compiler can't merge those because it doesn't know whether the data is
'frobbed' before/after the memory access.

	David

-
Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK
Registration No: 1397386 (Wales)

Re: [Linux-NTFS-Dev] [PATCH v2 00/13] Unify asm/unaligned.h around struct helper

[Ard B. <ar...@ke...>]

Hi Arnd,

(replying to an old thread as this came up in the discussion regarding
misaligned loads and stored in siphash() when compiled for ARM
[f7e5b9bfa6c8820407b64eabc1f29c9a87e8993d])

On Fri, 14 May 2021 at 12:02, Arnd Bergmann <ar...@ke...> wrote:
>
> From: Arnd Bergmann <ar...@ar...>
>
> The get_unaligned()/put_unaligned() helpers are traditionally architecture
> specific, with the two main variants being the "access-ok.h" version
> that assumes unaligned pointer accesses always work on a particular
> architecture, and the "le-struct.h" version that casts the data to a
> byte aligned type before dereferencing, for architectures that cannot
> always do unaligned accesses in hardware.
>
> Based on the discussion linked below, it appears that the access-ok
> version is not realiable on any architecture, but the struct version
> probably has no downsides. This series changes the code to use the
> same implementation on all architectures, addressing the few exceptions
> separately.
>
> I've included this version in the asm-generic tree for 5.14 already,
> addressing the few issues that were pointed out in the RFC. If there
> are any remaining problems, I hope those can be addressed as follow-up
> patches.
>

I think this series is a huge improvement, but it does not solve the
UB problem completely. As we found, there are open issues in the GCC
bugzilla regarding assumptions in the compiler that aligned quantities
either overlap entirely or not at all. (e.g.,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100363)

CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS is used in many places to
conditionally emit code that violates C alignment rules. E.g., there
is this example in Documentation/core-api/unaligned-memory-access.rst:

bool ether_addr_equal(const u8 *addr1, const u8 *addr2)
{
#ifdef CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS
  u32 fold = ((*(const u32 *)addr1) ^ (*(const u32 *)addr2)) |
             ((*(const u16 *)(addr1 + 4)) ^ (*(const u16 *)(addr2 + 4)));
  return fold == 0;
#else
...

(which now deviates from its actual implementation, but the point is
the same) where CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS is used in the
wrong way (IMHO).

The pattern seems to be

#ifdef CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS
  // ignore alignment rules, just cast to a more aligned pointer type
#else
  // use unaligned accessors, which could be either cheap or expensive,
  // depending on the architecture
#endif

whereas the following pattern makes more sense, I think, and does not
violate any C rules in the common case:

#ifdef CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS
  // use unaligned accessors, which are cheap or even entirely free
#else
  // avoid unaligned accessors, as they are expensive; instead, reorganize
  // the data so we don't need them (similar to setting NET_IP_ALIGN to 2)
#endif

The only remaining problem here is reinterpreting a char* pointer to a
u32*, e.g., for accessing the IP address in an Ethernet frame when
NET_IP_ALIGN == 2, which could suffer from the same UB problem again,
as I understand it.

In the 32-bit ARM case (v6+) [which is admittedly an outlier] this
makes a substantial difference, as ARMv6 does have efficient unaligned
accessors (load/store word or halfword may be used on misaligned
addresses) but requires that load/store double-word and load/store
multiple are only used on 32-bit aligned addresses. GCC does the right
thing with the unaligned accessors, but blindly casting away
misalignment may result in alignment traps if the compiler happened to
emit load-double or load-multiple instructions for the memory access
in question.

Jason already verifed that in the siphash() case, the aligned and
unaligned versions of the code actually compile to the same machine
code on x86, as the unaligned accessors just disappear. I suspect this
to be the case for many instances where
CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS is being used, mostly in the
networking stack.

So I intend to dig a bit deeper into this, and perhaps propose some
changes where the interpretation of
CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS is documented more clearly, and
tweaked according to my suggestion above (while ensuring that codegen
does not suffer, of course)

Thoughts, concerns, objections?


--
Ard.




> Link: https://lore.kernel.org/lkml/75d...@sy.../
> Link: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100363
> Link: https://lore.kernel.org/lkml/202...@ke.../
> Link: git://git.kernel.org/pub/scm/linux/kernel/git/arnd/asm-generic.git unaligned-rework-v2
>
>
> Arnd Bergmann (13):
>   asm-generic: use asm-generic/unaligned.h for most architectures
>   openrisc: always use unaligned-struct header
>   sh: remove unaligned access for sh4a
>   m68k: select CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS
>   powerpc: use linux/unaligned/le_struct.h on LE power7
>   asm-generic: unaligned: remove byteshift helpers
>   asm-generic: unaligned always use struct helpers
>   partitions: msdos: fix one-byte get_unaligned()
>   apparmor: use get_unaligned() only for multi-byte words
>   mwifiex: re-fix for unaligned accesses
>   netpoll: avoid put_unaligned() on single character
>   asm-generic: uaccess: 1-byte access is always aligned
>   asm-generic: simplify asm/unaligned.h
>
>  arch/alpha/include/asm/unaligned.h          |  12 --
>  arch/arm/include/asm/unaligned.h            |  27 ---
>  arch/ia64/include/asm/unaligned.h           |  12 --
>  arch/m68k/Kconfig                           |   1 +
>  arch/m68k/include/asm/unaligned.h           |  26 ---
>  arch/microblaze/include/asm/unaligned.h     |  27 ---
>  arch/mips/crypto/crc32-mips.c               |   2 +-
>  arch/openrisc/include/asm/unaligned.h       |  47 -----
>  arch/parisc/include/asm/unaligned.h         |   6 +-
>  arch/powerpc/include/asm/unaligned.h        |  22 ---
>  arch/sh/include/asm/unaligned-sh4a.h        | 199 --------------------
>  arch/sh/include/asm/unaligned.h             |  13 --
>  arch/sparc/include/asm/unaligned.h          |  11 --
>  arch/x86/include/asm/unaligned.h            |  15 --
>  arch/xtensa/include/asm/unaligned.h         |  29 ---
>  block/partitions/ldm.h                      |   2 +-
>  block/partitions/msdos.c                    |   2 +-
>  drivers/net/wireless/marvell/mwifiex/pcie.c |  10 +-
>  include/asm-generic/uaccess.h               |   4 +-
>  include/asm-generic/unaligned.h             | 141 +++++++++++---
>  include/linux/unaligned/access_ok.h         |  68 -------
>  include/linux/unaligned/be_byteshift.h      |  71 -------
>  include/linux/unaligned/be_memmove.h        |  37 ----
>  include/linux/unaligned/be_struct.h         |  37 ----
>  include/linux/unaligned/generic.h           | 115 -----------
>  include/linux/unaligned/le_byteshift.h      |  71 -------
>  include/linux/unaligned/le_memmove.h        |  37 ----
>  include/linux/unaligned/le_struct.h         |  37 ----
>  include/linux/unaligned/memmove.h           |  46 -----
>  net/core/netpoll.c                          |   4 +-
>  security/apparmor/policy_unpack.c           |   2 +-
>  31 files changed, 131 insertions(+), 1002 deletions(-)
>  delete mode 100644 arch/alpha/include/asm/unaligned.h
>  delete mode 100644 arch/arm/include/asm/unaligned.h
>  delete mode 100644 arch/ia64/include/asm/unaligned.h
>  delete mode 100644 arch/m68k/include/asm/unaligned.h
>  delete mode 100644 arch/microblaze/include/asm/unaligned.h
>  delete mode 100644 arch/openrisc/include/asm/unaligned.h
>  delete mode 100644 arch/powerpc/include/asm/unaligned.h
>  delete mode 100644 arch/sh/include/asm/unaligned-sh4a.h
>  delete mode 100644 arch/sh/include/asm/unaligned.h
>  delete mode 100644 arch/sparc/include/asm/unaligned.h
>  delete mode 100644 arch/x86/include/asm/unaligned.h
>  delete mode 100644 arch/xtensa/include/asm/unaligned.h
>  delete mode 100644 include/linux/unaligned/access_ok.h
>  delete mode 100644 include/linux/unaligned/be_byteshift.h
>  delete mode 100644 include/linux/unaligned/be_memmove.h
>  delete mode 100644 include/linux/unaligned/be_struct.h
>  delete mode 100644 include/linux/unaligned/generic.h
>  delete mode 100644 include/linux/unaligned/le_byteshift.h
>  delete mode 100644 include/linux/unaligned/le_memmove.h
>  delete mode 100644 include/linux/unaligned/le_struct.h
>  delete mode 100644 include/linux/unaligned/memmove.h
>
> --
> 2.29.2
>
> Cc: Amitkumar Karwar <ami...@gm...>
> Cc: Arnd Bergmann <ar...@ar...>
> Cc: Benjamin Herrenschmidt <be...@ke...>
> Cc: Borislav Petkov <bp...@al...>
> Cc: Eric Dumazet <edu...@go...>
> Cc: Florian Fainelli <f.f...@gm...>
> Cc: Ganapathi Bhat <gan...@gm...>
> Cc: Geert Uytterhoeven <ge...@li...>
> Cc: "H. Peter Anvin" <hp...@zy...>
> Cc: Ingo Molnar <mi...@re...>
> Cc: Jakub Kicinski <ku...@ke...>
> Cc: James Morris <jm...@na...>
> Cc: Jens Axboe <ax...@ke...>
> Cc: John Johansen <joh...@ca...>
> Cc: Jonas Bonn <jo...@so...>
> Cc: Kalle Valo <kv...@co...>
> Cc: Michael Ellerman <mp...@el...>
> Cc: Paul Mackerras <pa...@sa...>
> Cc: Rich Felker <da...@li...>
> Cc: "Richard Russon (FlatCap)" <ld...@fl...>
> Cc: Russell King <li...@ar...>
> Cc: "Serge E. Hallyn" <se...@ha...>
> Cc: Sharvari Harisangam <sha...@nx...>
> Cc: Stafford Horne <sh...@gm...>
> Cc: Stefan Kristiansson <ste...@sa...>
> Cc: Thomas Gleixner <tg...@li...>
> Cc: Vladimir Oltean <vla...@nx...>
> Cc: Xinming Hu <hux...@gm...>
> Cc: Yoshinori Sato <ys...@us...>
> Cc: x8...@ke...
> Cc: lin...@vg...
> Cc: lin...@li...
> Cc: lin...@li...
> Cc: lin...@vg...
> Cc: ope...@li...
> Cc: lin...@li...
> Cc: lin...@vg...
> Cc: spa...@vg...
> Cc: lin...@li...
> Cc: lin...@vg...
> Cc: lin...@vg...
> Cc: ne...@vg...
> Cc: lin...@vg...
> Cc: lin...@vg...
>
>

Re: [Linux-NTFS-Dev] [PATCH v2] ntfs: Fix ntfs_test_inode and ntfs_init_locked_inode function type

[Greg KH <gr...@li...>]

On Thu, Dec 09, 2021 at 10:38:39PM +0800, Mark-PK Tsai wrote:
> > Clang's Control Flow Integrity (CFI) is a security mechanism that can
> > help prevent JOP chains, deployed extensively in downstream kernels
> > used in Android.
> > 
> > It's deployment is hindered by mismatches in function signatures.  For
> > this case, we make callbacks match their intended function signature,
> > and cast parameters within them rather than casting the callback when
> > passed as a parameter.
> > 
> > When running `mount -t ntfs ...` we observe the following trace:
> > 
> > Call trace:
> > __cfi_check_fail+0x1c/0x24
> > name_to_dev_t+0x0/0x404
> > iget5_locked+0x594/0x5e8
> > ntfs_fill_super+0xbfc/0x43ec
> > mount_bdev+0x30c/0x3cc
> > ntfs_mount+0x18/0x24
> > mount_fs+0x1b0/0x380
> > vfs_kern_mount+0x90/0x398
> > do_mount+0x5d8/0x1a10
> > SyS_mount+0x108/0x144
> > el0_svc_naked+0x34/0x38
> > 
> > Signed-off-by: Luca Stefani <luc...@gm...>
> > Tested-by: freak07 <mic...@go...>
> > Acked-by: Anton Altaparmakov <an...@tu...>
> > ---
> >  fs/ntfs/dir.c   |  2 +-
> >  fs/ntfs/inode.c | 27 ++++++++++++++-------------
> >  fs/ntfs/inode.h |  4 +---
> >  fs/ntfs/mft.c   |  4 ++--
> >  4 files changed, 18 insertions(+), 19 deletions(-)
> > 
> 
> Hi,
> 
> I think stable tree should pick this change.
> 
> Below is the mainline commit.
> 
> (1146f7e2dc15 ntfs: fix ntfs_test_inode and ntfs_init_locked_inode function type)
> 
> 5.4 stable have the same issue when CFI is enabled.

Now queued up, thanks.

greg k-h

[Linux-NTFS-Dev] [PATCH v2] ntfs: Fix ntfs_test_inode and ntfs_init_locked_inode function type

[Mark-PK T. <mar...@me...>]

> Clang's Control Flow Integrity (CFI) is a security mechanism that can
> help prevent JOP chains, deployed extensively in downstream kernels
> used in Android.
> 
> It's deployment is hindered by mismatches in function signatures.  For
> this case, we make callbacks match their intended function signature,
> and cast parameters within them rather than casting the callback when
> passed as a parameter.
> 
> When running `mount -t ntfs ...` we observe the following trace:
> 
> Call trace:
> __cfi_check_fail+0x1c/0x24
> name_to_dev_t+0x0/0x404
> iget5_locked+0x594/0x5e8
> ntfs_fill_super+0xbfc/0x43ec
> mount_bdev+0x30c/0x3cc
> ntfs_mount+0x18/0x24
> mount_fs+0x1b0/0x380
> vfs_kern_mount+0x90/0x398
> do_mount+0x5d8/0x1a10
> SyS_mount+0x108/0x144
> el0_svc_naked+0x34/0x38
> 
> Signed-off-by: Luca Stefani <luc...@gm...>
> Tested-by: freak07 <mic...@go...>
> Acked-by: Anton Altaparmakov <an...@tu...>
> ---
>  fs/ntfs/dir.c   |  2 +-
>  fs/ntfs/inode.c | 27 ++++++++++++++-------------
>  fs/ntfs/inode.h |  4 +---
>  fs/ntfs/mft.c   |  4 ++--
>  4 files changed, 18 insertions(+), 19 deletions(-)
> 

Hi,

I think stable tree should pick this change.

Below is the mainline commit.

(1146f7e2dc15 ntfs: fix ntfs_test_inode and ntfs_init_locked_inode function type)

5.4 stable have the same issue when CFI is enabled.

Re: [Linux-NTFS-Dev] [PATCH AUTOSEL 4.4 9/9] fs: ntfs: Limit NTFS_RW to page sizes smaller than 64k

[Pavel M. <pa...@de...>]

Hi!

> [ Upstream commit 4eec7faf6775263d9e450ae7ee5bc4101d4a0bc9 ]
> 
> NTFS_RW code allocates page size dependent arrays on the stack. This
> results in build failures if the page size is 64k or larger.
> 
>   fs/ntfs/aops.c: In function 'ntfs_write_mst_block':
>   fs/ntfs/aops.c:1311:1: error:
> 	the frame size of 2240 bytes is larger than 2048 bytes
> 
> Since commit f22969a66041 ("powerpc/64s: Default to 64K pages for 64 bit
> book3s") this affects ppc:allmodconfig builds, but other architectures
> supporting page sizes of 64k or larger are also affected.

NAK, this will disable NTFS_RW support in 4.4 entirely.

> +++ b/fs/ntfs/Kconfig
> @@ -51,6 +51,7 @@ config NTFS_DEBUG
>  config NTFS_RW
>  	bool "NTFS write support"
>  	depends on NTFS_FS
> +	depends on PAGE_SIZE_LESS_THAN_64KB
>  	help
>  	  This enables the partial, but safe, write support in the NTFS driver.
>  

AFAICT CONFIG_PAGE_SIZE_LESS_THAN_64KB is not present in 4.4 (and
probably other) -stable kernels, nor it is queued to be added there.

Best regards,
								Pavel
-- 
DENX Software Engineering GmbH,      Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany

[Linux-NTFS-Dev] [PATCH AUTOSEL 4.9 12/12] fs: ntfs: Limit NTFS_RW to page sizes smaller than 64k

[Sasha L. <sa...@ke...>]

From: Guenter Roeck <li...@ro...>

[ Upstream commit 4eec7faf6775263d9e450ae7ee5bc4101d4a0bc9 ]

NTFS_RW code allocates page size dependent arrays on the stack. This
results in build failures if the page size is 64k or larger.

  fs/ntfs/aops.c: In function 'ntfs_write_mst_block':
  fs/ntfs/aops.c:1311:1: error:
	the frame size of 2240 bytes is larger than 2048 bytes

Since commit f22969a66041 ("powerpc/64s: Default to 64K pages for 64 bit
book3s") this affects ppc:allmodconfig builds, but other architectures
supporting page sizes of 64k or larger are also affected.

Increasing the maximum frame size for affected architectures just to
silence this error does not really help.  The frame size would have to
be set to a really large value for 256k pages.  Also, a large frame size
could potentially result in stack overruns in this code and elsewhere
and is therefore not desirable.  Make NTFS_RW dependent on page sizes
smaller than 64k instead.

Signed-off-by: Guenter Roeck <li...@ro...>
Cc: Anton Altaparmakov <an...@tu...>
Signed-off-by: Linus Torvalds <tor...@li...>
Signed-off-by: Sasha Levin <sa...@ke...>
---
 fs/ntfs/Kconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/fs/ntfs/Kconfig b/fs/ntfs/Kconfig
index f5a868cc9152e..5b384ec44793f 100644
--- a/fs/ntfs/Kconfig
+++ b/fs/ntfs/Kconfig
@@ -51,6 +51,7 @@ config NTFS_DEBUG
 config NTFS_RW
 	bool "NTFS write support"
 	depends on NTFS_FS
+	depends on PAGE_SIZE_LESS_THAN_64KB
 	help
 	  This enables the partial, but safe, write support in the NTFS driver.
 
-- 
2.33.0

[Linux-NTFS-Dev] [PATCH AUTOSEL 4.14 14/14] fs: ntfs: Limit NTFS_RW to page sizes smaller than 64k

[Sasha L. <sa...@ke...>]

From: Guenter Roeck <li...@ro...>

[ Upstream commit 4eec7faf6775263d9e450ae7ee5bc4101d4a0bc9 ]

NTFS_RW code allocates page size dependent arrays on the stack. This
results in build failures if the page size is 64k or larger.

  fs/ntfs/aops.c: In function 'ntfs_write_mst_block':
  fs/ntfs/aops.c:1311:1: error:
	the frame size of 2240 bytes is larger than 2048 bytes

Since commit f22969a66041 ("powerpc/64s: Default to 64K pages for 64 bit
book3s") this affects ppc:allmodconfig builds, but other architectures
supporting page sizes of 64k or larger are also affected.

Increasing the maximum frame size for affected architectures just to
silence this error does not really help.  The frame size would have to
be set to a really large value for 256k pages.  Also, a large frame size
could potentially result in stack overruns in this code and elsewhere
and is therefore not desirable.  Make NTFS_RW dependent on page sizes
smaller than 64k instead.

Signed-off-by: Guenter Roeck <li...@ro...>
Cc: Anton Altaparmakov <an...@tu...>
Signed-off-by: Linus Torvalds <tor...@li...>
Signed-off-by: Sasha Levin <sa...@ke...>
---
 fs/ntfs/Kconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/fs/ntfs/Kconfig b/fs/ntfs/Kconfig
index f5a868cc9152e..5b384ec44793f 100644
--- a/fs/ntfs/Kconfig
+++ b/fs/ntfs/Kconfig
@@ -51,6 +51,7 @@ config NTFS_DEBUG
 config NTFS_RW
 	bool "NTFS write support"
 	depends on NTFS_FS
+	depends on PAGE_SIZE_LESS_THAN_64KB
 	help
 	  This enables the partial, but safe, write support in the NTFS driver.
 
-- 
2.33.0

[Linux-NTFS-Dev] [PATCH AUTOSEL 4.4 9/9] fs: ntfs: Limit NTFS_RW to page sizes smaller than 64k

[Sasha L. <sa...@ke...>]

From: Guenter Roeck <li...@ro...>

[ Upstream commit 4eec7faf6775263d9e450ae7ee5bc4101d4a0bc9 ]

NTFS_RW code allocates page size dependent arrays on the stack. This
results in build failures if the page size is 64k or larger.

  fs/ntfs/aops.c: In function 'ntfs_write_mst_block':
  fs/ntfs/aops.c:1311:1: error:
	the frame size of 2240 bytes is larger than 2048 bytes

Since commit f22969a66041 ("powerpc/64s: Default to 64K pages for 64 bit
book3s") this affects ppc:allmodconfig builds, but other architectures
supporting page sizes of 64k or larger are also affected.

Increasing the maximum frame size for affected architectures just to
silence this error does not really help.  The frame size would have to
be set to a really large value for 256k pages.  Also, a large frame size
could potentially result in stack overruns in this code and elsewhere
and is therefore not desirable.  Make NTFS_RW dependent on page sizes
smaller than 64k instead.

Signed-off-by: Guenter Roeck <li...@ro...>
Cc: Anton Altaparmakov <an...@tu...>
Signed-off-by: Linus Torvalds <tor...@li...>
Signed-off-by: Sasha Levin <sa...@ke...>
---
 fs/ntfs/Kconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/fs/ntfs/Kconfig b/fs/ntfs/Kconfig
index f5a868cc9152e..5b384ec44793f 100644
--- a/fs/ntfs/Kconfig
+++ b/fs/ntfs/Kconfig
@@ -51,6 +51,7 @@ config NTFS_DEBUG
 config NTFS_RW
 	bool "NTFS write support"
 	depends on NTFS_FS
+	depends on PAGE_SIZE_LESS_THAN_64KB
 	help
 	  This enables the partial, but safe, write support in the NTFS driver.
 
-- 
2.33.0

[Linux-NTFS-Dev] [PATCH AUTOSEL 4.19 17/17] fs: ntfs: Limit NTFS_RW to page sizes smaller than 64k

[Sasha L. <sa...@ke...>]

From: Guenter Roeck <li...@ro...>

[ Upstream commit 4eec7faf6775263d9e450ae7ee5bc4101d4a0bc9 ]

NTFS_RW code allocates page size dependent arrays on the stack. This
results in build failures if the page size is 64k or larger.

  fs/ntfs/aops.c: In function 'ntfs_write_mst_block':
  fs/ntfs/aops.c:1311:1: error:
	the frame size of 2240 bytes is larger than 2048 bytes

Since commit f22969a66041 ("powerpc/64s: Default to 64K pages for 64 bit
book3s") this affects ppc:allmodconfig builds, but other architectures
supporting page sizes of 64k or larger are also affected.

Increasing the maximum frame size for affected architectures just to
silence this error does not really help.  The frame size would have to
be set to a really large value for 256k pages.  Also, a large frame size
could potentially result in stack overruns in this code and elsewhere
and is therefore not desirable.  Make NTFS_RW dependent on page sizes
smaller than 64k instead.

Signed-off-by: Guenter Roeck <li...@ro...>
Cc: Anton Altaparmakov <an...@tu...>
Signed-off-by: Linus Torvalds <tor...@li...>
Signed-off-by: Sasha Levin <sa...@ke...>
---
 fs/ntfs/Kconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/fs/ntfs/Kconfig b/fs/ntfs/Kconfig
index f5a868cc9152e..5b384ec44793f 100644
--- a/fs/ntfs/Kconfig
+++ b/fs/ntfs/Kconfig
@@ -51,6 +51,7 @@ config NTFS_DEBUG
 config NTFS_RW
 	bool "NTFS write support"
 	depends on NTFS_FS
+	depends on PAGE_SIZE_LESS_THAN_64KB
 	help
 	  This enables the partial, but safe, write support in the NTFS driver.
 
-- 
2.33.0

[Linux-NTFS-Dev] [PATCH AUTOSEL 5.4 25/25] fs: ntfs: Limit NTFS_RW to page sizes smaller than 64k

[Sasha L. <sa...@ke...>]

From: Guenter Roeck <li...@ro...>

[ Upstream commit 4eec7faf6775263d9e450ae7ee5bc4101d4a0bc9 ]

NTFS_RW code allocates page size dependent arrays on the stack. This
results in build failures if the page size is 64k or larger.

  fs/ntfs/aops.c: In function 'ntfs_write_mst_block':
  fs/ntfs/aops.c:1311:1: error:
	the frame size of 2240 bytes is larger than 2048 bytes

Since commit f22969a66041 ("powerpc/64s: Default to 64K pages for 64 bit
book3s") this affects ppc:allmodconfig builds, but other architectures
supporting page sizes of 64k or larger are also affected.

Increasing the maximum frame size for affected architectures just to
silence this error does not really help.  The frame size would have to
be set to a really large value for 256k pages.  Also, a large frame size
could potentially result in stack overruns in this code and elsewhere
and is therefore not desirable.  Make NTFS_RW dependent on page sizes
smaller than 64k instead.

Signed-off-by: Guenter Roeck <li...@ro...>
Cc: Anton Altaparmakov <an...@tu...>
Signed-off-by: Linus Torvalds <tor...@li...>
Signed-off-by: Sasha Levin <sa...@ke...>
---
 fs/ntfs/Kconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/fs/ntfs/Kconfig b/fs/ntfs/Kconfig
index de9fb5cff2269..026ec41418049 100644
--- a/fs/ntfs/Kconfig
+++ b/fs/ntfs/Kconfig
@@ -52,6 +52,7 @@ config NTFS_DEBUG
 config NTFS_RW
 	bool "NTFS write support"
 	depends on NTFS_FS
+	depends on PAGE_SIZE_LESS_THAN_64KB
 	help
 	  This enables the partial, but safe, write support in the NTFS driver.
 
-- 
2.33.0