CIFS: add SFM mapping for 0x01-0x1F

Hi,

attached patch adds more missing mappings for the 0x01-0x1f range. Please review, if you're fine with it, considere it also for stable.

Björn

From a97720c26db2ee77d4e798e3d383fcb6a348bd29 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Bj=C3=B6rn=20Jacke?= <[email protected]>
Date: Wed, 31 May 2017 22:48:41 +0200
Subject: [PATCH] cifs: add SFM mapping for 0x01-0x1F

0x1-0x1F has to be mapped to 0xF001-0xF01F

---
 fs/cifs/cifs_unicode.c | 8 ++++++++
 1 file changed, 8 insertions(+)

index a0b3e7d..e0445e2 100644
@@ -79,6 +79,10 @@ convert_sfu_char(const __u16 src_char, char *target)
 static bool
 convert_sfm_char(const __u16 src_char, char *target)
 {
+	if (src_char >= 0xF001 && src_char <= 0xF01F) {
+		*target = src_char - 0xF000;
+		return true;
+	}
 	switch (src_char) {
 	case SFM_COLON:
 		*target = ':';

@@ -417,6 +421,10 @@ static __le16 convert_to_sfm_char(char src_char, bool end_of_string)
 {
 	__le16 dest_char;
 
+	if (src_char >= 0x01 && src_char <= 0x1F) {
+		dest_char = cpu_to_le16(src_char + 0xF000);
+		return dest_char;
+	}
 	switch (src_char) {
 	case ':':
 		dest_char = cpu_to_le16(SFM_COLON);

2.7.4

Hi Björn,

Are these mappings documented somewhere? Now that Windows has a new Linux subsystem I wonder if any of these SFM/SFU mappings have changed.

Cheers,

Aurélien Aptel / SUSE Labs Samba Team
GPG: 1839 CB5F 9F5B FB9B AA97  8C99 03C8 A49B 521B D5D3
SUSE Linux GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
GF: Felix Imendörffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nürnberg)

Hi Aurélien,

it once was documentd in MS KB117258 ... which disappeared unfortunately, wayback machine still has is though:

https://web-beta.archive.org/web/20150315001238/http://support.microsoft.com:80/en-us/kb/117258

I also verified that current OS X clients use these mappings for SMB.

The only remaining mapping which needs fixing in the cifs module is the backslash now.

Björn

merged into cifs-2.6.git

JRA had some security concerns about allowing \ mapping so we need to be careful in deciding how we want Samba to handle that too

Thanks,

Steve

Hi,

I don't really see how the cifs client-side mapping of the "\" character should affect Samba security here. The client only maps "\" to an innocent unicode character. The server does nothing with that unicode character at all. It just stores it as it is - unless you configure via vfs fruit that you want to convert it to native encoding. But that's actually nothing that cifs vfs has to worry about. Even without an our mapping of "\" we can simply create unicode 0xF021 now on a remote SMB server. And the smb mac clients already do it anyway.

Björn