memory leak of auth_key.response in multichannel establishment

memory leak of auth_key.response in multichannel establishment

[Paul Aurich]

Mounting an SMB share with multichannel enabled appears to leak all but one
allocations of ses->auth_key.response, at least with ntlmssp auth. This was on
(roughly) bf1028a41ea:

unreferenced object 0xffff88802cefc500 (size 256):
   comm "mount.cifs", pid 680, jiffies 4294907522 (age 381.360s)
   hex dump (first 32 bytes):
     19 68 bf 70 7b a3 b8 00 43 63 8c fa e1 00 90 fb  .h.p{...Cc......
     1d d8 39 3c 25 d1 d3 f0 a2 4e e4 99 4f 35 9b 2e  ..9<%....N..O5..
   backtrace:
     [<000000006c8d6e81>] setup_ntlmv2_rsp+0x2f4/0x2190
     [<000000006cf0d77f>] build_ntlmssp_auth_blob+0x2b/0x10d0
     [<00000000300414f8>] SMB2_sess_auth_rawntlmssp_authenticate+0x316/0x7c0
     [<000000002ee76096>] SMB2_sess_setup+0x377/0x7b0
     [<0000000076fded43>] cifs_setup_session+0x359/0x770
     [<00000000f6a70b79>] cifs_get_smb_ses+0xfe1/0x2ae0
     [<0000000030763a8d>] mount_get_conns+0x20d/0xec0
     [<000000003deb8295>] cifs_mount+0xbe/0x1d00
     [<00000000d18bac6c>] cifs_smb3_do_mount+0x26e/0x1330
     [<000000000952c786>] legacy_get_tree+0x101/0x1f0
     [<00000000f07e0c29>] vfs_get_tree+0x8a/0x2d0
     [<00000000edbc514a>] do_mount+0xed7/0x16f0
     [<00000000ee452092>] __x64_sys_mount+0x12c/0x1a0
     [<00000000a6ccd160>] do_syscall_64+0x56/0xa0
     [<000000003143088f>] entry_SYSCALL_64_after_hwframe+0x44/0xa9
unreferenced object 0xffff88802a33e500 (size 256):
   comm "mount.cifs", pid 680, jiffies 4294907547 (age 381.260s)
   hex dump (first 32 bytes):
     5f ff 39 9f c0 e9 1e 3b 0a f1 06 9d c7 53 c2 74  _.9....;.....S.t
     03 7e 5f 2f 27 f7 a8 84 70 e8 58 e3 91 f6 76 d6  .~_/'...p.X...v.
   backtrace:
     [<000000006c8d6e81>] setup_ntlmv2_rsp+0x2f4/0x2190
     [<000000006cf0d77f>] build_ntlmssp_auth_blob+0x2b/0x10d0
     [<00000000300414f8>] SMB2_sess_auth_rawntlmssp_authenticate+0x316/0x7c0
     [<000000002ee76096>] SMB2_sess_setup+0x377/0x7b0
     [<0000000076fded43>] cifs_setup_session+0x359/0x770
     [<000000006bb9ce4c>] cifs_ses_add_channel+0x9bc/0x10a0
     [<000000004034ab3b>] cifs_try_adding_channels+0x1f0/0x580
     [<000000009ac39b0b>] cifs_mount+0xed1/0x1d00
     [<00000000d18bac6c>] cifs_smb3_do_mount+0x26e/0x1330
     [<000000000952c786>] legacy_get_tree+0x101/0x1f0
     [<00000000f07e0c29>] vfs_get_tree+0x8a/0x2d0
     [<00000000edbc514a>] do_mount+0xed7/0x16f0
     [<00000000ee452092>] __x64_sys_mount+0x12c/0x1a0
     [<00000000a6ccd160>] do_syscall_64+0x56/0xa0
     [<000000003143088f>] entry_SYSCALL_64_after_hwframe+0x44/0xa9

Regards,
~Paul

Re: memory leak of auth_key.response in multichannel establishment

[Aurélien Aptel]

Hi Paul,

These stack traces are where printed when the object is lost right?

Cheers,
-- 
Aurélien Aptel / SUSE Labs Samba Team
GPG: 1839 CB5F 9F5B FB9B AA97  8C99 03C8 A49B 521B D5D3
SUSE Software Solutions Germany GmbH, Maxfeldstr. 5, 90409 Nürnberg, DE
GF: Felix Imendörffer, Mary Higgins, Sri Rasiah HRB 247165 (AG München)

Re: memory leak of auth_key.response in multichannel establishment

[Paul Aurich]

They're the stack trace of where the allocations occurred, for objects that 
are lost.  (I won't pretend to understand kmemleak's algorithm for determining 
lost objects.)

In this case, I was mounting a server with max_channels=4, which generates 
three leak reports (one for the initial session, and two with the same stack 
trace, cifs_try_adding_channels -> cifs_ses_add_channel).  (With 
max_channels=8, I get 7 leak reports)

With

     CONFIG_HAVE_DEBUG_KMEMLEAK=y
     CONFIG_DEBUG_KMEMLEAK=y
     CONFIG_DEBUG_KMEMLEAK_MEM_POOL_SIZE=16000
     CONFIG_DEBUG_KMEMLEAK_AUTO_SCAN=y

To reproduce:

     - mount -t cifs -o multichannel,max_channels=4,... ...
     - echo scan > /sys/kernel/debug/kmemleak
       or wait long enough for the kmemleak periodic scan to pick it up
     - cat /sys/kernel/debug/kmemleak

~Paul

On 2020-07-01 15:35:34 +0200, Aurélien Aptel wrote:
>Hi Paul,
>
>These stack traces are where printed when the object is lost right?
>
>Cheers,
>-- 
>Aurélien Aptel / SUSE Labs Samba Team
>GPG: 1839 CB5F 9F5B FB9B AA97  8C99 03C8 A49B 521B D5D3
>SUSE Software Solutions Germany GmbH, Maxfeldstr. 5, 90409 Nürnberg, DE
>GF: Felix Imendörffer, Mary Higgins, Sri Rasiah HRB 247165 (AG München)
>