btrfs: zoned: clone zoned device info when cloning a device

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

can: mcan: pci: add missing mcanclassfreedev() in probe/remove methods

In mcanpciremove() and error handling path of mcanpciprobe(), mcanclassfreedev() should be called to free resource allocated by mcanclassallocatedev(), otherwise there will be memleak.

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

can: j1939: j1939sendone(): fix missing CAN header initialization

The read access to struct canxlframe::len inside of a j1939 created skbuff revealed a missing initialization of reserved and later filled elements in struct canframe.

This patch initializes the 8 byte CAN header with zero.

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

netdevsim: Fix memory leak of nsimdev->facookie

kmemleak reports this issue:

unreferenced object 0xffff8881bac872d0 (size 8): comm "sh", pid 58603, jiffies 4481524462 (age 68.065s) hex dump (first 8 bytes): 04 00 00 00 de ad be ef ........ backtrace: [<00000000c80b8577>] kmalloc+0x49/0x150 [<000000005292b8c6>] nsimdevtrapfacookiewrite+0xc1/0x210 [netdevsim] [<0000000093d78e77>] fullproxywrite+0xf3/0x180 [<000000005a662c16>] vfswrite+0x1c5/0xaf0 [<000000007aabf84a>] ksyswrite+0xed/0x1c0 [<000000005f1d2e47>] dosyscall64+0x3b/0x90 [<000000006001c6ec>] entrySYSCALL64afterhwframe+0x63/0xcd

The issue occurs in the following scenarios:

nsimdevtrapfacookiewrite() kmalloc() facookie nsimdev->facookie = facookie .. nsimdrvremove()

The facookie allocked in nsimdevtrapfacookiewrite() is not freed. To fix, add kfree(nsimdev->facookie) to nsimdrvremove().

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

misc/vmwvmci: fix an infoleak in vmcihostdoreceivedatagram()

struct vmcieventqp allocated by qpnotifypeer() contains padding, which may carry uninitialized data to the userspace, as observed by KMSAN:

BUG: KMSAN: kernel-infoleak in instrumentcopytouser ./include/linux/instrumented.h:121 instrumentcopytouser ./include/linux/instrumented.h:121 copytouser+0x5f/0xb0 lib/usercopy.c:33 copytouser ./include/linux/uaccess.h:169 vmcihostdoreceivedatagram drivers/misc/vmwvmci/vmcihost.c:431 vmcihostunlockedioctl+0x33d/0x43d0 drivers/misc/vmwvmci/vmcihost.c:925 vfsioctl fs/ioctl.c:51 ...

Uninit was stored to memory at: kmemdup+0x74/0xb0 mm/util.c:131 dgdispatchashost drivers/misc/vmwvmci/vmcidatagram.c:271 vmcidatagramdispatch+0x4f8/0xfc0 drivers/misc/vmwvmci/vmcidatagram.c:339 qpnotifypeer+0x19a/0x290 drivers/misc/vmwvmci/vmciqueuepair.c:1479 qpbrokerattach drivers/misc/vmwvmci/vmciqueuepair.c:1662 qpbrokeralloc+0x2977/0x2f30 drivers/misc/vmwvmci/vmciqueuepair.c:1750 vmciqpbrokeralloc+0x96/0xd0 drivers/misc/vmwvmci/vmciqueuepair.c:1940 vmcihostdoallocqueuepair drivers/misc/vmwvmci/vmcihost.c:488 vmcihostunlockedioctl+0x24fd/0x43d0 drivers/misc/vmwvmci/vmcihost.c:927 ...

Local variable ev created at: qpnotifypeer+0x54/0x290 drivers/misc/vmwvmci/vmciqueuepair.c:1456 qpbrokerattach drivers/misc/vmwvmci/vmciqueuepair.c:1662 qpbrokeralloc+0x2977/0x2f30 drivers/misc/vmwvmci/vmciqueuepair.c:1750

Bytes 28-31 of 48 are uninitialized Memory access of size 48 starts at ffff888035155e00 Data copied to user address 0000000020000100

Use memset() to prevent the infoleaks.

Also speculatively fix qpnotifypeerlocal(), which may suffer from the same problem.

A NULL pointer dereference flaw was found in the Linux kernel AMD Sensor Fusion Hub driver. This flaw allows a local user to crash the system.

A NULL pointer dereference flaw was found in the Linux kernel's drivers/gpu/drm/msm/msmgemsubmit.c code in the submitlookupcmds function, which fails because it lacks a check of the return value of kmalloc(). This issue allows a local user to crash the system.

Bluetooth: virtiobt: validate rx pkttype header length

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

cifs: Fix connections leak when tlink setup failed

If the tlink setup failed, lost to put the connections, then the module refcnt leak since the cifsd kthread not exit.

Also leak the fscache info, and for next mount with fsc, it will print the follow errors: CIFS: Cache volume key already in use (cifs,127.0.0.1:445,TEST)

Let's check the result of tlink setup, and do some cleanup.

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

clk: rs9: Fix suspend/resume

Disabling the cache in commit 2ff4ba9e3702 ("clk: rs9: Fix I2C accessors") without removing cache synchronization in resume path results in a kernel panic as map->cacheops is unset, due to REGCACHENONE. Enable flat cache again to support resume again. numregdefaultsraw is necessary to read the cache defaults from hardware. Some registers are strapped in hardware and cannot be provided in software.

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

bpf, sockmap: Fix the sk->skforwardalloc warning of skstreamkillqueues

When running testsockmap selftests, the following warning appears:

WARNING: CPU: 2 PID: 197 at net/core/stream.c:205 skstreamkillqueues+0xd3/0xf0 Call Trace: <TASK> inetcskdestroysock+0x55/0x110 tcprcvstateprocess+0xd28/0x1380 ? tcpv4dorcv+0x77/0x2c0 tcpv4dorcv+0x77/0x2c0 releasesock+0x106/0x130 tcpclose+0x1a7/0x4e0 tcpclose+0x20/0x70 inetrelease+0x3c/0x80 sockrelease+0x3a/0xb0 sockclose+0x14/0x20 fput+0xa3/0x260 taskworkrun+0x59/0xb0 exittousermodeprepare+0x1b3/0x1c0 syscallexittousermode+0x19/0x50 dosyscall64+0x48/0x90 entrySYSCALL64afterhwframe+0x44/0xae

The root case is in commit 84472b436e76 ("bpf, sockmap: Fix more uncharged while msg has moredata"), where I used msg->sg.size to replace the tosend, causing breakage:

if (msg->applybytes && msg->applybytes < tosend) tosend = psock->applybytes;

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

tipc: fix the msg->req tlv len check in tipcnlcompatnametabledumpheader

This is a follow-up for commit 974cb0e3e7c9 ("tipc: fix uninit-value in tipcnlcompatnametabledump") where it should have type casted sizeof(..) to int to work when TLVGETDATALEN() returns a negative value.

syzbot reported a call trace because of it:

BUG: KMSAN: uninit-value in ... tipcnlcompatnametabledump+0x841/0xea0 net/tipc/netlinkcompat.c:934 tipcnlcompatdumpit+0xab2/0x1320 net/tipc/netlinkcompat.c:238 tipcnlcompatdumpit+0x991/0xb50 net/tipc/netlinkcompat.c:321 tipcnlcompatrecv+0xb6e/0x1640 net/tipc/netlinkcompat.c:1324 genlfamilyrcvmsgdoit net/netlink/genetlink.c:731 [inline] genlfamilyrcvmsg net/netlink/genetlink.c:775 [inline] genlrcvmsg+0x103f/0x1260 net/netlink/genetlink.c:792 netlinkrcvskb+0x3a5/0x6c0 net/netlink/afnetlink.c:2501 genlrcv+0x3c/0x50 net/netlink/genetlink.c:803 netlinkunicastkernel net/netlink/afnetlink.c:1319 [inline] netlinkunicast+0xf3b/0x1270 net/netlink/afnetlink.c:1345 netlinksendmsg+0x1288/0x1440 net/netlink/afnetlink.c:1921 socksendmsgnosec net/socket.c:714 [inline] socksendmsg net/socket.c:734 [inline]

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

dmaengine: mvxorv2: Fix a resource leak in mvxorv2remove()

A clkprepareenable() call in the probe is not balanced by a corresponding clkdisableunprepare() in the remove function.

Add the missing call.

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

btrfs: fix match incorrectly in devargsmatchdevice

syzkaller found a failed assertion:

assertion failed: (args->devid != (u64)-1) || args->missing, in fs/btrfs/volumes.c:6921

This can be triggered when we set devid to (u64)-1 by ioctl. In this case, the match of devid will be skipped and the match of device may succeed incorrectly.

Patch 562d7b1512f7 introduced this function which is used to match device. This function contains two matching scenarios, we can distinguish them by checking the value of args->missing rather than check whether args->devid and args->uuid is default value.

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

net/x25: Fix skb leak in x25lapbreceiveframe()

x25lapbreceiveframe() using skbcopy() to get a private copy of skb, the new skb should be freed in the undersized/fragmented skb error handling path. Otherwise there is a memory leak.

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

tracing: Fix memory leak in tracingreadpipe()

kmemleak reports this issue:

unreferenced object 0xffff888105a18900 (size 128): comm "testprogs", pid 18933, jiffies 4336275356 (age 22801.766s) hex dump (first 32 bytes): 25 73 00 90 81 88 ff ff 26 05 00 00 42 01 58 04 %s......&...B.X. 03 00 00 00 02 00 00 00 00 00 00 00 00 00 00 00 ................ backtrace: [<00000000560143a1>] kmallocnodetrackcaller+0x4a/0x140 [<000000006af00822>] krealloc+0x8d/0xf0 [<00000000c309be6a>] traceiterexpandformat+0x99/0x150 [<000000005a53bdb6>] tracecheckvprintf+0x1e0/0x11d0 [<0000000065629d9d>] traceeventprintf+0xb6/0xf0 [<000000009a690dc7>] tracerawoutputbpftraceprintk+0x89/0xc0 [<00000000d22db172>] printtraceline+0x73c/0x1480 [<00000000cdba76ba>] tracingreadpipe+0x45c/0x9f0 [<0000000015b58459>] vfsread+0x17b/0x7c0 [<000000004aeee8ed>] ksysread+0xed/0x1c0 [<0000000063d3d898>] dosyscall64+0x3b/0x90 [<00000000a06dda7f>] entrySYSCALL64afterhwframe+0x63/0xcd

iter->fmt alloced in tracingreadpipe() -> .. ->traceiterexpandformat(), but not freed, to fix, add free in tracingreleasepipe()

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

Input: i8042 - fix leaking of platform device on module removal

Avoid resetting the module-wide i8042platformdevice pointer in i8042probe() or i8042remove(), so that the device can be properly destroyed by i8042exit() on module unload.

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

mptcp: fix sleep in atomic at close time

Matt reported a splat at msk close time:

BUG: sleeping function called from invalid context at net/mptcp/protocol.c:2877 inatomic(): 1, irqsdisabled(): 0, nonblock: 0, pid: 155, name: packetdrill preemptcount: 201, expected: 0 RCU nest depth: 0, expected: 0 4 locks held by packetdrill/155: #0: ffff888001536990 (&sb->stype->imutexkey#6){+.+.}-{3:3}, at: sockrelease (net/socket.c:650) #1: ffff88800b498130 (sklock-AFINET){+.+.}-{0:0}, at: mptcpclose (net/mptcp/protocol.c:2973) #2: ffff88800b49a130 (sklock-AFINET/1){+.+.}-{0:0}, at: mptcpclosessk (net/mptcp/protocol.c:2363) #3: ffff88800b49a0b0 (slock-AFINET){+...}-{2:2}, at: locksockfast (include/net/sock.h:1820) Preemption disabled at: 0x0 CPU: 1 PID: 155 Comm: packetdrill Not tainted 6.1.0-rc5 #365 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014 Call Trace: <TASK> dumpstacklvl (lib/dumpstack.c:107 (discriminator 4)) mightresched.cold (kernel/sched/core.c:9891) mptcpdestroysock (include/linux/kernel.h:110) mptcpclose (net/mptcp/protocol.c:2959) mptcpsubflowqueueclean (include/net/sock.h:1777) mptcpclosessk (net/mptcp/protocol.c:2363) mptcpdestroycommon (net/mptcp/protocol.c:3170) mptcpdestroy (include/net/sock.h:1495) mptcpdestroysock (net/mptcp/protocol.c:2886) mptcpclose (net/mptcp/protocol.c:2959) mptcpclose (net/mptcp/protocol.c:2974) inetrelease (net/ipv4/afinet.c:432) sockrelease (net/socket.c:651) sockclose (net/socket.c:1367) fput (fs/filetable.c:320) taskworkrun (kernel/taskwork.c:181 (discriminator 1)) exittousermodeprepare (include/linux/resumeusermode.h:49) syscallexittousermode (kernel/entry/common.c:130) dosyscall64 (arch/x86/entry/common.c:87) entrySYSCALL64afterhwframe (arch/x86/entry/entry64.S:120)

We can't call mptcpclose under the 'fast' socket lock variant, replace it with a socklocknested() as the relevant code is already under the listening msk socket lock protection.

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

ASoC: ops: Fix bounds check for sx controls

For sx controls the semantics of the max field is not the usual one, max is the number of steps rather than the maximum value. This means that our check in sndsocputvolswsx() needs to just check against the maximum value.

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

can: afcan: fix NULL pointer dereference in canrcvfilter

Analogue to commit 8aa59e355949 ("can: afcan: fix NULL pointer dereference in canrxregister()") we need to check for a missing initialization of mlpriv in the receive path of CAN frames.

Since commit 4e096a18867a ("net: introduce CAN specific pointer in the struct netdevice") the check for dev->type to be ARPHRDCAN is not sufficient anymore since bonding or tun netdevices claim to be CAN devices but do not initialize mlpriv accordingly.

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

wifi: cfg80211: fix memory leak in queryregdbfile()

In the function queryregdbfile() the alpha2 parameter is duplicated using kmemdup() and subsequently freed in regdbfwcb(). However, requestfirmwarenowait() can fail without calling regdbfwcb() and thus leak memory.

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

bpf, verifier: Fix memory leak in array reallocation for stack state

If an error (NULL) is returned by krealloc(), callers of reallocarray() were setting their allocation pointers to NULL, but on error krealloc() does not touch the original allocation. This would result in a memory resource leak. Instead, free the old allocation on the error handling path.

The memory leak information is as follows as also reported by Zhengchao:

unreferenced object 0xffff888019801800 (size 256): comm "bpfrepo", pid 6490, jiffies 4294959200 (age 17.170s) hex dump (first 32 bytes): 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ backtrace: [<00000000b211474b>] kmallocnodetrackcaller+0x45/0xc0 [<0000000086712a0b>] krealloc+0x83/0xd0 [<00000000139aab02>] reallocarray+0x82/0xe2 [<00000000b1ca41d1>] growstackstate+0xfb/0x186 [<00000000cd6f36d2>] checkmemaccess.cold+0x141/0x1341 [<0000000081780455>] docheckcommon+0x5358/0xb350 [<0000000015f6b091>] bpfcheck.cold+0xc3/0x29d [<000000002973c690>] bpfprogload+0x13db/0x2240 [<00000000028d1644>] sysbpf+0x1605/0x4ce0 [<00000000053f29bd>] x64sysbpf+0x75/0xb0 [<0000000056fedaf5>] dosyscall64+0x35/0x80 [<000000002bd58261>] entrySYSCALL64afterhwframe+0x63/0xcd

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

wifi: mac80211: fix general-protection-fault in ieee80211subifstartxmit()

When device is running and the interface status is changed, the gpf issue is triggered. The problem triggering process is as follows: Thread A: Thread B ieee80211runtimechangeiftype() processonework() ... ... ieee80211dostop() ... ... ... sdata->bss = NULL ... ... ieee80211subifstartxmit() ieee80211multicasttounicast //!sdata->bss->multicasttounicast cause gpf issue

When the interface status is changed, the sending queue continues to send packets. After the bss is set to NULL, the bss is accessed. As a result, this causes a general-protection-fault issue.

The following is the stack information: general protection fault, probably for non-canonical address 0xdffffc000000002f: 0000 [#1] PREEMPT SMP KASAN KASAN: null-ptr-deref in range [0x0000000000000178-0x000000000000017f] Workqueue: mld mldifcwork RIP: 0010:ieee80211subifstartxmit+0x25b/0x1310 Call Trace: <TASK> devhardstartxmit+0x1be/0x990 devqueuexmit+0x2c9a/0x3b60 ip6finishoutput2+0xf92/0x1520 ip6finishoutput+0x6af/0x11e0 ip6output+0x1ed/0x540 mldsendpack+0xa09/0xe70 mldifcwork+0x71c/0xdb0 processonework+0x9bf/0x1710 workerthread+0x665/0x1080 kthread+0x2e4/0x3a0 retfromfork+0x1f/0x30 </TASK>

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

bpftool: Fix NULL pointer dereference when pin {PROG, MAP, LINK} without FILE

When using bpftool to pin {PROG, MAP, LINK} without FILE, segmentation fault will occur. The reson is that the lack of FILE will cause strlen to trigger NULL pointer dereference. The corresponding stacktrace is shown below:

dopin dopinany dopinfd mountbpffsforpin strlen(name) <- NULL pointer dereference

Fix it by adding validation to the common process.

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

HID: hyperv: fix possible memory leak in mousevscprobe()

If hidadddevice() returns error, it should call hiddestroydevice() to free hiddev which is allocated in hidallocatedevice().

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

bpf: Fix wrong reg type conversion in releasereference()

Some helper functions will allocate memory. To avoid memory leaks, the verifier requires the eBPF program to release these memories by calling the corresponding helper functions.

When a resource is released, all pointer registers corresponding to the resource should be invalidated. The verifier use releasereferences() to do this job, by apply markregunknown() to each relevant register.

It will give these registers the type of SCALARVALUE. A register that will contain a pointer value at runtime, but of type SCALARVALUE, which may allow the unprivileged user to get a kernel pointer by storing this register into a map.

Using markregnotinit() while NOT allowptrleaks can mitigate this problem.

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

net: tun: Fix memory leaks of napigetfrags

kmemleak reports after running testprogs:

unreferenced object 0xffff8881b1672dc0 (size 232): comm "testprogs", pid 394388, jiffies 4354712116 (age 841.975s) hex dump (first 32 bytes): e0 84 d7 a8 81 88 ff ff 80 2c 67 b1 81 88 ff ff .........,g..... 00 40 c5 9b 81 88 ff ff 00 00 00 00 00 00 00 00 .@.............. backtrace: [<00000000c8f01748>] napiskbcacheget+0xd4/0x150 [<0000000041c7fc09>] napibuildskb+0x15/0x50 [<00000000431c7079>] napiallocskb+0x26e/0x540 [<000000003ecfa30e>] napigetfrags+0x59/0x140 [<0000000099b2199e>] tungetuser+0x183d/0x3bb0 [tun] [<000000008a5adef0>] tunchrwriteiter+0xc0/0x1b1 [tun] [<0000000049993ff4>] doiterreadvwritev+0x19f/0x320 [<000000008f338ea2>] doiterwrite+0x135/0x630 [<000000008a3377a4>] vfswritev+0x12e/0x440 [<00000000a6b5639a>] dowritev+0x104/0x280 [<00000000ccf065d8>] dosyscall64+0x3b/0x90 [<00000000d776e329>] entrySYSCALL64afterhwframe+0x63/0xcd

The issue occurs in the following scenarios: tungetuser() napigrofrags() napifragsfinish() case GRONORMAL: gronormalone() listaddtail(&skb->list, &napi->rxlist); <-- While napi->rxcount < READONCE(gronormalbatch), <-- gronormallist() is not called, napi->rxlist is not empty <-- not ask to complete the gro work, will cause memory leaks in <-- following tunnapidel() ... tunnapidel() netifnapidel() netifnapidel() <-- &napi->rxlist is not empty, which caused memory leaks

To fix, add napicomplete() after napigrofrags().

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

bnxten: Fix possible crash in bnxthwrmsetcoal()

During the error recovery sequence, the rtnllock is not held for the entire duration and some datastructures may be freed during the sequence. Check for the BNXTSTATEOPEN flag instead of netifrunning() to ensure that the device is fully operational before proceeding to reconfigure the coalescing settings.

This will fix a possible crash like this:

BUG: unable to handle kernel NULL pointer dereference at 0000000000000000 PGD 0 P4D 0 Oops: 0000 [#1] SMP NOPTI CPU: 10 PID: 181276 Comm: ethtool Kdump: loaded Tainted: G IOE --------- - - 4.18.0-348.el8.x8664 #1 Hardware name: Dell Inc. PowerEdge R740/0F9N89, BIOS 2.3.10 08/15/2019 RIP: 0010:bnxthwrmsetcoal+0x1fb/0x2a0 [bnxten] Code: c2 66 83 4e 22 08 66 89 46 1c e8 10 cb 00 00 41 83 c6 01 44 39 b3 68 01 00 00 0f 8e a3 00 00 00 48 8b 93 c8 00 00 00 49 63 c6 <48> 8b 2c c2 48 8b 85 b8 02 00 00 48 85 c0 74 2e 48 8b 74 24 08 f6 RSP: 0018:ffffb11c8dcaba50 EFLAGS: 00010246 RAX: 0000000000000000 RBX: ffff8d168a8b0ac0 RCX: 00000000000000c5 RDX: 0000000000000000 RSI: ffff8d162f72c000 RDI: ffff8d168a8b0b28 RBP: 0000000000000000 R08: b6e1f68a12e9a7eb R09: 0000000000000000 R10: 0000000000000001 R11: 0000000000000037 R12: ffff8d168a8b109c R13: ffff8d168a8b10aa R14: 0000000000000000 R15: ffffffffc01ac4e0 FS: 00007f3852e4c740(0000) GS:ffff8d24c0080000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000000 CR3: 000000041b3ee003 CR4: 00000000007706e0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 PKRU: 55555554 Call Trace: ethnlsetcoalesce+0x3ce/0x4c0 genlfamilyrcvmsgdoit.isra.15+0x10f/0x150 genlfamilyrcvmsg+0xb3/0x160 ? coalescefillreply+0x480/0x480 genlrcvmsg+0x47/0x90 ? genlfamilyrcvmsg+0x160/0x160 netlinkrcvskb+0x4c/0x120 genlrcv+0x24/0x40 netlinkunicast+0x196/0x230 netlinksendmsg+0x204/0x3d0 socksendmsg+0x4c/0x50 syssendto+0xee/0x160 ? syscalltraceenter+0x1d3/0x2c0 ? auditsyscallexit+0x249/0x2a0 x64syssendto+0x24/0x30 dosyscall64+0x5b/0x1a0 entrySYSCALL64afterhwframe+0x65/0xca RIP: 0033:0x7f38524163bb

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

phy: ralink: mt7621-pci: add sentinel to quirks table

With mt7621 socdevattr fixed to register the soc as a device, kernel will experience an oops in socdevicematchattr

This quirk test was introduced in the staging driver in commit 9445ccb3714c ("staging: mt7621-pci-phy: add quirks for 'E2' revision using 'socdeviceattribute'"). The staging driver was removed, and later re-added in commit d87da32372a0 ("phy: ralink: Add PHY driver for MT7621 PCIe PHY") for kernel 5.11

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

net: wwan: iosm: fix memory leak in ipcwwandellink

IOSM driver registers network device without setting the needsfreenetdev flag, and does NOT call freenetdev() when unregisters network device, which causes a memory leak.

This patch sets needsfreenetdev to true when registers network device, which makes netdev subsystem call freenetdev() automatically after unregisternetdevice().