In the Linux kernel, the following vulnerability has been resolved:
isofs: avoid memory leak in iocharset
A memleak was found as below:
unreferenced object 0xffff0000d10164d8 (size 8): comm "pool-udisksd", pid 108217, jiffies 4295408555 hex dump (first 8 bytes): 75 74 66 38 00 cc cc cc utf8.... backtrace (crc de430d31): [<ffff800081046e6c>] kmemleakalloc+0xb8/0xc8 [<ffff8000803e6c3c>] _kmallocnodetrackcallernoprof+0x380/0x474 [<ffff800080363b74>] kstrdup+0x70/0xfc [<ffff80007bb3c6a4>] isofsparseparam+0x228/0x2c0 [isofs] [<ffff8000804d7f68>] vfsparsefsparam+0xf4/0x164 [<ffff8000804d8064>] vfsparsefsstring+0x8c/0xd4 [<ffff8000804d815c>] vfsparsemonolithicsep+0xb0/0xfc [<ffff8000804d81d8>] genericparsemonolithic+0x30/0x3c [<ffff8000804d8bfc>] parsemonolithicmountdata+0x40/0x4c [<ffff8000804b6a64>] pathmount+0x6c4/0x9ec [<ffff8000804b6e38>] domount+0xac/0xc4 [<ffff8000804b7494>] _arm64sysmount+0x16c/0x2b0 [<ffff80008002b8dc>] invokesyscall+0x7c/0x104 [<ffff80008002ba44>] el0svccommon.constprop.1+0xe0/0x104 [<ffff80008002ba94>] doel0svc+0x2c/0x38 [<ffff800081041108>] el0_svc+0x3c/0x1b8
The opt->iocharset is freed inside the isofsfillsuper function, But there may be situations where it's not possible to enter this function.
For example, in the gettreebdevflags function,when encountering the situation where "Can't mount, would change RO state," In such a case, isofsfill_super will not have the opportunity to be called,which means that opt->iocharset will not have the chance to be freed,ultimately leading to a memory leak.
Let's move the memory freeing of opt->iocharset into isofsfreefc function.