efi/capsule-loader: fix incorrect sizeof in phys array reallocation

In the Linux kernel, the following vulnerability has been resolved:

drm/amd/display: Fix dclink NULL handling in HPD init

amdgpudmhpdinit() may see connectors without a valid dclink.

The code already checks dclink for the polling decision, but later unconditionally dereferences it when setting up HPD interrupts.

Assign dclink early and skip connectors where it is NULL.

Fixes the below: drivers/gpu/drm/amd/amdgpu/../display/amdgpudm/amdgpudmirq.c:940 amdgpudmhpdinit() error: we previously assumed 'dclink' could be null (see line 931)

drivers/gpu/drm/amd/amdgpu/../display/amdgpudm/amdgpudmirq.c 923 / 924 Analog connectors may be hot-plugged unlike other connector 925 types that don't support HPD. Only poll analog connectors. 926 / 927 usepolling |= 928 amdgpudmconnector->dclink && ^^^^^^^^^^^^^^^^^^^^^^^^^^^^ The patch adds this NULL check but hopefully it can be removed

929 dcconnectorsupportsanalog(amdgpudmconnector->dclink->linkid.id); 930 931 dclink = amdgpudmconnector->dclink;

dclink assigned here.

932 933 / 934 Get a base driver irq reference for hpd ints for the lifetime 935 of dm. Note that only hpd interrupt types are registered with 936 base driver; hpdrx types aren't. IOW, amdgpuirqget/put on 937 hpdrx isn't available. DM currently controls hpdrx 938 explicitly with dcinterruptset() 939 / --> 940 if (dclink->irqsourcehpd != DCIRQSOURCEINVALID) { ^^^^^^^^^^^^^^^^^^^^^^^ If it's NULL then we are trouble because we dereference it here.

941 irqtype = dclink->irqsourcehpd - DCIRQSOURCEHPD1; 942 / 943 TODO: There's a mismatch between modeinfo.numhpd 944 and what bios reports as the # of connectors with hpd

In the Linux kernel, the following vulnerability has been resolved:

mmc: core: Avoid bitfield RMW for claim/retune flags

Move claimed and retune control flags out of the bitfield word to avoid unrelated RMW side effects in asynchronous contexts.

The host->claimed bit shared a word with retune flags. Writes to claimed in mmcclaimhost() or retunenow in mmcmqqueuerq() can overwrite other bits when concurrent updates happen in other contexts, triggering spurious WARNON(!host->claimed). Convert claimed, canretune, retunenow and retunepaused to bool to remove shared-word coupling.

In the Linux kernel, the following vulnerability has been resolved:

bridge: brndsend: validate ND option lengths

brndsend() walks ND options according to option-provided lengths. A malformed option can make the parser advance beyond the computed option span or use a too-short source LLADDR option payload.

Validate option lengths against the remaining NS option area before advancing, and only read source LLADDR when the option is large enough for an Ethernet address.

HID: alps: fix NULL pointer dereference in alpsrawevent()

In the Linux kernel, the following vulnerability has been resolved:

drm/amdgpu: prevent immediate PASID reuse case

PASID resue could cause interrupt issue when process immediately runs into hw state left by previous process exited with the same PASID, it's possible that page faults are still pending in the IH ring buffer when the process exits and frees up its PASID. To prevent the case, it uses idr cyclic allocator same as kernel pid's.

(cherry picked from commit 8f1de51f49be692de137c8525106e0fce2d1912d)

In the Linux kernel, the following vulnerability has been resolved:

net/sched: clsflow: fix NULL pointer dereference on shared blocks

flowchange() calls tcfblockq() and dereferences q->handle to derive a default baseclass. Shared blocks leave block->q NULL, causing a NULL deref when a flow filter without a fully qualified baseclass is created on a shared block.

Check tcfblockshared() before accessing block->q and return -EINVAL for shared blocks. This avoids the null-deref shown below:

======================================================================= KASAN: null-ptr-deref in range [0x0000000000000038-0x000000000000003f] RIP: 0010:flowchange (net/sched/clsflow.c:508) Call Trace: tcnewtfilter (net/sched/clsapi.c:2432) rtnetlinkrcvmsg (net/core/rtnetlink.c:6980) [...] =======================================================================

In the Linux kernel, the following vulnerability has been resolved:

net/sched: clsfw: fix NULL pointer dereference on shared blocks

The old-method path in fwclassify() calls tcfblockq() and dereferences q->handle. Shared blocks leave block->q NULL, causing a NULL deref when an empty clsfw filter is attached to a shared block and a packet with a nonzero major skb mark is classified.

Reject the configuration in fwchange() when the old method (no TCAOPTIONS) is used on a shared block, since fwclassify()'s old-method path needs block->q which is NULL for shared blocks.

The fixed null-ptr-deref calling stack: KASAN: null-ptr-deref in range [0x0000000000000038-0x000000000000003f] RIP: 0010:fwclassify (net/sched/clsfw.c:81) Call Trace: tcfclassify (./include/net/tcwrapper.h:197 net/sched/clsapi.c:1764 net/sched/clsapi.c:1860) tcrun (net/core/dev.c:4401) devqueuexmit (net/core/dev.c:4535 net/core/dev.c:4790)

In the Linux kernel, the following vulnerability has been resolved:

net: bridge: fix ndtbl NULL dereference when IPv6 is disabled

When booting with the 'ipv6.disable=1' parameter, the ndtbl is never initialized because inet6init() exits before ndiscinit() is called which initializes it. Then, if neighsuppress is enabled and an ICMPv6 Neighbor Discovery packet reaches the bridge, brdosuppressnd() will dereference ipv6stub->ndtbl which is NULL, passing it to neighlookup(). This causes a kernel NULL pointer dereference.

BUG: kernel NULL pointer dereference, address: 0000000000000268 Oops: 0000 [#1] PREEMPT SMP NOPTI [...] RIP: 0010:neighlookup+0x16/0xe0 [...] Call Trace: <IRQ> ? neighlookup+0x16/0xe0 brdosuppressnd+0x160/0x290 [bridge] brhandleframefinish+0x500/0x620 [bridge] brhandleframe+0x353/0x440 [bridge] netifreceiveskbcore.constprop.0+0x298/0x1110 netifreceiveskbonecore+0x3d/0xa0 processbacklog+0xa0/0x140 napipoll+0x2c/0x170 netrxaction+0x2c4/0x3a0 handlesoftirqs+0xd0/0x270 dosoftirq+0x3f/0x60

Fix this by replacing ISENABLED(IPV6) call with ipv6modenabled() in the callers. This is in essence disabling NS/NA suppression when IPv6 is disabled.

In the Linux kernel, the following vulnerability has been resolved:

regmap: Fix race condition in hwspinlock irqsave routine

Previously, the address of the shared member '&map->spinlockflags' was passed directly to 'hwspinlocktimeoutirqsave'. This creates a race condition where multiple contexts contending for the lock could overwrite the shared flags variable, potentially corrupting the state for the current lock owner.

Fix this by using a local stack variable 'flags' to store the IRQ state temporarily.

In the Linux kernel, the following vulnerability has been resolved:

dmaengine: stm32: dmamux: fix device leak on route allocation

Make sure to drop the reference taken when looking up the DMA mux platform device during route allocation.

Note that holding a reference to a device does not prevent its driver data from going away so there is no point in keeping the reference.

ASoC: stm32: sai: fix OF node leak on probe

In the Linux kernel, the following vulnerability has been resolved:

tty: serial: samsungtty: Fix a memory leak in s3c24xxserialgetclk() when iterating clk

When the best clk is searched, we iterate over all possible clk.

If we find a better match, the previous one, if any, needs to be freed. If a better match has already been found, we still need to free the new one, otherwise it leaks.

In the Linux kernel, the following vulnerability has been resolved:

btrfs: output extra debug info if we failed to find an inline backref

[BUG] Syzbot reported several warning triggered inside lookupinlineextentbackref().

[CAUSE] As usual, the reproducer doesn't reliably trigger locally here, but at least we know the WARNON() is triggered when an inline backref can not be found, and it can only be triggered when @insert is true. (I.e. inserting a new inline backref, which means the backref should already exist)

[ENHANCEMENT] After the WARNON(), dump all the parameters and the extent tree leaf to help debug.

In the Linux kernel, the following vulnerability has been resolved:

net: cdcncm: Deal with too low values of dwNtbOutMaxSize

Currently in cdcncmchecktxmax(), if dwNtbOutMaxSize is lower than the calculated "min" value, but greater than zero, the logic sets txmax to dwNtbOutMaxSize. This is then used to allocate a new SKB in cdcncmfilltxframe() where all the data is handled.

For small values of dwNtbOutMaxSize the memory allocated during allocskb(dwNtbOutMaxSize, GFPATOMIC) will have the same size, due to how size is aligned at alloc time: size = SKBDATAALIGN(size); size += SKBDATAALIGN(sizeof(struct skbsharedinfo)); Thus we hit the same bug that we tried to squash with commit 2be6d4d16a084 ("net: cdcncm: Allow for dwNtbOutMaxSize to be unset or zero")

Low values of dwNtbOutMaxSize do not cause an issue presently because at allocskb() time more memory (512b) is allocated than required for the SKB headers alone (320b), leaving some space (512b - 320b = 192b) for CDC data (172b).

However, if more elements (for example 3 x u64 = [24b]) were added to one of the SKB header structs, say 'struct skbsharedinfo', increasing its original size (320b [320b aligned]) to something larger (344b [384b aligned]), then suddenly the CDC data (172b) no longer fits in the spare SKB data area (512b - 384b = 128b).

Consequently the SKB bounds checking semantics fails and panics:

skbuff: skboverpanic: text:ffffffff831f755b len:184 put:172 head:ffff88811f1c6c00 data:ffff88811f1c6c00 tail:0xb8 end:0x80 dev:<NULL> ------------[ cut here ]------------ kernel BUG at net/core/skbuff.c:113! invalid opcode: 0000 [#1] PREEMPT SMP KASAN CPU: 0 PID: 57 Comm: kworker/0:2 Not tainted 5.15.106-syzkaller-00249-g19c0ed55a470 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 04/14/2023 Workqueue: mld mldifcwork RIP: 0010:skbpanic net/core/skbuff.c:113 [inline] RIP: 0010:skboverpanic+0x14c/0x150 net/core/skbuff.c:118 [snip] Call Trace: <TASK> skbput+0x151/0x210 net/core/skbuff.c:2047 skbputzero include/linux/skbuff.h:2422 [inline] cdcncmndp16 drivers/net/usb/cdcncm.c:1131 [inline] cdcncmfilltxframe+0x11ab/0x3da0 drivers/net/usb/cdcncm.c:1308 cdcncmtxfixup+0xa3/0x100

Deal with too low values of dwNtbOutMaxSize, clamp it in the range [USBCDCNCMNTBMINOUTSIZE, CDCNCMNTBMAXSIZETX]. We ensure enough data space is allocated to handle CDC data by making sure dwNtbOutMaxSize is not smaller than USBCDCNCMNTBMINOUTSIZE.

In the Linux kernel, the following vulnerability has been resolved:

spi: bcm-qspi: return error if neither hifmspi nor mspi is available

If neither a "hifmspi" nor "mspi" resource is present, the driver will just early exit in probe but still return success. Apart from not doing anything meaningful, this would then also lead to a null pointer access on removal, as platformgetdrvdata() would return NULL, which it would then try to dereference when trying to unregister the spi master.

Fix this by unconditionally calling devmioremapresource(), as it can handle a NULL res and will then return a viable ERRPTR() if we get one.

The "return 0;" was previously a "goto qspiresourceerr;" where then ret was returned, but since ret was still initialized to 0 at this place this was a valid conversion in 63c5395bb7a9 ("spi: bcm-qspi: Fix use-after-free on unbind"). The issue was not introduced by this commit, only made more obvious.

In the Linux kernel, the following vulnerability has been resolved:

media: solo6x10: fix possible memory leak in solosysfsinit()

If deviceregister() returns error in solosysfsinit(), the name allocated by devsetname() need be freed. As comment of deviceregister() says, it should use putdevice() to give up the reference in the error path. So fix this by calling putdevice(), then the name can be freed in kobjectcleanup().

In the Linux kernel, the following vulnerability has been resolved:

r6040: Fix kmemleak in probe and remove

There is a memory leaks reported by kmemleak:

unreferenced object 0xffff888116111000 (size 2048): comm "modprobe", pid 817, jiffies 4294759745 (age 76.502s) hex dump (first 32 bytes): 00 c4 0a 04 81 88 ff ff 08 10 11 16 81 88 ff ff ................ 08 10 11 16 81 88 ff ff 00 00 00 00 00 00 00 00 ................ backtrace: [<ffffffff815bcd82>] kmalloctrace+0x22/0x60 [<ffffffff827e20ee>] phydevicecreate+0x4e/0x90 [<ffffffff827e6072>] getphydevice+0xd2/0x220 [<ffffffff827e7844>] mdiobusscan+0xa4/0x2e0 [<ffffffff827e8be2>] mdiobusregister+0x482/0x8b0 [<ffffffffa01f5d24>] r6040initone+0x714/0xd2c [r6040] ...

The problem occurs in probe process as follows: r6040initone: mdiobusregister mdiobusscan <- alloc and register phydevice, the reference count of phydevice is 3 r6040miiprobe phyconnect <- connect to the first phydevice, so the reference count of the first phydevice is 4, others are 3 registernetdev <- fault inject succeeded, goto error handling path

// error handling path erroutmdiounregister: mdiobusunregister(lp->miibus); erroutmdio: mdiobusfree(lp->miibus); <- the reference count of the first phydevice is 1, it is not released and other phydevices are released // similarly, the remove process also has the same problem

The root cause is traced to the phydevice is not disconnected when removes one r6040 device in r6040removeone() or on error handling path after r6040mii probed successfully. In r6040miiprobe(), a net ethernet device is connected to the first PHY device of miibus, in order to notify the connected driver when the link status changes, which is the default behavior of the PHY infrastructure to handle everything. Therefore the phydevice should be disconnected when removes one r6040 device or on error handling path.

Fix it by adding phydisconnect() when removes one r6040 device or on error handling path after r6040mii probed successfully.

In the Linux kernel, the following vulnerability has been resolved:

usb: host: xhci: Fix potential memory leak in xhciallocstreaminfo()

xhciallocstreaminfo() allocates stream context array for streaminfo ->streamctxarray with xhciallocstreamctx(). When some error occurs, streaminfo->streamctxarray is not released, which will lead to a memory leak.

We can fix it by releasing the streaminfo->streamctxarray with xhcifreestreamctx() on the error path to avoid the potential memory leak.

In the Linux kernel, the following vulnerability has been resolved:

vme: Fix error not catched in fakeinit()

In fakeinit(), rootdeviceregister() is possible to fail but it's ignored, which can cause unregistering vmeroot fail when exit.

general protection fault, probably for non-canonical address 0xdffffc000000008c KASAN: null-ptr-deref in range [0x0000000000000460-0x0000000000000467] RIP: 0010:rootdeviceunregister+0x26/0x60 Call Trace: <TASK> x64sysdeletemodule+0x34f/0x540 dosyscall64+0x38/0x90 entrySYSCALL64afterhwframe+0x63/0xcd

Return error when rootdeviceregister() fails.

In the Linux kernel, the following vulnerability has been resolved:

drm/amd/display: Fix potential null-deref in dmresume

[Why] Fixing smatch error: dmresume() error: we previously assumed 'aconnector->dclink' could be null

[How] Check if dclink null at the beginning of the loop, so further checks can be dropped.

In the Linux kernel, the following vulnerability has been resolved:

fbdev: omapfb: lcdmipid: Fix an error handling path in mipidspiprobe()

If 'mipiddetect()' fails, we must free 'md' to avoid a memory leak.

In the Linux kernel, the following vulnerability has been resolved:

ALSA: ac97: Fix possible NULL dereference in sndac97mixer

smatch error: sound/pci/ac97/ac97codec.c:2354 sndac97mixer() error: we previously assumed 'rac97' could be null (see line 2072)

remove redundant assignment, return error if rac97 is NULL.

In the Linux kernel, the following vulnerability has been resolved:

media: radio-shark: Add endpoint checks

The syzbot fuzzer was able to provoke a WARNING from the radio-shark2 driver:

------------[ cut here ]------------ usb 1-1: BOGUS urb xfer, pipe 1 != type 3 WARNING: CPU: 0 PID: 3271 at drivers/usb/core/urb.c:504 usbsubmiturb+0xed2/0x1880 drivers/usb/core/urb.c:504 Modules linked in: CPU: 0 PID: 3271 Comm: kworker/0:3 Not tainted 6.1.0-rc4-syzkaller #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 10/26/2022 Workqueue: usbhubwq hubevent RIP: 0010:usbsubmiturb+0xed2/0x1880 drivers/usb/core/urb.c:504 Code: 7c 24 18 e8 00 36 ea fb 48 8b 7c 24 18 e8 36 1c 02 ff 41 89 d8 44 89 e1 4c 89 ea 48 89 c6 48 c7 c7 a0 b6 90 8a e8 9a 29 b8 03 <0f> 0b e9 58 f8 ff ff e8 d2 35 ea fb 48 81 c5 c0 05 00 00 e9 84 f7 RSP: 0018:ffffc90003876dd0 EFLAGS: 00010282 RAX: 0000000000000000 RBX: 0000000000000003 RCX: 0000000000000000 RDX: ffff8880750b0040 RSI: ffffffff816152b8 RDI: fffff5200070edac RBP: ffff8880172d81e0 R08: 0000000000000005 R09: 0000000000000000 R10: 0000000080000000 R11: 0000000000000000 R12: 0000000000000001 R13: ffff8880285c5040 R14: 0000000000000002 R15: ffff888017158200 FS: 0000000000000000(0000) GS:ffff8880b9a00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007ffe03235b90 CR3: 000000000bc8e000 CR4: 00000000003506f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: <TASK> usbstartwaiturb+0x101/0x4b0 drivers/usb/core/message.c:58 usbbulkmsg+0x226/0x550 drivers/usb/core/message.c:387 sharkwritereg+0x1ff/0x2e0 drivers/media/radio/radio-shark2.c:88 ...

The problem was caused by the fact that the driver does not check whether the endpoints it uses are actually present and have the appropriate types. This can be fixed by adding a simple check of these endpoints (and similarly for the radio-shark driver).

In the Linux kernel, the following vulnerability has been resolved:

wifi: ath6kl: reduce WARN to devdbg() in callback

The warn is triggered on a known race condition, documented in the code above the test, that is correctly handled. Using WARN() hinders automated testing. Reducing severity.

In the Linux kernel, the following vulnerability has been resolved:

mm/swap: fix swapinfostruct race between swapoff and getswappages()

The si->lock must be held when deleting the si from the available list. Otherwise, another thread can re-add the si to the available list, which can lead to memory corruption. The only place we have found where this happens is in the swapoff path. This case can be described as below:

core 0 core 1 swapoff

delfromavaillist(si) waiting

try lock si->lock acquire swapavaillock and re-add si into swapavailhead

acquire si->lock but missing si already being added again, and continuing to clear SWPWRITEOK, etc.

It can be easily found that a massive warning messages can be triggered inside getswappages() by some special cases, for example, we call madvise(MADVPAGEOUT) on blocks of touched memory concurrently, meanwhile, run much swapon-swapoff operations (e.g. stress-ng-swap).

However, in the worst case, panic can be caused by the above scene. In swapoff(), the memory used by si could be kept in swapinfo[] after turning off a swap. This means memory corruption will not be caused immediately until allocated and reset for a new swap in the swapon path. A panic message caused: (with CONFIGPLISTDEBUG enabled)

------------[ cut here ]------------ top: 00000000e58a3003, n: 0000000013e75cda, p: 000000008cd4451a prev: 0000000035b1e58a, n: 000000008cd4451a, p: 000000002150ee8d next: 000000008cd4451a, n: 000000008cd4451a, p: 000000008cd4451a WARNING: CPU: 21 PID: 1843 at lib/plist.c:60 plistcheckprevnextnode+0x50/0x70 Modules linked in: rfkill(E) crct10difce(E)... CPU: 21 PID: 1843 Comm: stress-ng Kdump: ... 5.10.134+ Hardware name: Alibaba Cloud ECS, BIOS 0.0.0 02/06/2015 pstate: 60400005 (nZCv daif +PAN -UAO -TCO BTYPE=--) pc : plistcheckprevnextnode+0x50/0x70 lr : plistcheckprevnextnode+0x50/0x70 sp : ffff0018009d3c30 x29: ffff0018009d3c40 x28: ffff800011b32a98 x27: 0000000000000000 x26: ffff001803908000 x25: ffff8000128ea088 x24: ffff800011b32a48 x23: 0000000000000028 x22: ffff001800875c00 x21: ffff800010f9e520 x20: ffff001800875c00 x19: ffff001800fdc6e0 x18: 0000000000000030 x17: 0000000000000000 x16: 0000000000000000 x15: 0736076307640766 x14: 0730073007380731 x13: 0736076307640766 x12: 0730073007380731 x11: 000000000004058d x10: 0000000085a85b76 x9 : ffff8000101436e4 x8 : ffff800011c8ce08 x7 : 0000000000000000 x6 : 0000000000000001 x5 : ffff0017df9ed338 x4 : 0000000000000001 x3 : ffff8017ce62a000 x2 : ffff0017df9ed340 x1 : 0000000000000000 x0 : 0000000000000000 Call trace: plistcheckprevnextnode+0x50/0x70 plistcheckhead+0x80/0xf0 plistadd+0x28/0x140 addtoavaillist+0x9c/0xf0 enableswapinfo+0x78/0xb4 dosysswapon+0x918/0xa10 arm64sysswapon+0x20/0x30 el0svccommon+0x8c/0x220 doel0svc+0x2c/0x90 el0svc+0x1c/0x30 el0synchandler+0xa8/0xb0 el0sync+0x148/0x180 irq event stamp: 2082270

Now, si->lock locked before calling 'delfromavaillist()' to make sure other thread see the si had been deleted and SWPWRITEOK cleared together, will not reinsert again.

This problem exists in versions after stable 5.10.y.

In the Linux kernel, the following vulnerability has been resolved:

dm thin: Use last transaction's pmd->root when commit failed

Recently we found a softlock up problem in dm thin pool btree lookup code due to corrupted metadata:

Kernel panic - not syncing: softlockup: hung tasks CPU: 7 PID: 2669225 Comm: kworker/u16:3 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996) Workqueue: dm-thin doworker [dmthinpool] Call Trace: <IRQ> dumpstack+0x9c/0xd3 panic+0x35d/0x6b9 watchdogtimerfn.cold+0x16/0x25 runhrtimer+0xa2/0x2d0 </IRQ> RIP: 0010:relinklru+0x102/0x220 [dmbufio] bufionew+0x11f/0x4f0 [dmbufio] newread+0xa3/0x1e0 [dmbufio] dmbmreadlock+0x33/0xd0 [dmpersistentdata] rostep+0x63/0x100 [dmpersistentdata] btreelookupraw.constprop.0+0x44/0x220 [dmpersistentdata] dmbtreelookup+0x16f/0x210 [dmpersistentdata] dmthinfindblock+0x12c/0x210 [dmthinpool] processbioreadonly+0xc5/0x400 [dmthinpool] processthindeferredbios+0x1a4/0x4a0 [dmthinpool] processonework+0x3c5/0x730

Following process may generate a broken btree mixed with fresh and stale btree nodes, which could get dm thin trapped in an infinite loop while looking up data block: Transaction 1: pmd->root = A, A->B->C // One path in btree pmd->root = X, X->Y->Z // Copy-up Transaction 2: X,Z is updated on disk, Y write failed. // Commit failed, dm thin becomes read-only. processbioreadonly dmthinfindblock findblock dmbtreelookup(pmd->root) The pmd->root points to a broken btree, Y may contain stale node pointing to any block, for example X, which gets dm thin trapped into a dead loop while looking up Z.

Fix this by setting pmd->root in openmetadata(), so that dm thin will use the last transaction's pmd->root if commit failed.

Fetch a reproducer in [Link].

Linke: https://bugzilla.kernel.org/showbug.cgi?id=216790

In the Linux kernel, the following vulnerability has been resolved:

testfirmware: fix memory leak in testfirmwareinit()

When miscregister() failed in testfirmwareinit(), the memory pointed by testfwconfig->name is not released. The memory leak information is as follows: unreferenced object 0xffff88810a34cb00 (size 32): comm "insmod", pid 7952, jiffies 4294948236 (age 49.060s) hex dump (first 32 bytes): 74 65 73 74 2d 66 69 72 6d 77 61 72 65 2e 62 69 test-firmware.bi 6e 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 n............... backtrace: [<ffffffff81b21fcb>] kmallocnodetrackcaller+0x4b/0xc0 [<ffffffff81affb96>] kstrndup+0x46/0xc0 [<ffffffffa0403a49>] testfirmwareconfiginit+0x29/0x380 [testfirmware] [<ffffffffa040f068>] 0xffffffffa040f068 [<ffffffff81002c41>] dooneinitcall+0x141/0x780 [<ffffffff816a72c3>] doinitmodule+0x1c3/0x630 [<ffffffff816adb9e>] loadmodule+0x623e/0x76a0 [<ffffffff816af471>] dosysfinitmodule+0x181/0x240 [<ffffffff89978f99>] dosyscall64+0x39/0xb0 [<ffffffff89a0008b>] entrySYSCALL64afterhwframe+0x63/0xcd

In the Linux kernel, the following vulnerability has been resolved:

iommu/fslpamu: Fix resource leak in fslpamuprobe()

The fslpamuprobe() returns directly when createcsd() failed, leaving irq and memories unreleased. Fix by jumping to error if createcsd() returns error.

In the Linux kernel, the following vulnerability has been resolved:

clk: rockchip: Fix memory leak in rockchipclkregisterpll()

If clkregister() fails, @pll->ratetable may have allocated memory by kmemdup(), so it needs to be freed, otherwise will cause memory leak issue, this patch fixes it.