In the Linux kernel, the following vulnerability has been resolved:
Input: aiptek - properly check endpoint type
Syzbot reported warning in usbsubmiturb() which is caused by wrong endpoint type. There was a check for the number of endpoints, but not for the type of endpoint.
Fix it by replacing old desc.bNumEndpoints check with usbfindcommonendpoints() helper for finding endpoints
Fail log:
usb 5-1: BOGUS urb xfer, pipe 1 != type 3 WARNING: CPU: 2 PID: 48 at drivers/usb/core/urb.c:502 usbsubmiturb+0xed2/0x18a0 drivers/usb/core/urb.c:502 Modules linked in: CPU: 2 PID: 48 Comm: kworker/2:2 Not tainted 5.17.0-rc6-syzkaller-00226-g07ebd38a0da2 #0 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.14.0-2 04/01/2014 Workqueue: usbhubwq hubevent ... Call Trace: aiptekopen+0xd5/0x130 drivers/input/tablet/aiptek.c:830 inputopendevice+0x1bb/0x320 drivers/input/input.c:629 kbdconnect+0xfe/0x160 drivers/tty/vt/keyboard.c:1593
In the Linux kernel, the following vulnerability has been resolved:
ACPI: LPIT: Avoid u32 multiplication overflow
In lpitupdateresidency() there is a possibility of overflow in multiplication, if tsckhz is large enough (> UINTMAX/1000).
Change multiplication to mulu32u32().
Found by Linux Verification Center (linuxtesting.org) with SVACE.
In the Linux kernel, the following vulnerability has been resolved:
drm/amd/display: Fix potential null-deref in dmresume
[Why] Fixing smatch error: dmresume() error: we previously assumed 'aconnector->dclink' could be null
[How] Check if dclink null at the beginning of the loop, so further checks can be dropped.
In the Linux kernel, the following vulnerability has been resolved:
arm64: fix oops in concurrently setting insnemulation sysctls
emulationprochandler() changes table->data for procdointvecminmax and can generate the following Oops if called concurrently with itself:
| Unable to handle kernel NULL pointer dereference at virtual address 0000000000000010 | Internal error: Oops: 96000006 [#1] SMP | Call trace: | updateinsnemulationmode+0xc0/0x148 | emulationprochandler+0x64/0xb8 | procsyscallhandler+0x9c/0xf8 | procsyswrite+0x18/0x20 | vfswrite+0x20/0x48 | vfswrite+0xe4/0x1d0 | ksyswrite+0x70/0xf8 | arm64syswrite+0x20/0x28 | el0svccommon.constprop.0+0x7c/0x1c0 | el0svchandler+0x2c/0xa0 | el0svc+0x8/0x200
To fix this issue, keep the table->data as &insn->currentmode and use containerof() to retrieve the insn pointer. Another mutex is used to protect against the currentmode update but not for retrieving insnemulation as table->data is no longer changing.
In the Linux kernel, the following vulnerability has been resolved:
media: venus: hfi: avoid null dereference in deinit
If venusprobe fails at pmruntimeputsync the error handling first calls hfidestroy and afterwards hficoredeinit. As hfidestroy sets core->ops to NULL, hficoredeinit cannot call the coredeinit function anymore.
Avoid this null pointer derefence by skipping the call when necessary.
Rejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.
In the Linux kernel, the following vulnerability has been resolved:
riscv: Fix sleeping in invalid context in die()
die() can be called in exception handler, and therefore cannot sleep. However, die() takes spinlockt which can sleep with PREEMPTRT enabled. That causes the following warning:
BUG: sleeping function called from invalid context at kernel/locking/spinlockrt.c:48 inatomic(): 1, irqsdisabled(): 1, nonblock: 0, pid: 285, name: mutex preemptcount: 110001, expected: 0 RCU nest depth: 0, expected: 0 CPU: 0 UID: 0 PID: 285 Comm: mutex Not tainted 6.12.0-rc7-00022-ge19049cf7d56-dirty #234 Hardware name: riscv-virtio,qemu (DT) Call Trace: dumpbacktrace+0x1c/0x24 showstack+0x2c/0x38 dumpstacklvl+0x5a/0x72 dumpstack+0x14/0x1c mightresched+0x130/0x13a rtspinlock+0x2a/0x5c die+0x24/0x112 dotrapinsnillegal+0xa0/0xea newvmallocrestorecontexta0+0xcc/0xd8 Oops - illegal instruction [#1]
Switch to use rawspinlockt, which does not sleep even with PREEMPTRT enabled.
drm/amd/display: Fix by adding FPU protection for dcn30internalvalidatebw
In the Linux kernel, the following vulnerability has been resolved:
drm/amd/display: Fix dclink NULL handling in HPD init
amdgpudmhpdinit() may see connectors without a valid dclink.
The code already checks dclink for the polling decision, but later unconditionally dereferences it when setting up HPD interrupts.
Assign dclink early and skip connectors where it is NULL.
Fixes the below: drivers/gpu/drm/amd/amdgpu/../display/amdgpudm/amdgpudmirq.c:940 amdgpudmhpdinit() error: we previously assumed 'dclink' could be null (see line 931)
drivers/gpu/drm/amd/amdgpu/../display/amdgpudm/amdgpudmirq.c 923 / 924 Analog connectors may be hot-plugged unlike other connector 925 types that don't support HPD. Only poll analog connectors. 926 / 927 usepolling |= 928 amdgpudmconnector->dclink && ^^^^^^^^^^^^^^^^^^^^^^^^^^^^ The patch adds this NULL check but hopefully it can be removed
929 dcconnectorsupportsanalog(amdgpudmconnector->dclink->linkid.id); 930 931 dclink = amdgpudmconnector->dclink;
dclink assigned here.
932 933 / 934 Get a base driver irq reference for hpd ints for the lifetime 935 of dm. Note that only hpd interrupt types are registered with 936 base driver; hpdrx types aren't. IOW, amdgpuirqget/put on 937 hpdrx isn't available. DM currently controls hpdrx 938 explicitly with dcinterruptset() 939 / --> 940 if (dclink->irqsourcehpd != DCIRQSOURCEINVALID) { ^^^^^^^^^^^^^^^^^^^^^^^ If it's NULL then we are trouble because we dereference it here.
941 irqtype = dclink->irqsourcehpd - DCIRQSOURCEHPD1; 942 / 943 TODO: There's a mismatch between modeinfo.numhpd 944 and what bios reports as the # of connectors with hpd
efi/capsule-loader: fix incorrect sizeof in phys array reallocation
In the Linux kernel, the following vulnerability has been resolved:
bridge: brndsend: validate ND option lengths
brndsend() walks ND options according to option-provided lengths. A malformed option can make the parser advance beyond the computed option span or use a too-short source LLADDR option payload.
Validate option lengths against the remaining NS option area before advancing, and only read source LLADDR when the option is large enough for an Ethernet address.
In the Linux kernel, the following vulnerability has been resolved:
net/sched: clsflow: fix NULL pointer dereference on shared blocks
flowchange() calls tcfblockq() and dereferences q->handle to derive a default baseclass. Shared blocks leave block->q NULL, causing a NULL deref when a flow filter without a fully qualified baseclass is created on a shared block.
Check tcfblockshared() before accessing block->q and return -EINVAL for shared blocks. This avoids the null-deref shown below:
======================================================================= KASAN: null-ptr-deref in range [0x0000000000000038-0x000000000000003f] RIP: 0010:flowchange (net/sched/clsflow.c:508) Call Trace: tcnewtfilter (net/sched/clsapi.c:2432) rtnetlinkrcvmsg (net/core/rtnetlink.c:6980) [...] =======================================================================
In the Linux kernel, the following vulnerability has been resolved:
net/sched: clsfw: fix NULL pointer dereference on shared blocks
The old-method path in fwclassify() calls tcfblockq() and dereferences q->handle. Shared blocks leave block->q NULL, causing a NULL deref when an empty clsfw filter is attached to a shared block and a packet with a nonzero major skb mark is classified.
Reject the configuration in fwchange() when the old method (no TCAOPTIONS) is used on a shared block, since fwclassify()'s old-method path needs block->q which is NULL for shared blocks.
The fixed null-ptr-deref calling stack: KASAN: null-ptr-deref in range [0x0000000000000038-0x000000000000003f] RIP: 0010:fwclassify (net/sched/clsfw.c:81) Call Trace: tcfclassify (./include/net/tcwrapper.h:197 net/sched/clsapi.c:1764 net/sched/clsapi.c:1860) tcrun (net/core/dev.c:4401) devqueuexmit (net/core/dev.c:4535 net/core/dev.c:4790)
In the Linux kernel, the following vulnerability has been resolved:
net: bridge: fix ndtbl NULL dereference when IPv6 is disabled
When booting with the 'ipv6.disable=1' parameter, the ndtbl is never initialized because inet6init() exits before ndiscinit() is called which initializes it. Then, if neighsuppress is enabled and an ICMPv6 Neighbor Discovery packet reaches the bridge, brdosuppressnd() will dereference ipv6stub->ndtbl which is NULL, passing it to neighlookup(). This causes a kernel NULL pointer dereference.
BUG: kernel NULL pointer dereference, address: 0000000000000268 Oops: 0000 [#1] PREEMPT SMP NOPTI [...] RIP: 0010:neighlookup+0x16/0xe0 [...] Call Trace: <IRQ> ? neighlookup+0x16/0xe0 brdosuppressnd+0x160/0x290 [bridge] brhandleframefinish+0x500/0x620 [bridge] brhandleframe+0x353/0x440 [bridge] netifreceiveskbcore.constprop.0+0x298/0x1110 netifreceiveskbonecore+0x3d/0xa0 processbacklog+0xa0/0x140 napipoll+0x2c/0x170 netrxaction+0x2c4/0x3a0 handlesoftirqs+0xd0/0x270 dosoftirq+0x3f/0x60
Fix this by replacing ISENABLED(IPV6) call with ipv6modenabled() in the callers. This is in essence disabling NS/NA suppression when IPv6 is disabled.
In the Linux kernel, the following vulnerability has been resolved:
dmaengine: stm32: dmamux: fix device leak on route allocation
Make sure to drop the reference taken when looking up the DMA mux platform device during route allocation.
Note that holding a reference to a device does not prevent its driver data from going away so there is no point in keeping the reference.
In the Linux kernel, the following vulnerability has been resolved:
powerpc/xics: fix refcount leak in icpopalinit()
The offindcompatiblenode() function returns a node pointer with refcount incremented, use ofnodeput() on it when done.
In the Linux kernel, the following vulnerability has been resolved:
usbnet: fix memory leak in error case
usbnetwritecmdasync() mixed up which buffers need to be freed in which error case.
v2: add Fixes tag v3: fix uninitialized buf pointer
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: usb: smsc75xx: Limit packet length to skb->len
Packet length retrieved from skb data may be larger than the actual socket buffer length (up to 9026 bytes). In such case the cloned skb passed up the network stack will leak kernel memory contents.
In the Linux kernel, the following vulnerability has been resolved:
ext4: avoid resizing to a partial cluster size
This patch avoids an attempt to resize the filesystem to an unaligned cluster boundary. An online resize to a size that is not integral to cluster size results in the last iteration attempting to grow the fs by a negative amount, which trips a BUGON and leaves the fs with a corrupted in-memory superblock.
In the Linux kernel, the following vulnerability has been resolved:
ip6mr: Fix skbunderpanic in ip6mrcachereport()
skbuff: skbunderpanic: text:ffffffff88771f69 len:56 put:-4 head:ffff88805f86a800 data:ffff887f5f86a850 tail:0x88 end:0x2c0 dev:pim6reg ------------[ cut here ]------------ kernel BUG at net/core/skbuff.c:192! invalid opcode: 0000 [#1] PREEMPT SMP KASAN CPU: 2 PID: 22968 Comm: kworker/2:11 Not tainted 6.5.0-rc3-00044-g0a8db05b571a #236 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014 Workqueue: ipv6addrconf addrconfdadwork RIP: 0010:skbpanic+0x152/0x1d0 Call Trace: <TASK> skbpush+0xc4/0xe0 ip6mrcachereport+0xd69/0x19b0 regvifxmit+0x406/0x690 devhardstartxmit+0x17e/0x6e0 devqueuexmit+0x2d6a/0x3d20 vlandevhardstartxmit+0x3ab/0x5c0 devhardstartxmit+0x17e/0x6e0 devqueuexmit+0x2d6a/0x3d20 neighconnectedoutput+0x3ed/0x570 ip6finishoutput2+0x5b5/0x1950 ip6finishoutput+0x693/0x11c0 ip6output+0x24b/0x880 NFHOOK.constprop.0+0xfd/0x530 ndiscsendskb+0x9db/0x1400 ndiscsendrs+0x12a/0x6c0 addrconfdadcompleted+0x3c9/0xea0 addrconfdadwork+0x849/0x1420 processonework+0xa22/0x16e0 workerthread+0x679/0x10c0 retfromfork+0x28/0x60 retfromforkasm+0x11/0x20
When setup a vlan device on dev pim6reg, DAD ns packet may sent on regvifxmit(). regvifxmit() ip6mrcachereport() skbpush(skb, -skbnetworkoffset(pkt));//skbnetworkoffset(pkt) is 4 And skbpush declared as: void skbpush(struct skbuff skb, unsigned int len); skb->data -= len; //0xffff88805f86a84c - 0xfffffffc = 0xffff887f5f86a850 skb->data is set to 0xffff887f5f86a850, which is invalid mem addr, lead to skbpush() fails.
In the Linux kernel, the following vulnerability has been resolved:
KVM: SVM: Don't BUG if userspace injects an interrupt with GIF=0
Don't BUG/WARN on interrupt injection due to GIF being cleared, since it's trivial for userspace to force the situation via KVMSETVCPUEVENTS (even if having at least a WARN there would be correct for KVM internally generated injections).
kernel BUG at arch/x86/kvm/svm/svm.c:3386! invalid opcode: 0000 [#1] SMP CPU: 15 PID: 926 Comm: smmtest Not tainted 5.17.0-rc3+ #264 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 0.0.0 02/06/2015 RIP: 0010:svminjectirq+0xab/0xb0 [kvmamd] Code: <0f> 0b 0f 1f 00 0f 1f 44 00 00 80 3d ac b3 01 00 00 55 48 89 f5 53 RSP: 0018:ffffc90000b37d88 EFLAGS: 00010246 RAX: 0000000000000000 RBX: ffff88810a234ac0 RCX: 0000000000000006 RDX: 0000000000000000 RSI: ffffc90000b37df7 RDI: ffff88810a234ac0 RBP: ffffc90000b37df7 R08: ffff88810a1fa410 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000000 R12: 0000000000000000 R13: ffff888109571000 R14: ffff88810a234ac0 R15: 0000000000000000 FS: 0000000001821380(0000) GS:ffff88846fdc0000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f74fc550008 CR3: 000000010a6fe000 CR4: 0000000000350ea0 Call Trace: <TASK> injectpendingevent+0x2f7/0x4c0 [kvm] kvmarchvcpuioctlrun+0x791/0x17a0 [kvm] kvmvcpuioctl+0x26d/0x650 [kvm] x64sysioctl+0x82/0xb0 dosyscall64+0x3b/0xc0 entrySYSCALL64afterhwframe+0x44/0xae </TASK>
In the Linux kernel, the following vulnerability has been resolved:
wifi: ath9k: don't allow to overwrite ENDPOINT0 attributes
A bad USB device is able to construct a service connection response message with target endpoint being ENDPOINT0 which is reserved for HTCCTRLRSVDSVC and should not be modified to be used for any other services.
Reject such service connection responses.
Found by Linux Verification Center (linuxtesting.org) with Syzkaller.
In the Linux kernel, the following vulnerability has been resolved:
mmc: core: Avoid bitfield RMW for claim/retune flags
Move claimed and retune control flags out of the bitfield word to avoid unrelated RMW side effects in asynchronous contexts.
The host->claimed bit shared a word with retune flags. Writes to claimed in mmcclaimhost() or retunenow in mmcmqqueuerq() can overwrite other bits when concurrent updates happen in other contexts, triggering spurious WARNON(!host->claimed). Convert claimed, canretune, retunenow and retunepaused to bool to remove shared-word coupling.
An out-of-bounds memory write flaw in the Linux kernel’s USB Monitor component was found in how a user with access to the /dev/usbmon can trigger it by an incorrect write to the memory of the usbmon. This flaw allows a local user to crash or potentially escalate their privileges on the system.
A use-after-free flaw was found in usbsgcancel in drivers/usb/core/message.c in USB core subsystem. This flaw could allow a local attacker with special user privilege (or root) to crash the system due to a race problem in scatter-gather cancellation and transfer completion in usbsgwait. This vulnerability can even lead to a kernel information leak problem .
Here usbsgcancel() does not take any reference to the transfer and there is nothing to prevent the URBs from being deallocated while the routine is trying to use them.
Taking a reference by incrementing the transfer's io->count field while the cancellation is in progress and decrementing it afterwards can be way to address this. The transfer's URBs are not deallocated until io->complete is triggered, which happens when io->count reaches zero. ~~~ BUG: KASAN: use-after-free in atomicread include/asm-generic/atomic-instrumented.h:26 [inline] BUG: KASAN: use-after-free in usbhcdunlinkurb+0x5f/0x170 drivers/usb/core/hcd.c:1607 Read of size 4 at addr ffff888065379610 by task kworker/u4:1/27 ~~~
References: https://cdn.kernel.org/pub/linux/kernel/v5.x/ChangeLog-5.6.8 https://lkml.org/lkml/2020/3/23/52
Upstream commit: https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=056ad39ee9253873522f6469c3364964a322912b
An issue was discovered in the Linux kernel before 5.0.9. There is a use-after-free in atalkprocexit, related to net/appletalk/atalkproc.c, net/appletalk/ddp.c, and net/appletalk/sysctlnetatalk.c.
An error in the "sctpmakechunk()" function (net/sctp/smmakechunk.c) when handling SCTP packets length can be exploited by a malicious local user to cause a kernel crash and a DoS.
References:
https://packetstormsecurity.com/files/146620/secunia-sctpmakechunkdos.txt
https://marc.info/?t=151818093200004&r=1&w=2
https://marc.info/?t=151818682600001&r=1&w=2
An upstream patch:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=07f2c7ab6f8d0a7e7c5764c4e6cc9c52951b9d9c
A flaw was discovered in the Linux kernel's USB subsystem in the usbgetextradescriptor() function in the drivers/usb/core/usb.c which mishandles a size check during the reading of an extra descriptor data. By using a specially crafted USB device which sends a forged extra descriptor, an unprivileged user with physical access to the system can potentially cause a privilege escalation or trigger a system crash or lock up and thus to cause a denial of service (DoS).
A flaw was found in the latest Linux kernel. A out-of-bounds write of kernel address space may be triggered via uncontrolled userland provided offset in ebtentry struct in netfilter/ebtables.c.
References:
https://marc.info/?l=linux-netdev&m=152023808817590&w=2
https://marc.info/?l=linux-netdev&m=152025888924151&w=2
An upsteam patch:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=b71812168571fa55e44cdd0254471331b9c4c4c6
https://github.com/torvalds/linux/commit/b71812168571fa55e44cdd0254471331b9c4c4c6