Bluetooth: virtiobt: validate rx pkttype header length

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:

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:

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:

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:

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().

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: mhi: fix memory leak in mhimbimdellink

MHI 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().

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: ti: k3-udma-glue: fix memory leak when register device fail

If deviceregister() fails, it should call putdevice() to give up reference, the name allocated in devsetname() can be freed in callback function kobjectcleanup().

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:

net: marvell: prestera: fix memory leak in presterarxtxswitchinit()

When presterasdmaswitchinit() failed, the memory pointed to by sw->rxtx isn't released. Fix it. Only be compiled, not be tested.

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

net: wwan: iosm: fix memory leak in ipcpciereadbioscfg

ipcpciereadbioscfg() is using the acpievaluatedsm() to obtain the wwan power state configuration from BIOS but is not freeing the acpiobject. The acpievaluatedsm() returned acpiobject to be freed.

Free the acpiobject after use.

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

mctp: Fix an error handling path in mctpinit()

If mctpneighinit() return error, the routes resources should be released in the error handling path. Otherwise some resources leak.

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

net: macvlan: fix memory leaks of macvlancommonnewlink

kmemleak reports memory leaks in macvlancommonnewlink, as follows:

ip link add link eth0 name .. type macvlan mode source macaddr add <MAC-ADDR>

kmemleak reports:

unreferenced object 0xffff8880109bb140 (size 64): comm "ip", pid 284, jiffies 4294986150 (age 430.108s) hex dump (first 32 bytes): 00 00 00 00 00 00 00 00 b8 aa 5a 12 80 88 ff ff ..........Z..... 80 1b fa 0d 80 88 ff ff 1e ff ac af c7 c1 6b 6b ..............kk backtrace: [<ffffffff813e06a7>] kmemcachealloctrace+0x1c7/0x300 [<ffffffff81b66025>] macvlanhashaddsource+0x45/0xc0 [<ffffffff81b66a67>] macvlanchangelinksources+0xd7/0x170 [<ffffffff81b6775c>] macvlancommonnewlink+0x38c/0x5a0 [<ffffffff81b6797e>] macvlannewlink+0xe/0x20 [<ffffffff81d97f8f>] rtnlnewlink+0x7af/0xa50 [<ffffffff81d98278>] rtnlnewlink+0x48/0x70 ...

In the scenario where the macvlan mode is configured as 'source', macvlanchangelinksources() will be execured to reconfigure list of remote source mac addresses, at the same time, if registernetdevice() return an error, the resource generated by macvlanchangelinksources() is not cleaned up.

Using this patch, in the case of an error, it will execute macvlanflushsources() to ensure that the resource is cleaned up.

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

nilfs2: fix deadlock in nilfscountfreeblocks()

A semaphore deadlock can occur if nilfsgetblock() detects metadata corruption while locating data blocks and a superblock writeback occurs at the same time:

task 1 task 2 ------ ------ A file operation nilfstruncate() nilfsgetblock() downread(rwsem A) <-- nilfsbmaplookupcontig() ... genericshutdownsuper() nilfsputsuper() Prepare to write superblock downwrite(rwsem B) <-- nilfscleanupsuper() Detect b-tree corruption nilfssetlogcursor() nilfsbmapconverterror() nilfscountfreeblocks() nilfserror() downread(rwsem A) <-- nilfsseterror() downwrite(rwsem B) <--

DEADLOCK

Here, nilfsgetblock() readlocks rwsem A (= NILFSMDT(datinode)->misem) and then calls nilfsbmaplookupcontig(), but if it fails due to metadata corruption, nilfserror() is called from nilfsbmapconverterror() inside the lock section.

Since nilfserror() calls nilfsseterror() unless the filesystem is read-only and nilfsseterror() attempts to writelock rwsem B (= nilfs->nssem) to write back superblock exclusively, hierarchical lock acquisition occurs in the order rwsem A -> rwsem B.

Now, if another task starts updating the superblock, it may writelock rwsem B during the lock sequence above, and can deadlock trying to readlock rwsem A in nilfscountfreeblocks().

However, there is actually no need to take rwsem A in nilfscountfreeblocks() because it, within the lock section, only reads a single integer data on a shared struct with nilfssufilegetncleansegs(). This has been the case after commit aa474a220180 ("nilfs2: add local variable to cache the number of clean segments"), that is, even before this bug was introduced.

So, this resolves the deadlock problem by just not taking the semaphore in nilfscountfreeblocks().

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:

phy: qcom-qmp-combo: fix NULL-deref on runtime resume

Commit fc64623637da ("phy: qcom-qmp-combo,usb: add support for separate PCSUSB region") started treating the PCSUSB registers as potentially separate from the PCS registers but used the wrong base when no PCSUSB offset has been provided.

Fix the PCSUSB base used at runtime resume to prevent dereferencing a NULL pointer on platforms that do not provide a PCSUSB offset (e.g. SC7180).

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

net: ethernet: ti: am65-cpsw: Fix segmentation fault at module unload

Move am65cpswnussphylinkcleanup() call to after am65cpswnusscleanupndev() so phylink is still valid to prevent the below Segmentation fault on module remove when first slave link is up.

[ 31.652944] Unable to handle kernel paging request at virtual address 00040008000005f4 [ 31.684627] Mem abort info: [ 31.687446] ESR = 0x0000000096000004 [ 31.704614] EC = 0x25: DABT (current EL), IL = 32 bits [ 31.720663] SET = 0, FnV = 0 [ 31.723729] EA = 0, S1PTW = 0 [ 31.740617] FSC = 0x04: level 0 translation fault [ 31.756624] Data abort info: [ 31.759508] ISV = 0, ISS = 0x00000004 [ 31.776705] CM = 0, WnR = 0 [ 31.779695] [00040008000005f4] address between user and kernel address ranges [ 31.808644] Internal error: Oops: 0000000096000004 [#1] PREEMPT SMP [ 31.814928] Modules linked in: wlcoresdio wl18xx wlcore mac80211 libarc4 cfg80211 rfkill crct10difce phygmiisel tiam65cpswnuss(-) schfqcodel ipv6 [ 31.828776] CPU: 0 PID: 1026 Comm: modprobe Not tainted 6.1.0-rc2-00012-gfabfcf7dafdb-dirty #160 [ 31.837547] Hardware name: Texas Instruments AM625 (DT) [ 31.842760] pstate: 40000005 (nZcv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 31.849709] pc : phystop+0x18/0xf8 [ 31.853202] lr : phylinkstop+0x38/0xf8 [ 31.857031] sp : ffff80000a0839f0 [ 31.860335] x29: ffff80000a0839f0 x28: ffff000000de1c80 x27: 0000000000000000 [ 31.867462] x26: 0000000000000000 x25: 0000000000000000 x24: ffff80000a083b98 [ 31.874589] x23: 0000000000000800 x22: 0000000000000001 x21: ffff000001bfba90 [ 31.881715] x20: ffff0000015ee000 x19: 0004000800000200 x18: 0000000000000000 [ 31.888842] x17: ffff800076c45000 x16: ffff800008004000 x15: 000058e39660b106 [ 31.895969] x14: 0000000000000144 x13: 0000000000000144 x12: 0000000000000000 [ 31.903095] x11: 000000000000275f x10: 00000000000009e0 x9 : ffff80000a0837d0 [ 31.910222] x8 : ffff000000de26c0 x7 : ffff00007fbd6540 x6 : ffff00007fbd64c0 [ 31.917349] x5 : ffff00007fbd0b10 x4 : ffff00007fbd0b10 x3 : ffff00007fbd3920 [ 31.924476] x2 : d0a07fcff8b8d500 x1 : 0000000000000000 x0 : 0004000800000200 [ 31.931603] Call trace: [ 31.934042] phystop+0x18/0xf8 [ 31.937177] phylinkstop+0x38/0xf8 [ 31.940657] am65cpswnussndoslavestop+0x28/0x1e0 [tiam65cpswnuss] [ 31.947452] devclosemany+0xa4/0x140 [ 31.951371] devclosemany+0x84/0x128 [ 31.955115] unregisternetdevicemany+0x130/0x6d0 [ 31.959897] unregisternetdevicequeue+0x94/0xd8 [ 31.964591] unregisternetdev+0x24/0x38 [ 31.968504] am65cpswnusscleanupndev.isra.0+0x48/0x70 [tiam65cpswnuss] [ 31.975637] am65cpswnussremove+0x58/0xf8 [tiam65cpswnuss]

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:

serial: imx: Add missing .thawnoirq hook

The following warning is seen with non-console UART instance when system hibernates.

[ 37.371969] ------------[ cut here ]------------ [ 37.376599] uart3rootclk already disabled [ 37.380810] WARNING: CPU: 0 PID: 296 at drivers/clk/clk.c:952 clkcoredisable+0xa4/0xb0 ... [ 37.506986] Call trace: [ 37.509432] clkcoredisable+0xa4/0xb0 [ 37.513270] clkdisable+0x34/0x50 [ 37.516672] imxuartthaw+0x38/0x5c [ 37.520250] platformpmthaw+0x30/0x6c [ 37.524089] dpmruncallback.constprop.0+0x3c/0xd4 [ 37.528972] deviceresume+0x7c/0x160 [ 37.532633] dpmresume+0xe8/0x230 [ 37.536036] hibernationsnapshot+0x288/0x430 [ 37.540397] hibernate+0x10c/0x2e0 [ 37.543798] statestore+0xc4/0xd0 [ 37.547203] kobjattrstore+0x1c/0x30 [ 37.550953] sysfskfwrite+0x48/0x60 [ 37.554619] kernfsfopwriteiter+0x118/0x1ac [ 37.559063] newsyncwrite+0xe8/0x184 [ 37.562812] vfswrite+0x230/0x290 [ 37.566214] ksyswrite+0x68/0xf4 [ 37.569529] arm64syswrite+0x20/0x2c [ 37.573452] invokesyscall.constprop.0+0x50/0xf0 [ 37.578156] doel0svc+0x11c/0x150 [ 37.581648] el0svc+0x30/0x140 [ 37.584792] el0t64synchandler+0xe8/0xf0 [ 37.588976] el0t64sync+0x1a0/0x1a4 [ 37.592639] ---[ end trace 56e22eec54676d75 ]---

On hibernating, pm core calls into related hooks in sequence like:

.freeze .freezenoirq .thawnoirq .thaw

With .thawnoirq hook being absent, the clock will be disabled in a unbalanced call which results the warning above.

imxuartfreeze() clkprepareenable() imxuartsuspendnoirq() clkdisable() imxuartthaw clkdisableunprepare()

Adding the missing .thawnoirq hook as imxuartresumenoirq() will have the call sequence corrected as below and thus fix the warning.

imxuartfreeze() clkprepareenable() imxuartsuspendnoirq() clkdisable() imxuartresumenoirq() clkenable() imxuartthaw clkdisableunprepare()

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

scsi: scsitransportsas: Fix error handling in sasphyadd()

If transportadddevice() fails in sasphyadd(), the kernel will crash trying to delete the device in transportremovedevice() called from sasremovehost().

Unable to handle kernel NULL pointer dereference at virtual address 0000000000000108 CPU: 61 PID: 42829 Comm: rmmod Kdump: loaded Tainted: G W 6.1.0-rc1+ #173 pstate: 60000005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : devicedel+0x54/0x3d0 lr : devicedel+0x37c/0x3d0 Call trace: devicedel+0x54/0x3d0 attributecontainerclassdevicedel+0x28/0x38 transportremoveclassdev+0x6c/0x80 attributecontainerdevicetrigger+0x108/0x110 transportremovedevice+0x28/0x38 sasphydelete+0x30/0x60 [scsitransportsas] dosasphydelete+0x6c/0x80 [scsitransportsas] deviceforeachchild+0x68/0xb0 sasremovechildren+0x40/0x50 [scsitransportsas] sasremovehost+0x20/0x38 [scsitransportsas] hisisasremove+0x40/0x68 [hisisasmain] hisisasv2remove+0x20/0x30 [hisisasv2hw] platformremove+0x2c/0x60

Fix this by checking and handling return value of transportadddevice() in sasphyadd().

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

sctp: clear outcurr if all frag chunks of current msg are pruned

A crash was reported by Zhen Chen:

listdel corruption, ffffa035ddf01c18->next is NULL WARNING: CPU: 1 PID: 250682 at lib/listdebug.c:49 listdelentryvalid+0x59/0xe0 RIP: 0010:listdelentryvalid+0x59/0xe0 Call Trace: sctpscheddequeuecommon+0x17/0x70 [sctp] sctpschedfcfsdequeue+0x37/0x50 [sctp] sctpoutqflushdata+0x85/0x360 [sctp] sctpoutquncork+0x77/0xa0 [sctp] sctpcmdinterpreter.constprop.0+0x164/0x1450 [sctp] sctpsideeffects+0x37/0xe0 [sctp] sctpdosm+0xd0/0x230 [sctp] sctpprimitiveSEND+0x2f/0x40 [sctp] sctpsendmsgtoasoc+0x3fa/0x5c0 [sctp] sctpsendmsg+0x3d5/0x440 [sctp] socksendmsg+0x5b/0x70

and in sctpschedfcfsdequeue() it dequeued a chunk from stream outcurr outq while this outq was empty.

Normally stream->outcurr must be set to NULL once all frag chunks of current msg are dequeued, as we can see in sctpscheddequeuedone(). However, in sctpprsctppruneunsent() as it is not a proper dequeue, sctpscheddequeuedone() is not called to do this.

This patch is to fix it by simply setting outcurr to NULL when the last frag chunk of current msg is dequeued from outcurr stream in sctpprsctppruneunsent().

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

bpf: Fix memory leaks in checkfunccall

kmemleak reports this issue:

unreferenced object 0xffff88817139d000 (size 2048): comm "testprogs", pid 33246, jiffies 4307381979 (age 45851.820s) hex dump (first 32 bytes): 01 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: [<0000000045f075f0>] kmalloctrace+0x27/0xa0 [<0000000098b7c90a>] checkfunccall+0x316/0x1230 [<00000000b4c3c403>] checkhelpercall+0x172e/0x4700 [<00000000aa3875b7>] docheck+0x21d8/0x45e0 [<000000001147357b>] docheckcommon+0x767/0xaf0 [<00000000b5a595b4>] bpfcheck+0x43e3/0x5bc0 [<0000000011e391b1>] bpfprogload+0xf26/0x1940 [<0000000007f765c0>] sysbpf+0xd2c/0x3650 [<00000000839815d6>] x64sysbpf+0x75/0xc0 [<00000000946ee250>] dosyscall64+0x3b/0x90 [<0000000000506b7f>] entrySYSCALL64afterhwframe+0x63/0xcd

The root case here is: In function preparefuncexit(), the callee is not released in the abnormal scenario after "state->curframe--;". To fix, move "state->curframe--;" to the very bottom of the function, right when we free callee and reset frame[] pointer to NULL, as Andrii suggested.

In addition, function checkfunccall() has a similar problem. In the abnormal scenario before "state->curframe++;", the callee also should be released by freefuncstate().