cifs: handle large EA requests more gracefully in smb2+

PATCH In review Ronnie Sahlberg 3 participants 3 messages Sep 27, 2017 2 messages not in the archive

Subsystems (2)

SMB client (CIFS) Kernel SMB3 server (ksmbd)

lore

Share & tools

lore

Ronnie Sahlberg

author

2017-09-27 06:20 UTC #0 lore raw

PATCH 1/1 cifs: handle large EA requests more gracefully in smb2+

Update update reading the EA using increasingly larger buffer sizes until the response will fit in the buffer, or we exceed the (arbitrary) maximum set to 64kb.

Without this change, a user is able to add more and more EAs using setfattr until the point where the total space of all EAs exceed 2kb at which point the user can no longer list the EAs at all and getfattr will abort with an error.

The maximum is currently set to 64kb almost arbitrarily. 64kb is the maximum size of all xattrs under XFS so at least for samba + XFS (or EXT4) servers we will not be able to write so many EAs that we no longer can list them any more.

The same issue still exists for EAs in SMB1.

Signed-off-by Ronnie Sahlberg <[email protected]>

---
 fs/cifs/smb2maperror.c |  2 +-
 fs/cifs/smb2ops.c      | 31 +++++++++++++++++++++++++------
 fs/cifs/smb2pdu.c      |  6 +++---
 fs/cifs/smb2pdu.h      |  3 ++-
 fs/cifs/smb2proto.h    |  1 +
 5 files changed, 32 insertions(+), 11 deletions(-)

fs/cifs/smb2maperror.c +1 -1

index 7ca9808a0daa..62c88dfed57b 100644
@@ -214,7 +214,7 @@ static const struct status_to_posix_error smb2_error_map_table[] = {
 	{STATUS_DATATYPE_MISALIGNMENT, -EIO, "STATUS_DATATYPE_MISALIGNMENT"},
 	{STATUS_BREAKPOINT, -EIO, "STATUS_BREAKPOINT"},
 	{STATUS_SINGLE_STEP, -EIO, "STATUS_SINGLE_STEP"},
-	{STATUS_BUFFER_OVERFLOW, -EIO, "STATUS_BUFFER_OVERFLOW"},
+	{STATUS_BUFFER_OVERFLOW, -E2BIG, "STATUS_BUFFER_OVERFLOW"},
 	{STATUS_NO_MORE_FILES, -ENODATA, "STATUS_NO_MORE_FILES"},
 	{STATUS_WAKE_SYSTEM_DEBUGGER, -EIO, "STATUS_WAKE_SYSTEM_DEBUGGER"},
 	{STATUS_HANDLES_CLOSED, -EIO, "STATUS_HANDLES_CLOSED"},

fs/cifs/smb2ops.c +25 -6

index 0dafdbae1f8c..bdb963d0ba32 100644
@@ -522,6 +522,7 @@ smb2_query_eas(const unsigned int xid, struct cifs_tcon *tcon,
 	struct cifs_open_parms oparms;
 	struct cifs_fid fid;
 	struct smb2_file_full_ea_info *smb2_data;
+	int ea_buf_size = SMB2_MIN_EA_BUF;
 
 	utf16_path = cifs_convert_path_to_utf16(path, cifs_sb);
 	if (!utf16_path)

@@ -541,14 +542,32 @@ smb2_query_eas(const unsigned int xid, struct cifs_tcon *tcon,
 		return rc;
 	}
 
-	smb2_data = kzalloc(SMB2_MAX_EA_BUF, GFP_KERNEL);
-	if (smb2_data == NULL) {
-		SMB2_close(xid, tcon, fid.persistent_fid, fid.volatile_fid);
-		return -ENOMEM;
+	while (1) {
+		smb2_data = kzalloc(ea_buf_size, GFP_KERNEL);
+		if (smb2_data == NULL) {
+			SMB2_close(xid, tcon, fid.persistent_fid,
+				   fid.volatile_fid);
+			return -ENOMEM;
+		}
+
+		rc = SMB2_query_eas(xid, tcon, fid.persistent_fid,
+				    fid.volatile_fid,
+				    ea_buf_size, smb2_data);
+
+		if (rc != -E2BIG)
+			break;
+
+		kfree(smb2_data);
+		ea_buf_size <<= 1;
+
+		if (ea_buf_size > SMB2_MAX_EA_BUF) {
+			cifs_dbg(VFS, "EA size is too large\n");
+			SMB2_close(xid, tcon, fid.persistent_fid,
+				   fid.volatile_fid);
+			return -ENOMEM;
+		}
 	}
 
-	rc = SMB2_query_eas(xid, tcon, fid.persistent_fid, fid.volatile_fid,
-			    smb2_data);
 	SMB2_close(xid, tcon, fid.persistent_fid, fid.volatile_fid);
 
 	if (!rc)

fs/cifs/smb2pdu.c +3 -3

index 6f0e6343c15e..ba3865b338d8 100644
@@ -2233,12 +2233,12 @@ query_info(const unsigned int xid, struct cifs_tcon *tcon,
 }
 
 int SMB2_query_eas(const unsigned int xid, struct cifs_tcon *tcon,
-	u64 persistent_fid, u64 volatile_fid,
-	struct smb2_file_full_ea_info *data)
+		   u64 persistent_fid, u64 volatile_fid,
+		   int ea_buf_size, struct smb2_file_full_ea_info *data)
 {
 	return query_info(xid, tcon, persistent_fid, volatile_fid,
 			  FILE_FULL_EA_INFORMATION, SMB2_O_INFO_FILE, 0,
-			  SMB2_MAX_EA_BUF,
+			  ea_buf_size,
 			  sizeof(struct smb2_file_full_ea_info),
 			  (void **)&data,
 			  NULL);

fs/cifs/smb2pdu.h +2 -1

index 6c9653a130c8..4c155b95b558 100644
@@ -1178,7 +1178,8 @@ struct smb2_file_link_info { /* encoding of request for level 11 */
 	char   FileName[0];     /* Name to be assigned to new link */
 } __packed; /* level 11 Set */
 
-#define SMB2_MAX_EA_BUF 2048
+#define SMB2_MIN_EA_BUF  2048
+#define SMB2_MAX_EA_BUF 65536
 
 struct smb2_file_full_ea_info { /* encoding of response for level 15 */
 	__le32 next_entry_offset;

fs/cifs/smb2proto.h +1 -0

index 003217099ef3..e9ab5227e7a8 100644
@@ -134,6 +134,7 @@ extern int SMB2_flush(const unsigned int xid, struct cifs_tcon *tcon,
 		      u64 persistent_file_id, u64 volatile_file_id);
 extern int SMB2_query_eas(const unsigned int xid, struct cifs_tcon *tcon,
 			  u64 persistent_file_id, u64 volatile_file_id,
+			  int ea_buf_size,
 			  struct smb2_file_full_ea_info *data);
 extern int SMB2_query_info(const unsigned int xid, struct cifs_tcon *tcon,
 			   u64 persistent_file_id, u64 volatile_file_id,

Signature · 1 line

2.13.3

A message that is not in the archive (sent off-list or not yet received): 20170927062001.979-1-lsahlber-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org

Christoph Hellwig

2017-09-27 06:32 UTC #2 lore raw

Quoted 4 lines · Ronnie Sahlberg

The maximum is currently set to 64kb almost arbitrarily. 64kb is the maximum size of all xattrs under XFS so at least for samba + XFS (or EXT4) servers we will not be able to write so many EAs that we no longer can list them any more.

This description looks confusing.

For XFS the limits is 64kb for each individual xattr, not for all attrs.

But your patch seems to be about the listxattr path anyway if I read it correctly. There the VFS exposes a limit of XATTR_LIST_MAX, which also happens to be 64kb for the buffer size that contains all the xattr _names_. Note that XFS could support almost arbitrary large amounts of xatttrs names (and on IRIX does), but on Linux we limit it to this limit of the VFS listxattr interface.

A message that is not in the archive (sent off-list or not yet received): [email protected]

ronnie sahlberg

2017-09-27 06:39 UTC #4 lore raw

My mistake. I misremembered the limit for XFS.

Unless there are other issues in the reviews that will require a re-spin, maybe Steve
can tweak the commit message.

regards
Ronnie Sahlberg

Quoted 20 lines · Christoph Hellwig

Quoted 4 lines · Ronnie Sahlberg
The maximum is currently set to 64kb almost arbitrarily. 64kb is the maximum size of all xattrs under XFS so at least for samba + XFS (or EXT4) servers we will not be able to write so many EAs that we no longer can list them any more.
This description looks confusing.
For XFS the limits is 64kb for each individual xattr, not for all attrs.
But your patch seems to be about the listxattr path anyway if I read it correctly. There the VFS exposes a limit of XATTR_LIST_MAX, which also happens to be 64kb for the buffer size that contains all the xattr _names_. Note that XFS could support almost arbitrary large amounts of xatttrs names (and on IRIX does), but on Linux we limit it to this limit of the VFS listxattr interface.
--
To unsubscribe from this list: send the line "unsubscribe linux-cifs" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html