A race condition in the x86 KVM subsystem in the Linux kernel through 6.1-rc6 allows guest OS users to cause a denial of service (host OS crash or host OS memory corruption) when nested virtualisation and the TDP MMU are enabled.
In the Linux kernel, the following vulnerability has been resolved:
igb: Initialize mailbox message for VF reset
When a MAC address is not assigned to the VF, that portion of the message sent to the VF is not set. The memory, however, is allocated from the stack meaning that information may be leaked to the VM. Initialize the message buffer to 0 so that no information is passed to the VM in this case.
In the Linux kernel, the following vulnerability has been resolved:
xen-netfront: Fix NULL sring after live migration
A NAPI is setup for each network sring to poll data to kernel The sring with source host is destroyed before live migration and new sring with target host is setup after live migration. The NAPI for the old sring is not deleted until setup new sring with target host after migration. With busypoll/busyread enabled, the NAPI can be polled before got deleted when resume VM.
BUG: unable to handle kernel NULL pointer dereference at 0000000000000008 IP: xennetpoll+0xae/0xd20 PGD 0 P4D 0 Oops: 0000 [#1] SMP PTI Call Trace: finishtaskswitch+0x71/0x230 timerqueuedel+0x1d/0x40 hrtimertrytocancel+0xb5/0x110 xennetallocrxbuffers+0x2a0/0x2a0 napibusyloop+0xdb/0x270 sockpoll+0x87/0x90 dosyspoll+0x26f/0x580 tracingmapinsert+0x1d4/0x2f0 eventhisttrigger+0x14a/0x260
finishtaskswitch+0x71/0x230 schedule+0x256/0x890 recalcsigpending+0x1b/0x50 xenschedclock+0x15/0x20 rbreservenext+0x12d/0x140 ringbufferlockreserve+0x123/0x3d0 eventtriggerscall+0x87/0xb0 traceeventbuffercommit+0x1c4/0x210 xenclocksourcegetcycles+0x15/0x20 ktimegetts64+0x51/0xf0 SySppoll+0x160/0x1a0 SySppoll+0x160/0x1a0 dosyscall64+0x73/0x130 entrySYSCALL64afterhwframe+0x41/0xa6 ... RIP: xennetpoll+0xae/0xd20 RSP: ffffb4f041933900 CR2: 0000000000000008 ---[ end trace f8601785b354351c ]---
xen frontend should remove the NAPIs for the old srings before live migration as the bond srings are destroyed
There is a tiny window between the srings are set to NULL and the NAPIs are disabled, It is safe as the NAPI threads are still frozen at that time
In the Linux kernel, the following vulnerability has been resolved:
mac802154: fix missing INITLISTHEAD in ieee802154ifadd()
Kernel fault injection test reports null-ptr-deref as follows:
BUG: kernel NULL pointer dereference, address: 0000000000000008 RIP: 0010:cfg802154netdevnotifiercall+0x120/0x310 include/linux/list.h:114 Call Trace: <TASK> rawnotifiercallchain+0x6d/0xa0 kernel/notifier.c:87 callnetdevicenotifiersinfo+0x6e/0xc0 net/core/dev.c:1944 unregisternetdevicemanynotify+0x60d/0xcb0 net/core/dev.c:1982 unregisternetdevicequeue+0x154/0x1a0 net/core/dev.c:10879 registernetdevice+0x9a8/0xb90 net/core/dev.c:10083 ieee802154ifadd+0x6ed/0x7e0 net/mac802154/iface.c:659 ieee802154registerhw+0x29c/0x330 net/mac802154/main.c:229 mcr20aprobe+0xaaa/0xcb1 drivers/net/ieee802154/mcr20a.c:1316
ieee802154ifadd() allocates wpandev as netdev's private data, but not init the list in struct wpandev. cfg802154netdevnotifiercall() manage the list when device register/unregister, and may lead to null-ptr-deref.
Use INITLISTHEAD() on it to initialize it correctly.
In the Linux kernel, the following vulnerability has been resolved:
net: dsa: sja1105: fix memory leak in sja1105setupdevlinkregions()
When dsadevlinkregioncreate failed in sja1105setupdevlinkregions(), priv->regions is not released.
In the Linux kernel, the following vulnerability has been resolved:
ethernet: aeroflex: fix potential skb leak in grethinitrings()
The grethinitrings() function won't free the newly allocated skb when dmamappingerror() returns error, so add devkfreeskb() to fix it.
Compile tested only.
In the Linux kernel, the following vulnerability has been resolved:
afunix: Get userns from inskb in unixdiaggetexact().
Wei Chen reported a NULL deref in skuserns() [0][1], and Paolo diagnosed the root cause: in unixdiaggetexact(), the newly allocated skb does not have sk. [2]
We must get the userns from the NETLINKCB(inskb).sk and pass it to skdiagfill().
[0]: BUG: kernel NULL pointer dereference, address: 0000000000000270 #PF: supervisor read access in kernel mode #PF: errorcode(0x0000) - not-present page PGD 12bbce067 P4D 12bbce067 PUD 12bc40067 PMD 0 Oops: 0000 [#1] PREEMPT SMP CPU: 0 PID: 27942 Comm: syz-executor.0 Not tainted 6.1.0-rc5-next-20221118 #2 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.13.0-48-gd9c812dda519-prebuilt.qemu.org 04/01/2014 RIP: 0010:skuserns include/net/sock.h:920 [inline] RIP: 0010:skdiagdumpuid net/unix/diag.c:119 [inline] RIP: 0010:skdiagfill+0x77d/0x890 net/unix/diag.c:170 Code: 89 ef e8 66 d4 2d fd c7 44 24 40 00 00 00 00 49 8d 7c 24 18 e8 54 d7 2d fd 49 8b 5c 24 18 48 8d bb 70 02 00 00 e8 43 d7 2d fd <48> 8b 9b 70 02 00 00 48 8d 7b 10 e8 33 d7 2d fd 48 8b 5b 10 48 8d RSP: 0018:ffffc90000d67968 EFLAGS: 00010246 RAX: ffff88812badaa48 RBX: 0000000000000000 RCX: ffffffff840d481d RDX: 0000000000000465 RSI: 0000000000000000 RDI: 0000000000000270 RBP: ffffc90000d679a8 R08: 0000000000000277 R09: 0000000000000000 R10: 0001ffffffffffff R11: 0001c90000d679a8 R12: ffff88812ac03800 R13: ffff88812c87c400 R14: ffff88812ae42210 R15: ffff888103026940 FS: 00007f08b4e6f700(0000) GS:ffff88813bc00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000270 CR3: 000000012c58b000 CR4: 00000000003506f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: <TASK> unixdiaggetexact net/unix/diag.c:285 [inline] unixdiaghandlerdump+0x3f9/0x500 net/unix/diag.c:317 sockdiagcmd net/core/sockdiag.c:235 [inline] sockdiagrcvmsg+0x237/0x250 net/core/sockdiag.c:266 netlinkrcvskb+0x13e/0x250 net/netlink/afnetlink.c:2564 sockdiagrcv+0x24/0x40 net/core/sockdiag.c:277 netlinkunicastkernel net/netlink/afnetlink.c:1330 [inline] netlinkunicast+0x5e9/0x6b0 net/netlink/afnetlink.c:1356 netlinksendmsg+0x739/0x860 net/netlink/afnetlink.c:1932 socksendmsgnosec net/socket.c:714 [inline] socksendmsg net/socket.c:734 [inline] syssendmsg+0x38f/0x500 net/socket.c:2476 syssendmsg net/socket.c:2530 [inline] syssendmsg+0x197/0x230 net/socket.c:2559 dosyssendmsg net/socket.c:2568 [inline] sesyssendmsg net/socket.c:2566 [inline] x64syssendmsg+0x42/0x50 net/socket.c:2566 dosyscallx64 arch/x86/entry/common.c:50 [inline] dosyscall64+0x2b/0x70 arch/x86/entry/common.c:80 entrySYSCALL64afterhwframe+0x63/0xcd RIP: 0033:0x4697f9 Code: f7 d8 64 89 02 b8 ff ff ff ff c3 66 0f 1f 44 00 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 bc ff ff ff f7 d8 64 89 01 48 RSP: 002b:00007f08b4e6ec48 EFLAGS: 00000246 ORIGRAX: 000000000000002e RAX: ffffffffffffffda RBX: 000000000077bf80 RCX: 00000000004697f9 RDX: 0000000000000000 RSI: 00000000200001c0 RDI: 0000000000000003 RBP: 00000000004d29e9 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000246 R12: 000000000077bf80 R13: 0000000000000000 R14: 000000000077bf80 R15: 00007ffdb36bc6c0 </TASK> Modules linked in: CR2: 0000000000000270
[1]: https://lore.kernel.org/netdev/CAO4mrfdvyjFpokhNsiwZiP-wpdSD0AStcJwfKcKQdAALQ92Qw@mail.gmail.com/ [2]: https://lore.kernel.org/netdev/e04315e7c90d9a75613f3993c2baf2d344eef7eb.camel@redhat.com/
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:
gpio: amd8111: Fix PCI device reference count leak
foreachpcidev() is implemented by pcigetdevice(). The comment of pcigetdevice() says that it will increase the reference count for the returned pcidev and also decrease the reference count for the input pcidev @from if it is not NULL.
If we break foreachpcidev() loop with pdev not NULL, we need to call pcidevput() to decrease the reference count. Add the missing pcidevput() after the 'out' label. Since pcidevput() can handle NULL input parameter, there is no problem for the 'Device not found' branch. For the normal path, add pcidevput() in amdgpioexit().
In the Linux kernel, the following vulnerability has been resolved:
octeontx2-pf: Fix potential memory leak in otx2inittc()
In otx2inittc(), if rhashtableinit() failed, it does not free tc->tcentriesbitmap which is allocated in otx2tcallocentbitmap().
In the Linux kernel, the following vulnerability has been resolved:
ALSA: seq: Fix function prototype mismatch in sndseqexpandvarevent
With clang's kernel control flow integrity (kCFI, CONFIGCFICLANG), indirect call targets are validated against the expected function pointer prototype to make sure the call target is valid to help mitigate ROP attacks. If they are not identical, there is a failure at run time, which manifests as either a kernel panic or thread getting killed.
seqcopyinuser() and seqcopyinkernel() did not have prototypes matching sndseqdumpfunct. Adjust this and remove the casts. There are not resulting binary output differences.
This was found as a result of Clang's new -Wcast-function-type-strict flag, which is more sensitive than the simpler -Wcast-function-type, which only checks for type width mismatches.
In the Linux kernel, the following vulnerability has been resolved:
Bluetooth: L2CAP: Fix u8 overflow
By keep sending L2CAPCONFREQ packets, chan->numconfrsp increases multiple times and eventually it will wrap around the maximum number (i.e., 255). This patch prevents this by adding a boundary check with L2CAPMAXCONFRSP
Btmon log: Bluetooth monitor ver 5.64 = Note: Linux version 6.1.0-rc2 (x8664) 0.264594 = Note: Bluetooth subsystem version 2.22 0.264636 @ MGMT Open: btmon (privileged) version 1.22 {0x0001} 0.272191 = New Index: 00:00:00:00:00:00 (Primary,Virtual,hci0) [hci0] 13.877604 @ RAW Open: 9496 (privileged) version 2.22 {0x0002} 13.890741 = Open Index: 00:00:00:00:00:00 [hci0] 13.900426 (...) ACL Data RX: Handle 200 flags 0x00 dlen 1033 #32 [hci0] 14.273106 invalid packet size (12 != 1033) 08 00 01 00 02 01 04 00 01 10 ff ff ............ ACL Data RX: Handle 200 flags 0x00 dlen 1547 #33 [hci0] 14.273561 invalid packet size (14 != 1547) 0a 00 01 00 04 01 06 00 40 00 00 00 00 00 ........@..... ACL Data RX: Handle 200 flags 0x00 dlen 2061 #34 [hci0] 14.274390 invalid packet size (16 != 2061) 0c 00 01 00 04 01 08 00 40 00 00 00 00 00 00 04 ........@....... ACL Data RX: Handle 200 flags 0x00 dlen 2061 #35 [hci0] 14.274932 invalid packet size (16 != 2061) 0c 00 01 00 04 01 08 00 40 00 00 00 07 00 03 00 ........@....... = bluetoothd: Bluetooth daemon 5.43 14.401828 ACL Data RX: Handle 200 flags 0x00 dlen 1033 #36 [hci0] 14.275753 invalid packet size (12 != 1033) 08 00 01 00 04 01 04 00 40 00 00 00 ........@...
In the Linux kernel, the following vulnerability has been resolved:
Bluetooth: Fix crash when replugging CSR fake controllers
It seems fake CSR 5.0 clones can cause the suspend notifier to be registered twice causing the following kernel panic:
[ 71.986122] Call Trace: [ 71.986124] <TASK> [ 71.986125] blockingnotifierchainregister+0x33/0x60 [ 71.986130] hciregisterdev+0x316/0x3d0 [bluetooth 99b5497ea3d09708fa1366c1dc03288bf3cca8da] [ 71.986154] btusbprobe+0x979/0xd85 [btusb e1e0605a4f4c01984a4b9c8ac58c3666ae287477] [ 71.986159] ? pmruntimesetstatus+0x1a9/0x300 [ 71.986162] ? ktimegetmonofastns+0x3e/0x90 [ 71.986167] usbprobeinterface+0xe3/0x2b0 [ 71.986171] reallyprobe+0xdb/0x380 [ 71.986174] ? pmruntimebarrier+0x54/0x90 [ 71.986177] driverprobedevice+0x78/0x170 [ 71.986180] driverprobedevice+0x1f/0x90 [ 71.986183] deviceattachdriver+0x89/0x110 [ 71.986186] ? driverallowsasyncprobing+0x70/0x70 [ 71.986189] busforeachdrv+0x8c/0xe0 [ 71.986192] deviceattach+0xb2/0x1e0 [ 71.986195] busprobedevice+0x92/0xb0 [ 71.986198] deviceadd+0x422/0x9a0 [ 71.986201] ? sysfsmergegroup+0xd4/0x110 [ 71.986205] usbsetconfiguration+0x57a/0x820 [ 71.986208] usbgenericdriverprobe+0x4f/0x70 [ 71.986211] usbprobedevice+0x3a/0x110 [ 71.986213] reallyprobe+0xdb/0x380 [ 71.986216] ? pmruntimebarrier+0x54/0x90 [ 71.986219] driverprobedevice+0x78/0x170 [ 71.986221] driverprobedevice+0x1f/0x90 [ 71.986224] deviceattachdriver+0x89/0x110 [ 71.986227] ? driverallowsasyncprobing+0x70/0x70 [ 71.986230] busforeachdrv+0x8c/0xe0 [ 71.986232] deviceattach+0xb2/0x1e0 [ 71.986235] busprobedevice+0x92/0xb0 [ 71.986237] deviceadd+0x422/0x9a0 [ 71.986239] ? devinfo+0x7d/0x98 [ 71.986242] ? blake2supdate+0x4c/0xc0 [ 71.986246] usbnewdevice.cold+0x148/0x36d [ 71.986250] hubevent+0xa8a/0x1910 [ 71.986255] processonework+0x1c4/0x380 [ 71.986259] workerthread+0x51/0x390 [ 71.986262] ? rescuerthread+0x3b0/0x3b0 [ 71.986264] kthread+0xdb/0x110 [ 71.986266] ? kthreadcompleteandexit+0x20/0x20 [ 71.986268] retfromfork+0x1f/0x30 [ 71.986273] </TASK> [ 71.986274] ---[ end trace 0000000000000000 ]--- [ 71.986284] btusb: probe of 2-1.6:1.0 failed with error -17
In the Linux kernel, the following vulnerability has been resolved:
netfilter: conntrack: fix using thiscpuadd in preemptible
Currently in nfconntrackhashcheckinsert(), when it fails in nfctextvalidpre/post(), NFCTSTATINC() will be called in the preemptible context, a call trace can be triggered:
BUG: using thiscpuadd() in preemptible [00000000] code: conntrack/1636 caller is nfconntrackhashcheckinsert+0x45/0x430 [nfconntrack] Call Trace: <TASK> dumpstacklvl+0x33/0x46 checkpreemptiondisabled+0xc3/0xf0 nfconntrackhashcheckinsert+0x45/0x430 [nfconntrack] ctnetlinkcreateconntrack+0x3cd/0x4e0 [nfconntracknetlink] ctnetlinknewconntrack+0x1c0/0x450 [nfconntracknetlink] nfnetlinkrcvmsg+0x277/0x2f0 [nfnetlink] netlinkrcvskb+0x50/0x100 nfnetlinkrcv+0x65/0x144 [nfnetlink] netlinkunicast+0x1ae/0x290 netlinksendmsg+0x257/0x4f0 socksendmsg+0x5f/0x70
This patch is to fix it by changing to use NFCTSTATINCATOMIC() for nfctextvalidpre/post() check in nfconntrackhashcheckinsert(), as well as nfctextvalidpost() in nfconntrackconfirm().
Note that nfctextvalidpre() check in nfconntrackconfirm() is safe to use NFCTSTATINC(), as it's under localbhdisable().
In the Linux kernel, the following vulnerability has been resolved:
ASoC: soc-pcm: Add NULL check in BE reparenting
Add NULL check in dpcmbereparent API, to handle kernel NULL pointer dereference error. The issue occurred in fuzzing test.
In the Linux kernel, the following vulnerability has been resolved:
HID: core: fix shift-out-of-bounds in hidreportrawevent
Syzbot reported shift-out-of-bounds in hidreportrawevent.
microsoft 0003:045E:07DA.0001: hidfieldextract() called with n (128) > 32! (swapper/0) ====================================================================== UBSAN: shift-out-of-bounds in drivers/hid/hid-core.c:1323:20 shift exponent 127 is too large for 32-bit type 'int' CPU: 0 PID: 0 Comm: swapper/0 Not tainted 6.1.0-rc4-syzkaller-00159-g4bbf3422df78 #0 Hardware name: Google Compute Engine/Google Compute Engine, BIOS Google 10/26/2022 Call Trace: <IRQ> dumpstack lib/dumpstack.c:88 [inline] dumpstacklvl+0x1e3/0x2cb lib/dumpstack.c:106 ubsanepilogue lib/ubsan.c:151 [inline] ubsanhandleshiftoutofbounds+0x3a6/0x420 lib/ubsan.c:322 snto32 drivers/hid/hid-core.c:1323 [inline] hidinputfetchfield drivers/hid/hid-core.c:1572 [inline] hidprocessreport drivers/hid/hid-core.c:1665 [inline] hidreportrawevent+0xd56/0x18b0 drivers/hid/hid-core.c:1998 hidinputreport+0x408/0x4f0 drivers/hid/hid-core.c:2066 hidirqin+0x459/0x690 drivers/hid/usbhid/hid-core.c:284 usbhcdgivebackurb+0x369/0x530 drivers/usb/core/hcd.c:1671 dummytimer+0x86b/0x3110 drivers/usb/gadget/udc/dummyhcd.c:1988 calltimerfn+0xf5/0x210 kernel/time/timer.c:1474 expiretimers kernel/time/timer.c:1519 [inline] runtimers+0x76a/0x980 kernel/time/timer.c:1790 runtimersoftirq+0x63/0xf0 kernel/time/timer.c:1803 dosoftirq+0x277/0x75b kernel/softirq.c:571 irqexitrcu+0xec/0x170 kernel/softirq.c:650 irqexitrcu+0x5/0x20 kernel/softirq.c:662 sysvecapictimerinterrupt+0x91/0xb0 arch/x86/kernel/apic/apic.c:1107 ======================================================================
If the size of the integer (unsigned n) is bigger than 32 in snto32(), shift exponent will be too large for 32-bit type 'int', resulting in a shift-out-of-bounds bug. Fix this by adding a check on the size of the integer (unsigned n) in snto32(). To add support for n greater than 32 bits, set n to 32, if n is greater than 32.
In the Linux kernel, the following vulnerability has been resolved:
net: mdio: fix unbalanced fwnode reference count in mdiodevicerelease()
There is warning report about ofnode refcount leak while probing mdio device:
OF: ERROR: memory leak, expected refcount 1 instead of 2, ofnodeget()/ofnodeput() unbalanced - destroy cset entry: attach overlay node /spi/soc@0/mdio@710700c0/ethernet@4
In ofmdiobusregisterdevice(), we increase fwnode refcount by fwnodehandleget() before associating the ofnode with mdio device, but it has never been decreased in normal path. Since that, in mdiodevicerelease(), it needs to call fwnodehandleput() in addition instead of calling kfree() directly.
After above, just calling mdiodevicefree() in the error handle path of ofmdiobusregisterdevice() is enough to keep the refcount balanced.
In the Linux kernel, the following vulnerability has been resolved:
iouring: Fix a null-ptr-deref in iotctxexitcb()
Syzkaller reports a NULL deref bug as follows:
BUG: KASAN: null-ptr-deref in iotctxexitcb+0x53/0xd3 Read of size 4 at addr 0000000000000138 by task file1/1955
CPU: 1 PID: 1955 Comm: file1 Not tainted 6.1.0-rc7-00103-gef4d3ea40565 #75 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.11.0-2.el7 04/01/2014 Call Trace: <TASK> dumpstacklvl+0xcd/0x134 ? iotctxexitcb+0x53/0xd3 kasanreport+0xbb/0x1f0 ? iotctxexitcb+0x53/0xd3 kasancheckrange+0x140/0x190 iotctxexitcb+0x53/0xd3 taskworkrun+0x164/0x250 ? taskworkcancel+0x30/0x30 getsignal+0x1c3/0x2440 ? lockdowngrade+0x6e0/0x6e0 ? lockdowngrade+0x6e0/0x6e0 ? exitsignals+0x8b0/0x8b0 ? dorawreadunlock+0x3b/0x70 ? dorawspinunlock+0x50/0x230 archdosignalorrestart+0x82/0x2470 ? kmemcachefree+0x260/0x4b0 ? putname+0xfe/0x140 ? getsigframesize+0x10/0x10 ? doexecveatcommon.isra.0+0x226/0x710 ? lockdephardirqson+0x79/0x100 ? putname+0xfe/0x140 ? doexecveatcommon.isra.0+0x238/0x710 exittousermodeprepare+0x15f/0x250 syscallexittousermode+0x19/0x50 dosyscall64+0x42/0xb0 entrySYSCALL64afterhwframe+0x63/0xcd RIP: 0023:0x0 Code: Unable to access opcode bytes at 0xffffffffffffffd6. RSP: 002b:00000000fffb7790 EFLAGS: 00000200 ORIGRAX: 000000000000000b RAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000000000000 RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000 RBP: 0000000000000000 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000000 R12: 0000000000000000 R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000 </TASK> Kernel panic - not syncing: paniconwarn set ...
This happens because the adding of taskwork from ioringexitwork() isn't synchronized with canceling all work items from eg exec. The execution of the two are ordered in that they are both run by the task itself, but if iotctxexitcb() is queued while we're canceling all work items off exec AND gets executed when the task exits to userspace rather than in the main loop in iouringcancelgeneric(), then we can find current->iouring == NULL and hit the above crash.
It's safe to add this NULL check here, because the execution of the two paths are done by the task itself.
[axboe: add code comment and also put an explanation in the commit msg]
In the Linux kernel, the following vulnerability has been resolved:
net: wwan: iosm: fix memory leak in ipcmuxinit()
When failed to alloc ipcmux->uladb.ppqlt in ipcmuxinit(), ipcmux is not released.
In the Linux kernel, the following vulnerability has been resolved:
can: slcan: fix freed work crash
The LTP test pty03 is causing a crash in slcan: BUG: kernel NULL pointer dereference, address: 0000000000000008 #PF: supervisor read access in kernel mode #PF: errorcode(0x0000) - not-present page PGD 0 P4D 0 Oops: 0000 [#1] PREEMPT SMP NOPTI CPU: 0 PID: 348 Comm: kworker/0:3 Not tainted 6.0.8-1-default #1 openSUSE Tumbleweed 9d20364b934f5aab0a9bdf84e8f45cfdfae39dab Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.15.0-0-g2dd4b9b-rebuilt.opensuse.org 04/01/2014 Workqueue: 0x0 (events) RIP: 0010:processonework (/home/rich/kernel/linux/kernel/workqueue.c:706 /home/rich/kernel/linux/kernel/workqueue.c:2185) Code: 49 89 ff 41 56 41 55 41 54 55 53 48 89 f3 48 83 ec 10 48 8b 06 48 8b 6f 48 49 89 c4 45 30 e4 a8 04 b8 00 00 00 00 4c 0f 44 e0 <49> 8b 44 24 08 44 8b a8 00 01 00 00 41 83 e5 20 f6 45 10 04 75 0e RSP: 0018:ffffaf7b40f47e98 EFLAGS: 00010046 RAX: 0000000000000000 RBX: ffff9d644e1b8b48 RCX: ffff9d649e439968 RDX: 00000000ffff8455 RSI: ffff9d644e1b8b48 RDI: ffff9d64764aa6c0 RBP: ffff9d649e4335c0 R08: 0000000000000c00 R09: ffff9d64764aa734 R10: 0000000000000007 R11: 0000000000000001 R12: 0000000000000000 R13: ffff9d649e4335e8 R14: ffff9d64490da780 R15: ffff9d64764aa6c0 FS: 0000000000000000(0000) GS:ffff9d649e400000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000008 CR3: 0000000036424000 CR4: 00000000000006f0 Call Trace: <TASK> workerthread (/home/rich/kernel/linux/kernel/workqueue.c:2436) kthread (/home/rich/kernel/linux/kernel/kthread.c:376) retfromfork (/home/rich/kernel/linux/arch/x86/entry/entry64.S:312)
Apparently, the slcan's txwork is freed while being scheduled. While slcannetdevclose() (netdev side) calls flushwork(&sl->txwork), slcanclose() (tty side) does not. So when the netdev is never set UP, but the tty is stuffed with bytes and forced to wakeup write, the work is scheduled, but never flushed.
So add an additional flushwork() to slcanclose() to be sure the work is flushed under all circumstances.
The Fixes commit below moved flushwork() from slcanclose() to slcannetdevclose(). What was the rationale behind it? Maybe we can drop the one in slcannetdevclose()?
I see the same pattern in can327. So it perhaps needs the very same fix.
In the Linux kernel, the following vulnerability has been resolved:
gpiolib: fix memory leak in gpiochipsetupdev()
Here is a backtrace report about memory leak detected in gpiochipsetupdev():
unreferenced object 0xffff88810b406400 (size 512): comm "python3", pid 1682, jiffies 4295346908 (age 24.090s) backtrace: kmalloctrace deviceadd deviceprivateinit at drivers/base/core.c:3361 (inlined by) deviceadd at drivers/base/core.c:3411 cdevdeviceadd gpiolibcdevregister gpiochipsetupdev gpiochipadddatawithkey
gcdevregister() & gcdevunregister() would call deviceadd() & devicedel() (no matter CONFIGGPIOCDEV is enabled or not) to register/unregister device.
However, if deviceadd() succeeds, some resource (like struct deviceprivate allocated by deviceprivateinit()) is not released by devicedel().
Therefore, after deviceadd() succeeds by gcdevregister(), it needs to call putdevice() to release resource in the error handle path.
Here we move forward the register of release function, and let it release every piece of resource by putdevice() instead of kfree().
While at it, fix another subtle issue, i.e. when gc->ngpio is equal to 0, we still call kcalloc() and, in case of further error, kfree() on the ZEROPTR pointer, which is not NULL. It's not a bug per se, but rather waste of the resources and potentially wrong expectation about contents of the gdev->descs variable.
In the Linux kernel, the following vulnerability has been resolved:
gpio/rockchip: fix refcount leak in rockchipgpiolibregister()
The node returned by ofgetparent() with refcount incremented, ofnodeput() needs be called when finish using it. So add it in the end of ofpinctrlget().
In the Linux kernel, the following vulnerability has been resolved:
rtc: cmos: Fix event handler registration ordering issue
Because acpiinstallfixedeventhandler() enables the event automatically on success, it is incorrect to call it before the handler routine passed to it is ready to handle events.
Unfortunately, the rtc-cmos driver does exactly the incorrect thing by calling cmoswakesetup(), which passes rtchandler() to acpiinstallfixedeventhandler(), before cmosdoprobe(), because rtchandler() uses devgetdrvdata() to get to the cmos object pointer and the driver data pointer is only populated in cmosdoprobe().
This leads to a NULL pointer dereference in rtchandler() on boot if the RTC fixed event happens to be active at the init time.
To address this issue, change the initialization ordering of the driver so that cmoswakesetup() is always called after a successful cmosdoprobe() call.
While at it, change cmospnpprobe() to call cmosdoprobe() after the initial if () statement used for computing the IRQ argument to be passed to cmosdoprobe() which is cleaner than calling it in each branch of that if () (local variable "irq" can be of type int, because it is passed to that function as an argument of type int).
Note that commit 6492fed7d8c9 ("rtc: rtc-cmos: Do not check ACPIFADTLOWPOWERS0") caused this issue to affect a larger number of systems, because previously it only affected systems with ACPIFADTLOWPOWERS0 set, but it is present regardless of that commit.
In the Linux kernel, the following vulnerability has been resolved:
Input: raydiumtsi2c - fix memory leak in raydiumi2csend()
There is a kmemleak when test the raydiumi2cts with bpf mock device:
unreferenced object 0xffff88812d3675a0 (size 8): comm "python3", pid 349, jiffies 4294741067 (age 95.695s) hex dump (first 8 bytes): 11 0e 10 c0 01 00 04 00 ........ backtrace: [<0000000068427125>] kmalloc+0x46/0x1b0 [<0000000090180f91>] raydiumi2csend+0xd4/0x2bf [raydiumi2cts] [<000000006e631aee>] raydiumi2cinitialize.cold+0xbc/0x3e4 [raydiumi2cts] [<00000000dc6fcf38>] raydiumi2cprobe+0x3cd/0x6bc [raydiumi2cts] [<00000000a310de16>] i2cdeviceprobe+0x651/0x680 [<00000000f5a96bf3>] reallyprobe+0x17c/0x3f0 [<00000000096ba499>] driverprobedevice+0xe3/0x170 [<00000000c5acb4d9>] driverprobedevice+0x49/0x120 [<00000000264fe082>] deviceattachdriver+0xf7/0x150 [<00000000f919423c>] busforeachdrv+0x114/0x180 [<00000000e067feca>] deviceattach+0x1e5/0x2d0 [<0000000054301fc2>] busprobedevice+0x126/0x140 [<00000000aad93b22>] deviceadd+0x810/0x1130 [<00000000c086a53f>] i2cnewclientdevice+0x352/0x4e0 [<000000003c2c248c>] ofi2cregisterdevice+0xf1/0x110 [<00000000ffec4177>] ofi2cnotify+0x100/0x160 unreferenced object 0xffff88812d3675c8 (size 8): comm "python3", pid 349, jiffies 4294741070 (age 95.692s) hex dump (first 8 bytes): 22 00 36 2d 81 88 ff ff ".6-.... backtrace: [<0000000068427125>] kmalloc+0x46/0x1b0 [<0000000090180f91>] raydiumi2csend+0xd4/0x2bf [raydiumi2cts] [<000000001d5c9620>] raydiumi2cinitialize.cold+0x223/0x3e4 [raydiumi2cts] [<00000000dc6fcf38>] raydiumi2cprobe+0x3cd/0x6bc [raydiumi2cts] [<00000000a310de16>] i2cdeviceprobe+0x651/0x680 [<00000000f5a96bf3>] reallyprobe+0x17c/0x3f0 [<00000000096ba499>] driverprobedevice+0xe3/0x170 [<00000000c5acb4d9>] driverprobedevice+0x49/0x120 [<00000000264fe082>] deviceattachdriver+0xf7/0x150 [<00000000f919423c>] busforeachdrv+0x114/0x180 [<00000000e067feca>] deviceattach+0x1e5/0x2d0 [<0000000054301fc2>] busprobedevice+0x126/0x140 [<00000000aad93b22>] deviceadd+0x810/0x1130 [<00000000c086a53f>] i2cnewclientdevice+0x352/0x4e0 [<000000003c2c248c>] ofi2cregisterdevice+0xf1/0x110 [<00000000ffec4177>] ofi2cnotify+0x100/0x160
After BANKSWITCH command from i2c BUS, no matter success or error happened, the txbuf should be freed.
In the Linux kernel, the following vulnerability has been resolved:
net: thunderbolt: fix memory leak in tbnetopen()
When tbringallocrx() failed in tbnetopen(), ida that allocated in tbxdomainallocouthopid() is not released. Add tbxdomainreleaseouthopid() to the error path to release ida.
In the Linux kernel, the following vulnerability has been resolved:
Bluetooth: Fix not cleanup led when btinit fails
btinit() calls btledsinit() to register led, but if it fails later, btledscleanup() is not called to unregister it.
This can cause panic if the argument "bluetooth-power" in text is freed and then another ledtriggerregister() tries to access it:
BUG: unable to handle page fault for address: ffffffffc06d3bc0 RIP: 0010:strcmp+0xc/0x30 Call Trace: <TASK> ledtriggerregister+0x10d/0x4f0 ledtriggerregistersimple+0x7d/0x100 btinit+0x39/0xf7 [bluetooth] dooneinitcall+0xd0/0x4e0
In the Linux kernel, the following vulnerability has been resolved:
iavf: Fix error handling in iavfinitmodule()
The iavfinitmodule() won't destroy workqueue when pciregisterdriver() failed. Call destroyworkqueue() when pciregisterdriver() failed to prevent the resource leak.
Similar to the handling of u132hcdinit in commit f276e002793c ("usb: u132-hcd: fix resource leak")
In the Linux kernel, the following vulnerability has been resolved:
mm/damon/sysfs: fix wrong empty schemes assumption under online tuning in damonsysfssetschemes()
Commit da87878010e5 ("mm/damon/sysfs: support online inputs update") made 'damonsysfssetschemes()' to be called for running DAMON context, which could have schemes. In the case, DAMON sysfs interface is supposed to update, remove, or add schemes to reflect the sysfs files. However, the code is assuming the DAMON context wouldn't have schemes at all, and therefore creates and adds new schemes. As a result, the code doesn't work as intended for online schemes tuning and could have more than expected memory footprint. The schemes are all in the DAMON context, so it doesn't leak the memory, though.
Remove the wrong asssumption (the DAMON context wouldn't have schemes) in 'damonsysfssetschemes()' to fix the bug.
In the Linux kernel, the following vulnerability has been resolved:
In the Linux kernel, the following vulnerability has been resolved:
afs: Fix server->active leak in afsputserver
The atomicread was accidentally replaced with atomicincreturn, which prevents the server from getting cleaned up and causes rmmod to hang with a warning:
Can't purge s=00000001