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.
In the Linux kernel, the following vulnerability has been resolved:
net: sched: sfb: fix null pointer access issue when sfbinit() fails
When the default qdisc is sfb, if the qdisc of devqueue fails to be inited during mqprioinit(), sfbreset() is invoked to clear resources. In this case, the q->qdisc is NULL, and it will cause gpf issue.
The process is as follows: qdisccreatedflt() sfbinit() tcfblockget() --->failed, q->qdisc is NULL ... qdiscput() ... sfbreset() qdiscreset(q->qdisc) --->q->qdisc is NULL ops = qdisc->ops
The following is the Call Trace information: general protection fault, probably for non-canonical address 0xdffffc0000000003: 0000 [#1] PREEMPT SMP KASAN KASAN: null-ptr-deref in range [0x0000000000000018-0x000000000000001f] RIP: 0010:qdiscreset+0x2b/0x6f0 Call Trace: <TASK> sfbreset+0x37/0xd0 qdiscreset+0xed/0x6f0 qdiscdestroy+0x82/0x4c0 qdiscput+0x9e/0xb0 qdisccreatedflt+0x2c3/0x4a0 mqprioinit+0xa71/0x1760 qdisccreate+0x3eb/0x1000 tcmodifyqdisc+0x408/0x1720 rtnetlinkrcvmsg+0x38e/0xac0 netlinkrcvskb+0x12d/0x3a0 netlinkunicast+0x4a2/0x740 netlinksendmsg+0x826/0xcc0 socksendmsg+0xc5/0x100 syssendmsg+0x583/0x690 syssendmsg+0xe8/0x160 syssendmsg+0xbf/0x160 dosyscall64+0x35/0x80 entrySYSCALL64afterhwframe+0x46/0xb0 RIP: 0033:0x7f2164122d04 </TASK>
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.
A known cache speculation vulnerability, known as Branch History Injection (BHI) or Spectre-BHB, becomes actual again for the new hw AmpereOne. Spectre-BHB is similar to Spectre v2, except that malicious code uses the shared branch history (stored in the CPU Branch History Buffer, or BHB) to influence mispredicted branches within the victim's hardware context. Once that occurs, speculation caused by the mispredicted branches can cause cache allocation. This issue leads to obtaining information that should not be accessible.
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:
net: do not sense pfmemalloc status in skbappendpagefrags()
skbappendpagefrags() is used by afunix and udp sendpage() implementation so far.
In commit 326140063946 ("tcp: TX zerocopy should not sense pfmemalloc status") we explained why we should not sense pfmemalloc status for pages owned by user space.
We should also use skbfillpagedescnoacc() in skbappendpagefrags() to avoid following KCSAN report:
BUG: KCSAN: data-race in lruaddfn / skbappendpagefrags
write to 0xffffea00058fc1c8 of 8 bytes by task 17319 on cpu 0: listadd include/linux/list.h:73 [inline] listadd include/linux/list.h:88 [inline] lruvecaddfolio include/linux/mminline.h:323 [inline] lruaddfn+0x327/0x410 mm/swap.c:228 foliobatchmovelru+0x1e1/0x2a0 mm/swap.c:246 lruadddraincpu+0x73/0x250 mm/swap.c:669 lruadddrain+0x21/0x60 mm/swap.c:773 freepagesandswapcache+0x16/0x70 mm/swapstate.c:311 tlbbatchpagesflush mm/mmugather.c:59 [inline] tlbflushmmufree mm/mmugather.c:256 [inline] tlbflushmmu+0x5b2/0x640 mm/mmugather.c:263 tlbfinishmmu+0x86/0x100 mm/mmugather.c:363 exitmmap+0x190/0x4d0 mm/mmap.c:3098 mmput+0x27/0x1b0 kernel/fork.c:1185 mmput+0x3d/0x50 kernel/fork.c:1207 copyprocess+0x19fc/0x2100 kernel/fork.c:2518 kernelclone+0x166/0x550 kernel/fork.c:2671 dosysclone kernel/fork.c:2812 [inline] sesysclone kernel/fork.c:2796 [inline] x64sysclone+0xc3/0xf0 kernel/fork.c:2796 dosyscallx64 arch/x86/entry/common.c:50 [inline] dosyscall64+0x2b/0x70 arch/x86/entry/common.c:80 entrySYSCALL64afterhwframe+0x63/0xcd
read to 0xffffea00058fc1c8 of 8 bytes by task 17325 on cpu 1: pageispfmemalloc include/linux/mm.h:1817 [inline] skbfillpagedesc include/linux/skbuff.h:2432 [inline] skbfillpagedesc include/linux/skbuff.h:2453 [inline] skbappendpagefrags+0x210/0x600 net/core/skbuff.c:3974 unixstreamsendpage+0x45e/0x990 net/unix/afunix.c:2338 kernelsendpage+0x184/0x300 net/socket.c:3561 socksendpage+0x5a/0x70 net/socket.c:1054 pipetosendpage+0x128/0x160 fs/splice.c:361 splicefrompipefeed fs/splice.c:415 [inline] splicefrompipe+0x222/0x4d0 fs/splice.c:559 splicefrompipe fs/splice.c:594 [inline] genericsplicesendpage+0x89/0xc0 fs/splice.c:743 dosplicefrom fs/splice.c:764 [inline] directspliceactor+0x80/0xa0 fs/splice.c:931 splicedirecttoactor+0x305/0x620 fs/splice.c:886 dosplicedirect+0xfb/0x180 fs/splice.c:974 dosendfile+0x3bf/0x910 fs/readwrite.c:1255 dosyssendfile64 fs/readwrite.c:1323 [inline] sesyssendfile64 fs/readwrite.c:1309 [inline] x64syssendfile64+0x10c/0x150 fs/readwrite.c:1309 dosyscallx64 arch/x86/entry/common.c:50 [inline] dosyscall64+0x2b/0x70 arch/x86/entry/common.c:80 entrySYSCALL64afterhwframe+0x63/0xcd
value changed: 0x0000000000000000 -> 0xffffea00058fc188
Reported by Kernel Concurrency Sanitizer on: CPU: 1 PID: 17325 Comm: syz-executor.0 Not tainted 6.1.0-rc1-syzkaller-00158-g440b7895c990-dirty #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 10/11/2022
In the Linux kernel, the following vulnerability has been resolved:
mm,hugetlb: take hugetlblock before decrementing h->resvhugepages
The h->hugepages counters are protected by the hugetlblock, but allochugepage has a corner case where it can decrement the counter outside of the lock.
This could lead to a corrupted value of h->resvhugepages, which we have observed on our systems.
Take the hugetlblock before decrementing h->resvhugepages to avoid a potential race.
In the Linux kernel, the following vulnerability has been resolved:
rose: Fix NULL pointer dereference in rosesendframe()
The syzkaller reported an issue:
KASAN: null-ptr-deref in range [0x0000000000000380-0x0000000000000387] CPU: 0 PID: 4069 Comm: kworker/0:15 Not tainted 6.0.0-syzkaller-02734-g0326074ff465 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/22/2022 Workqueue: rcugp srcuinvokecallbacks RIP: 0010:rosesendframe+0x1dd/0x2f0 net/rose/roselink.c:101 Call Trace: <IRQ> rosetransmitclearrequest+0x1d5/0x290 net/rose/roselink.c:255 roserxcallrequest+0x4c0/0x1bc0 net/rose/afrose.c:1009 roseloopbacktimer+0x19e/0x590 net/rose/roseloopback.c:111 calltimerfn+0x1a0/0x6b0 kernel/time/timer.c:1474 expiretimers kernel/time/timer.c:1519 [inline] runtimers.part.0+0x674/0xa80 kernel/time/timer.c:1790 runtimers kernel/time/timer.c:1768 [inline] runtimersoftirq+0xb3/0x1d0 kernel/time/timer.c:1803 dosoftirq+0x1d0/0x9c8 kernel/softirq.c:571 [...] </IRQ>
It triggers NULL pointer dereference when 'neigh->dev->devaddr' is called in the rosesendframe(). It's the first occurrence of the neigh is in roseloopbacktimer() as roseloopbackneigh', and the 'dev' in 'roseloopbackneigh' is initialized sa nullptr.
It had been fixed by commit 3b3fd068c56e3fbea30090859216a368398e39bf ("rose: Fix Null pointer dereference in rosesendframe()") ever. But it's introduced by commit 3c53cd65dece47dd1f9d3a809f32e59d1d87b2b8 ("rose: check NULL roseloopbackneigh->loopback") again.
We fix it by add NULL check in rosetransmitclearrequest(). When the 'dev' in 'neigh' is NULL, we don't reply the request and just clear it.
syzkaller don't provide repro, and I provide a syz repro like: r0 = syzinitnetsocket$btsco(0x1f, 0x5, 0x2) ioctl$sockinetSIOCSIFFLAGS(r0, 0x8914, &(0x7f0000000180)={'rose0\x00', 0x201}) r1 = syzinitnetsocket$rose(0xb, 0x5, 0x0) bind$rose(r1, &(0x7f00000000c0)=@full={0xb, @dev, @null, 0x0, [@null, @null, @netrom, @netrom, @default, @null]}, 0x40) connect$rose(r1, &(0x7f0000000240)=@short={0xb, @dev={0xbb, 0xbb, 0xbb, 0x1, 0x0}, @remote={0xcc, 0xcc, 0xcc, 0xcc, 0xcc, 0xcc, 0x1}, 0x1, @netrom={0xbb, 0xbb, 0xbb, 0xbb, 0xbb, 0x0, 0x0}}, 0x1c)
In the Linux kernel, the following vulnerability has been resolved:
net, neigh: Fix null-ptr-deref in neightableclear()
When IPv6 module gets initialized but hits an error in the middle, kenel panic with:
KASAN: null-ptr-deref in range [0x0000000000000598-0x000000000000059f] CPU: 1 PID: 361 Comm: insmod Hardware name: QEMU Standard PC (i440FX + PIIX, 1996) RIP: 0010:neighifdown.isra.0+0x24b/0x370 RSP: 0018:ffff888012677908 EFLAGS: 00000202 ... Call Trace: <TASK> neightableclear+0x94/0x2d0 ndisccleanup+0x27/0x40 [ipv6] inet6init+0x21c/0x2cb [ipv6] dooneinitcall+0xd3/0x4d0 doinitmodule+0x1ae/0x670 ... Kernel panic - not syncing: Fatal exception
When ipv6 initialization fails, it will try to cleanup and calls:
neightableclear() neighifdown(tbl, NULL) pneighqueuepurge(&tbl->proxyqueue, devnet(dev == NULL)) # devnet(NULL) triggers null-ptr-deref.
Fix it by passing NULL to pneighqueuepurge() in neighifdown() if dev is NULL, to make kernel not panic immediately.
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:
tipc: fix an information leak in tipctopsrvkernsubscr
Use a 8-byte write to initialize sub.usrhandle in tipctopsrvkernsubscr(), otherwise four bytes remain uninitialized when issuing setsockopt(..., SOLTIPC, ...). This resulted in an infoleak reported by KMSAN when the packet was received:
===================================================== BUG: KMSAN: kernel-infoleak in copyout+0xbc/0x100 lib/ioviter.c:169 instrumentcopytouser ./include/linux/instrumented.h:121 copyout+0xbc/0x100 lib/ioviter.c:169 copytoiter+0x5c0/0x20a0 lib/ioviter.c:527 copytoiter ./include/linux/uio.h:176 simplecopytoiter+0x64/0xa0 net/core/datagram.c:513 skbdatagramiter+0x123/0xdc0 net/core/datagram.c:419 skbcopydatagramiter+0x58/0x200 net/core/datagram.c:527 skbcopydatagrammsg ./include/linux/skbuff.h:3903 packetrecvmsg+0x521/0x1e70 net/packet/afpacket.c:3469 sysrecvmsg+0x2c4/0x810 net/socket.c:? sysrecvmsg+0x217/0x840 net/socket.c:2743 sysrecvmsg net/socket.c:2773 dosysrecvmsg net/socket.c:2783 sesysrecvmsg net/socket.c:2780 x64sysrecvmsg+0x364/0x540 net/socket.c:2780 dosyscallx64 arch/x86/entry/common.c:50 dosyscall64+0x3d/0xb0 arch/x86/entry/common.c:80 entrySYSCALL64afterhwframe+0x63/0xcd arch/x86/entry/entry64.S:120
...
Uninit was stored to memory at: tipcsubsubscribe+0x42d/0xb50 net/tipc/subscr.c:156 tipcconnrcvsub+0x246/0x620 net/tipc/topsrv.c:375 tipctopsrvkernsubscr+0x2e8/0x400 net/tipc/topsrv.c:579 tipcgroupcreate+0x4e7/0x7d0 net/tipc/group.c:190 tipcskjoin+0x2a8/0x770 net/tipc/socket.c:3084 tipcsetsockopt+0xae5/0xe40 net/tipc/socket.c:3201 syssetsockopt+0x87f/0xdc0 net/socket.c:2252 dosyssetsockopt net/socket.c:2263 sesyssetsockopt net/socket.c:2260 x64syssetsockopt+0xe0/0x160 net/socket.c:2260 dosyscallx64 arch/x86/entry/common.c:50 dosyscall64+0x3d/0xb0 arch/x86/entry/common.c:80 entrySYSCALL64afterhwframe+0x63/0xcd arch/x86/entry/entry64.S:120
Local variable sub created at: tipctopsrvkernsubscr+0x57/0x400 net/tipc/topsrv.c:562 tipcgroupcreate+0x4e7/0x7d0 net/tipc/group.c:190
Bytes 84-87 of 88 are uninitialized Memory access of size 88 starts at ffff88801ed57cd0 Data copied to user address 0000000020000400 ... =====================================================
In the Linux kernel, the following vulnerability has been resolved:
blk-mq: fix null pointer dereference in blkmqclearrqmapping()
Our syzkaller report a null pointer dereference, root cause is following:
blkmqallocmapandrqs set->tags[hctxidx] = blkmqallocmapandrqs blkmqallocmapandrqs blkmqallocrqs // failed due to oom allocpagesnode // set->tags[hctxidx] is still NULL blkmqfreerqs drvtags = set->tags[hctxidx]; // null pointer dereference is triggered blkmqclearrqmapping(drvtags, ...)
This is because commit 63064be150e4 ("blk-mq: Add blkmqallocmapandrqs()") merged the two steps:
1) set->tags[hctxidx] = blkmqallocrqmap() 2) blkmqallocrqs(..., set->tags[hctxidx])
into one step:
set->tags[hctxidx] = blkmqallocmapandrqs()
Since tags is not initialized yet in this case, fix the problem by checking if tags is NULL pointer in blkmqclearrqmapping().
In the Linux kernel, the following vulnerability has been resolved:
drbd: only clone bio if we have a backing device
Commit c347a787e34cb (drbd: set ->bibdev in drbdreqnew) moved a biosetdev call (which has since been removed) to "earlier", from drbdrequestprepare to drbdreqnew.
The problem is that this accesses device->ldev->backingbdev, which is not NULL-checked at this point. When we don't have an ldev (i.e. when the DRBD device is diskless), this leads to a null pointer deref.
So, only allocate the privatebio if we actually have a disk. This is also a small optimization, since we don't clone the bio to only to immediately free it again in the diskless case.
In the Linux kernel, the following vulnerability has been resolved:
netdevsim: fix memory leak in nsimdrvprobe() when nsimdevresourcesregister() failed
If some items in nsimdevresourcesregister() fail, memory leak will occur. The following is the memory leak information.
unreferenced object 0xffff888074c02600 (size 128): comm "echo", pid 8159, jiffies 4294945184 (age 493.530s) hex dump (first 32 bytes): 40 47 ea 89 ff ff ff ff 01 00 00 00 00 00 00 00 @G.............. ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ................ backtrace: [<0000000011a31c98>] kmalloctrace+0x22/0x60 [<0000000027384c69>] devlresourceregister+0x144/0x4e0 [<00000000a16db248>] nsimdrvprobe+0x37a/0x1260 [<000000007d1f448c>] reallyprobe+0x20b/0xb10 [<00000000c416848a>] driverprobedevice+0x1b3/0x4a0 [<00000000077e0351>] driverprobedevice+0x49/0x140 [<0000000054f2465a>] deviceattachdriver+0x18c/0x2a0 [<000000008538f359>] busforeachdrv+0x151/0x1d0 [<0000000038e09747>] deviceattach+0x1c9/0x4e0 [<00000000dd86e533>] busprobedevice+0x1d5/0x280 [<00000000839bea35>] deviceadd+0xae0/0x1cb0 [<000000009c2abf46>] newdevicestore+0x3b6/0x5f0 [<00000000fb823d7f>] busattrstore+0x72/0xa0 [<000000007acc4295>] sysfskfwrite+0x106/0x160 [<000000005f50cb4d>] kernfsfopwriteiter+0x3a8/0x5a0 [<0000000075eb41bf>] vfswrite+0x8f0/0xc80
In the Linux kernel, the following vulnerability has been resolved:
coresight: cti: Fix hang in ctidisablehw()
ctienablehw() and ctidisablehw() are called from an atomic context so shouldn't use runtime PM because it can result in a sleep when communicating with firmware.
Since commit 3c6656337852 ("Revert "firmware: armscmi: Add clock management to the SCMI power domain""), this causes a hang on Juno when running the Perf Coresight tests or running this command:
perf record -e csetm//u -- ls
This was also missed until the revert commit because pmruntimeput() was called with the wrong device until commit 692c9a499b28 ("coresight: cti: Correct the parameter for pmruntimeput")
With lock and scheduler debugging enabled the following is output:
coresight ctisys0: ctienablehw -- dev:ctisys0 parent: 20020000.cti BUG: sleeping function called from invalid context at drivers/base/power/runtime.c:1151 inatomic(): 1, irqsdisabled(): 128, nonblock: 0, pid: 330, name: perf-exec preemptcount: 2, expected: 0 RCU nest depth: 0, expected: 0 INFO: lockdep is turned off. irq event stamp: 0 hardirqs last enabled at (0): [<0000000000000000>] 0x0 hardirqs last disabled at (0): [<ffff80000822b394>] copyprocess+0xa0c/0x1948 softirqs last enabled at (0): [<ffff80000822b394>] copyprocess+0xa0c/0x1948 softirqs last disabled at (0): [<0000000000000000>] 0x0 CPU: 3 PID: 330 Comm: perf-exec Not tainted 6.0.0-00053-g042116d99298 #7 Hardware name: ARM LTD ARM Juno Development Platform/ARM Juno Development Platform, BIOS EDK II Sep 13 2022 Call trace: dumpbacktrace+0x134/0x140 showstack+0x20/0x58 dumpstacklvl+0x8c/0xb8 dumpstack+0x18/0x34 mightresched+0x180/0x228 mightsleep+0x50/0x88 pmruntimeresume+0xac/0xb0 ctienable+0x44/0x120 coresightcontrolassocectdev+0xc0/0x150 coresightenablepath+0xb4/0x288 etmeventstart+0x138/0x170 etmeventadd+0x48/0x70 eventschedin.isra.122+0xb4/0x280 mergeschedin+0x1fc/0x3d0 visitgroupsmerge.constprop.137+0x16c/0x4b0 ctxschedin+0x114/0x1f0 perfeventschedin+0x60/0x90 ctxresched+0x68/0xb0 perfeventexec+0x138/0x508 beginnewexec+0x52c/0xd40 loadelfbinary+0x6b8/0x17d0 bprmexecve+0x360/0x7f8 doexecveatcommon.isra.47+0x218/0x238 arm64sysexecve+0x48/0x60 invokesyscall+0x4c/0x110 el0svccommon.constprop.4+0xfc/0x120 doel0svc+0x34/0xc0 el0svc+0x40/0x98 el0t64synchandler+0x98/0xc0 el0t64sync+0x170/0x174
Fix the issue by removing the runtime PM calls completely. They are not needed here because it must have already been done when building the path for a trace.
[ Fix build warnings ]
In the Linux kernel, the following vulnerability has been resolved:
iommu/vt-d: Clean up sidomain in the initdmars() error path
A splat from kmemcachedestroy() was seen with a kernel prior to commit ee2653bbe89d ("iommu/vt-d: Remove domain and devinfo mempool") when there was a failure in initdmars(), because the iommudomain cache still had objects. While the mempool code is now gone, there still is a leak of the sidomain memory if initdmars() fails. So clean up sidomain in the initdmars() error path.