In the Linux kernel, the following vulnerability has been resolved:
net: tls: handle backlogging of crypto requests
Since we're setting the CRYPTOTFMREQMAYBACKLOG flag on our requests to the crypto API, cryptoaead{encrypt,decrypt} can return -EBUSY instead of -EINPROGRESS in valid situations. For example, when the cryptd queue for AESNI is full (easy to trigger with an artificially low cryptd.cryptdmaxcpuqlen), requests will be enqueued to the backlog but still processed. In that case, the async callback will also be called twice: first with err == -EINPROGRESS, which it seems we can just ignore, then with err == 0.
Compared to Sabrina's original patch this version uses the new tlscryptasyncwait() helpers and converts the EBUSY to EINPROGRESS to avoid having to modify all the error handling paths. The handling is identical.
In the Linux kernel, the following vulnerability has been resolved:
tls: fix race between async notify and socket close
The submitting thread (one which called recvmsg/sendmsg) may exit as soon as the async crypto handler calls complete() so any code past that point risks touching already freed data.
Try to avoid the locking and extra flags altogether. Have the main thread hold an extra reference, this way we can depend solely on the atomic ref counter for synchronization.
Don't futz with reiniting the completion, either, we are now tightly controlling when completion fires.
In the Linux kernel, the following vulnerability has been resolved:
tls: fix race between tx work scheduling and socket close
Similarly to previous commit, the submitting thread (recvmsg/sendmsg) may exit as soon as the async crypto handler calls complete(). Reorder scheduling the work before calling complete(). This seems more logical in the first place, as it's the inverse order of what the submitting thread will do.
In the Linux kernel, the following vulnerability has been resolved:
net:emac/emac-mac: Fix a use after free in emacmactxbufsend
In emacmactxbufsend, it calls emactxfilltpd(..,skb,..). If some error happens in emactxfilltpd(), the skb will be freed via devkfreeskb(skb) in error branch of emactxfilltpd(). But the freed skb is still used via skb->len by netdevsentqueue(,skb->len).
As i observed that emactxfilltpd() haven't modified the value of skb->len, thus my patch assigns skb->len to 'len' before the possible free and use 'len' instead of skb->len later.
In the Linux kernel, the following vulnerability has been resolved:
ethernet: hisilicon: hns: hnsdsafmisc: fix a possible array overflow in hnsdsafgesrstbyport()
The if statement: if (port >= DSAFGENUM) return;
limits the value of port less than DSAFGENUM (i.e., 8). However, if the value of port is 6 or 7, an array overflow could occur: portrstoff = dsafdev->maccb[port]->portrstoff;
because the length of dsafdev->maccb is DSAFMAXPORTNUM (i.e., 6).
To fix this possible array overflow, we first check port and if it is greater than or equal to DSAFMAXPORTNUM, the function returns.
In the Linux kernel, the following vulnerability has been resolved:
tipc: fix UAF in error path
Sam Page (sam4k) working with Trend Micro Zero Day Initiative reported a UAF in the tipcbufappend() error path:
BUG: KASAN: slab-use-after-free in kfreeskblistreason+0x47e/0x4c0 linux/net/core/skbuff.c:1183 Read of size 8 at addr ffff88804d2a7c80 by task poc/8034
CPU: 1 PID: 8034 Comm: poc Not tainted 6.8.2 #1 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.0-debian-1.16.0-5 04/01/2014 Call Trace: <IRQ> dumpstack linux/lib/dumpstack.c:88 dumpstacklvl+0xd9/0x1b0 linux/lib/dumpstack.c:106 printaddressdescription linux/mm/kasan/report.c:377 printreport+0xc4/0x620 linux/mm/kasan/report.c:488 kasanreport+0xda/0x110 linux/mm/kasan/report.c:601 kfreeskblistreason+0x47e/0x4c0 linux/net/core/skbuff.c:1183 skbreleasedata+0x5af/0x880 linux/net/core/skbuff.c:1026 skbreleaseall linux/net/core/skbuff.c:1094 kfreeskb linux/net/core/skbuff.c:1108 kfreeskbreason+0x12d/0x210 linux/net/core/skbuff.c:1144 kfreeskb linux/./include/linux/skbuff.h:1244 tipcbufappend+0x425/0xb50 linux/net/tipc/msg.c:186 tipclinkinput+0x224/0x7c0 linux/net/tipc/link.c:1324 tipclinkrcv+0x76e/0x2d70 linux/net/tipc/link.c:1824 tipcrcv+0x45f/0x10f0 linux/net/tipc/node.c:2159 tipcudprecv+0x73b/0x8f0 linux/net/tipc/udpmedia.c:390 udpqueuercvoneskb+0xad2/0x1850 linux/net/ipv4/udp.c:2108 udpqueuercvskb+0x131/0xb00 linux/net/ipv4/udp.c:2186 udpunicastrcvskb+0x165/0x3b0 linux/net/ipv4/udp.c:2346 udp4librcv+0x2594/0x3400 linux/net/ipv4/udp.c:2422 ipprotocoldeliverrcu+0x30c/0x4e0 linux/net/ipv4/ipinput.c:205 iplocaldeliverfinish+0x2e4/0x520 linux/net/ipv4/ipinput.c:233 NFHOOK linux/./include/linux/netfilter.h:314 NFHOOK linux/./include/linux/netfilter.h:308 iplocaldeliver+0x18e/0x1f0 linux/net/ipv4/ipinput.c:254 dstinput linux/./include/net/dst.h:461 iprcvfinish linux/net/ipv4/ipinput.c:449 NFHOOK linux/./include/linux/netfilter.h:314 NFHOOK linux/./include/linux/netfilter.h:308 iprcv+0x2c5/0x5d0 linux/net/ipv4/ipinput.c:569 netifreceiveskbonecore+0x199/0x1e0 linux/net/core/dev.c:5534 netifreceiveskb+0x1f/0x1c0 linux/net/core/dev.c:5648 processbacklog+0x101/0x6b0 linux/net/core/dev.c:5976 napipoll.constprop.0+0xba/0x550 linux/net/core/dev.c:6576 napipoll linux/net/core/dev.c:6645 netrxaction+0x95a/0xe90 linux/net/core/dev.c:6781 dosoftirq+0x21f/0x8e7 linux/kernel/softirq.c:553 dosoftirq linux/kernel/softirq.c:454 dosoftirq+0xb2/0xf0 linux/kernel/softirq.c:441 </IRQ> <TASK> localbhenableip+0x100/0x120 linux/kernel/softirq.c:381 localbhenable linux/./include/linux/bottomhalf.h:33 rcureadunlockbh linux/./include/linux/rcupdate.h:851 devqueuexmit+0x871/0x3ee0 linux/net/core/dev.c:4378 devqueuexmit linux/./include/linux/netdevice.h:3169 neighhhoutput linux/./include/net/neighbour.h:526 neighoutput linux/./include/net/neighbour.h:540 ipfinishoutput2+0x169f/0x2550 linux/net/ipv4/ipoutput.c:235 ipfinishoutput linux/net/ipv4/ipoutput.c:313 ipfinishoutput+0x49e/0x950 linux/net/ipv4/ipoutput.c:295 ipfinishoutput+0x31/0x310 linux/net/ipv4/ipoutput.c:323 NFHOOKCOND linux/./include/linux/netfilter.h:303 ipoutput+0x13b/0x2a0 linux/net/ipv4/ipoutput.c:433 dstoutput linux/./include/net/dst.h:451 iplocalout linux/net/ipv4/ipoutput.c:129 ipsendskb+0x3e5/0x560 linux/net/ipv4/ipoutput.c:1492 udpsendskb+0x73f/0x1530 linux/net/ipv4/udp.c:963 udpsendmsg+0x1a36/0x2b40 linux/net/ipv4/udp.c:1250 inetsendmsg+0x105/0x140 linux/net/ipv4/afinet.c:850 socksendmsgnosec linux/net/socket.c:730 socksendmsg linux/net/socket.c:745 syssendto+0x42c/0x4e0 linux/net/socket.c:2191 dosyssendto linux/net/socket.c:2203 sesyssendto linux/net/socket.c:2199 x64syssendto+0xe0/0x1c0 linux/net/socket.c:2199 dosyscallx64 linux/arch/x86/entry/common.c:52 dosyscall ---truncated---
In the Linux kernel, the following vulnerability has been resolved:
gfs2: Fix potential glock use-after-free on unmount
The Linux kernel CVE team has assigned CVE-2024-38570 to this issue.
Upstream advisory: https://lore.kernel.org/linux-cve-announce/2024061956-CVE-2024-38570-a8ef@gregkh/T
In the Linux kernel, the following vulnerability has been resolved:
of: module: add buffer overflow check in ofmodalias()
In ofmodalias(), if the buffer happens to be too small even for the 1st snprintf() call, the len parameter will become negative and str parameter (if not NULL initially) will point beyond the buffer's end. Add the buffer overflow check after the 1st snprintf() call and fix such check after the strlen() call (accounting for the terminating NUL char).
In the Linux kernel, the following vulnerability has been resolved:
tipc: force a dst refcount before doing decryption
As it says in commit 3bc07321ccc2 ("xfrm: Force a dst refcount before entering the xfrm type handlers"):
"Crypto requests might return asynchronous. In this case we leave the rcu protected region, so force a refcount on the skb's destination entry before we enter the xfrm type input/output handlers."
On TIPC decryption path it has the same problem, and skbdstforce() should be called before doing decryption to avoid a possible crash.
Shuang reported this issue when this warning is triggered:
[] WARNING: include/net/dst.h:337 tipcskrcv+0x1055/0x1ea0 [tipc] [] Kdump: loaded Tainted: G W --------- - - 4.18.0-496.el8.x8664+debug [] Workqueue: crypto cryptdqueueworker [] RIP: 0010:tipcskrcv+0x1055/0x1ea0 [tipc] [] Call Trace: [] tipcskmcastrcv+0x548/0xea0 [tipc] [] tipcrcv+0xcf5/0x1060 [tipc] [] tipcaeaddecryptdone+0x215/0x2e0 [tipc] [] cryptdaeadcrypt+0xdb/0x190 [] cryptdqueueworker+0xed/0x190 [] processonework+0x93d/0x17e0
In the Linux kernel, the following vulnerability has been resolved:
net/sched: Fix UAF when resolving a clash
KASAN reports the following UAF:
BUG: KASAN: slab-use-after-free in tcfctflowtableprocessconn+0x12b/0x380 [actct] Read of size 1 at addr ffff888c07603600 by task handler130/6469
Call Trace: <IRQ> dumpstacklvl+0x48/0x70 printaddressdescription.constprop.0+0x33/0x3d0 printreport+0xc0/0x2b0 kasanreport+0xd0/0x120 asanload1+0x6c/0x80 tcfctflowtableprocessconn+0x12b/0x380 [actct] tcfctact+0x886/0x1350 [actct] tcfactionexec+0xf8/0x1f0 flclassify+0x355/0x360 [clsflower] tcfclassify+0x1fd/0x330 tcfclassify+0x21c/0x3c0 schhandleingress.constprop.0+0x2c5/0x500 netifreceiveskbcore.constprop.0+0xb25/0x1510 netifreceiveskblistcore+0x220/0x4c0 netifreceiveskblistinternal+0x446/0x620 napicompletedone+0x157/0x3d0 grocellpoll+0xcf/0x100 napipoll+0x65/0x310 netrxaction+0x30c/0x5c0 dosoftirq+0x14f/0x491 irqexitrcu+0x82/0xc0 irqexitrcu+0xe/0x20 commoninterrupt+0xa1/0xb0 </IRQ> <TASK> asmcommoninterrupt+0x27/0x40
Allocated by task 6469: kasansavestack+0x38/0x70 kasansettrack+0x25/0x40 kasansaveallocinfo+0x1e/0x40 kasankrealloc+0x133/0x190 krealloc+0xaa/0x130 nfctextadd+0xed/0x230 [nfconntrack] tcfctact+0x1095/0x1350 [actct] tcfactionexec+0xf8/0x1f0 flclassify+0x355/0x360 [clsflower] tcfclassify+0x1fd/0x330 tcfclassify+0x21c/0x3c0 schhandleingress.constprop.0+0x2c5/0x500 netifreceiveskbcore.constprop.0+0xb25/0x1510 netifreceiveskblistcore+0x220/0x4c0 netifreceiveskblistinternal+0x446/0x620 napicompletedone+0x157/0x3d0 grocellpoll+0xcf/0x100 napipoll+0x65/0x310 netrxaction+0x30c/0x5c0 dosoftirq+0x14f/0x491
Freed by task 6469: kasansavestack+0x38/0x70 kasansettrack+0x25/0x40 kasansavefreeinfo+0x2b/0x60 kasanslabfree+0x180/0x1f0 kasanslabfree+0x12/0x30 slabfreefreelisthook+0xd2/0x1a0 kmemcachefree+0x1a2/0x2f0 kfree+0x78/0x120 nfconntrackfree+0x74/0x130 [nfconntrack] nfctdestroy+0xb2/0x140 [nfconntrack] nfctresolveclash+0x529/0x5d0 [nfconntrack] nfctresolveclash+0xf6/0x490 [nfconntrack] nfconntrackconfirm+0x2c6/0x770 [nfconntrack] tcfctact+0x12ad/0x1350 [actct] tcfactionexec+0xf8/0x1f0 flclassify+0x355/0x360 [clsflower] tcfclassify+0x1fd/0x330 tcfclassify+0x21c/0x3c0 schhandleingress.constprop.0+0x2c5/0x500 netifreceiveskbcore.constprop.0+0xb25/0x1510 netifreceiveskblistcore+0x220/0x4c0 netifreceiveskblistinternal+0x446/0x620 napicompletedone+0x157/0x3d0 grocellpoll+0xcf/0x100 napipoll+0x65/0x310 netrxaction+0x30c/0x5c0 dosoftirq+0x14f/0x491
The ct may be dropped if a clash has been resolved but is still passed to the tcfctflowtableprocessconn function for further usage. This issue can be fixed by retrieving ct from skb again after confirming conntrack.
IBM WebSphere Application Server 8.5 and 9.0 could allow a remote attacker to execute arbitrary code on the system with a specially crafted sequence of serialized objects.
json-schema before version 0.4.0 is vulnerable to Improperly Controlled Modification of Object Prototype Attributes ('Prototype Pollution').
A vulnerability was found in technisatusb2getir in drivers/media/usb/dvb-usb/technisat-usb2.c in DVB USB subsystem, there was an out-of-bounds read for an array in struct technisatusb2state state->buf with no boundary check applied until 0xff byte is encountered, if it is not found with in the limits it goes beyond the array size, this exposes kernel data structure which should not happen.
Reference: https://lore.kernel.org/linux-media/20190821104408.w7krumcglxo6fz5q@gofer.mess.org/ https://git.linuxtv.org/mediatree.git/commit/?id=0c4df39e504bf925ab666132ac3c98d6cbbe380b https://lore.kernel.org/lkml/b9b256cb-95f2-5fa1-9956-5a602a017c11@gmail.com/
IBM Security Verify Governance Identity Manager 10.0 virtual appliance component performs an operation at a privilege level that is higher than the minimum level required, which creates new weaknesses or amplifies the consequences of other weaknesses. IBM X-Force ID: 224989.
Improper access control in the Intel(R) Ethernet Controller RDMA driver for linux before version 1.9.30 may allow an unauthenticated user to potentially enable escalation of privilege via network access.
In the Linux kernel, the following vulnerability has been resolved:
atl1c: Work around the DMA RX overflow issue
The Linux kernel CVE team has assigned CVE-2023-52834 to this issue.
Upstream advisory: https://lore.kernel.org/linux-cve-announce/2024052109-CVE-2023-52834-4c46@gregkh/T
In the Linux kernel, the following vulnerability has been resolved:
tunnels: fix out of bounds access when building IPv6 PMTU error
If the ICMPv6 error is built from a non-linear skb we get the following splat,
BUG: KASAN: slab-out-of-bounds in docsum+0x220/0x240 Read of size 4 at addr ffff88811d402c80 by task netperf/820 CPU: 0 PID: 820 Comm: netperf Not tainted 6.8.0-rc1+ #543 ... kasanreport+0xd8/0x110 docsum+0x220/0x240 csumpartial+0xc/0x20 skbtunnelcheckpmtu+0xeb9/0x3280 vxlanxmitone+0x14c2/0x4080 vxlanxmit+0xf61/0x5c00 devhardstartxmit+0xfb/0x510 devqueuexmit+0x7cd/0x32a0 brdevqueuepushxmit+0x39d/0x6a0
Use skbchecksum instead of csumpartial who cannot deal with non-linear SKBs.
In the Linux kernel, the following vulnerability has been resolved:
wifi: iwlwifi: dbg-tlv: ensure NUL termination
The iwlfwinidebuginfotlv is used as a string, so we must ensure the string is terminated correctly before using it.
In the Linux kernel, the following vulnerability has been resolved:
net/mlx5: Properly link new fs rules into the tree
Previously, addrulefg would only add newly created rules from the handle into the tree when they had a refcount of 1. On the other hand, createflowhandle tries hard to find and reference already existing identical rules instead of creating new ones.
These two behaviors can result in a situation where createflowhandle 1) creates a new rule and references it, then 2) in a subsequent step during the same handle creation references it again, resulting in a rule with a refcount of 2 that is not linked into the tree, will have a NULL parent and root and will result in a crash when the flow group is deleted because delswhwrule, invoked on rule deletion, assumes node->parent is != NULL.
This happened in the wild, due to another bug related to incorrect handling of duplicate pktreformat ids, which lead to the code in createflowhandle incorrectly referencing a just-added rule in the same flow handle, resulting in the problem described above. Full details are at [1].
This patch changes addrulefg to add new rules without parents into the tree, properly initializing them and avoiding the crash. This makes it more consistent with how rules are added to an FTE in createflowhandle.
In the Linux kernel, the following vulnerability has been resolved:
wifi: mac80211: don't return unset power in ieee80211gettxpower()
We can get a UBSAN warning if ieee80211gettxpower() returns the INTMIN value mac80211 internally uses for "unset power level".
UBSAN: signed-integer-overflow in net/wireless/nl80211.c:3816:5 -2147483648 100 cannot be represented in type 'int' CPU: 0 PID: 20433 Comm: insmod Tainted: G WC OE Call Trace: dumpstack+0x74/0x92 ubsanepilogue+0x9/0x50 handleoverflow+0x8d/0xd0 ubsanhandlemuloverflow+0xe/0x10 nl80211sendiface+0x688/0x6b0 [cfg80211] [...] cfg80211registerwdev+0x78/0xb0 [cfg80211] cfg80211netdevnotifiercall+0x200/0x620 [cfg80211] [...] ieee80211ifadd+0x60e/0x8f0 [mac80211] ieee80211registerhw+0xda5/0x1170 [mac80211]
In this case, simply return an error instead, to indicate that no data is available.
In the Linux kernel, the following vulnerability has been resolved:
USB: core: Fix access violation during port device removal
Testing with KASAN and syzkaller revealed a bug in port.c:disablestore(): usbhubtostructhub() can return NULL if the hub that the port belongs to is concurrently removed, but the function does not check for this possibility before dereferencing the returned value.
It turns out that the first dereference is unnecessary, since hub->intfdev is the parent of the port device, so it can be changed easily. Adding a check for hub == NULL prevents further problems.
The same bug exists in the disableshow() routine, and it can be fixed the same way.
In the Linux kernel, the following vulnerability has been resolved:
tipc: Return non-zero value from tipcudpaddr2str() on error
tipcudpaddr2str() should return non-zero value if the UDP media address is invalid. Otherwise, a buffer overflow access can occur in tipcmediaaddrprintf(). Fix this by returning 1 on an invalid UDP media address.
https-proxy-agent before 2.1.1 passes auth option to the Buffer constructor without proper sanitization, resulting in DoS and uninitialized memory leak in setups where an attacker could submit typed input to the 'auth' parameter (e.g. JSON).
In the Linux kernel, the following vulnerability has been resolved:
wifi: mac80211: fix potential key use-after-free
The Linux kernel CVE team has assigned CVE-2023-52530 to this issue.
Upstream advisory: https://lore.kernel.org/linux-cve-announce/2024030255-CVE-2023-52530-ebf0@gregkh/T/#u
In the Linux kernel, the following vulnerability has been resolved:
Bluetooth: Avoid potential use-after-free in hcierrorreset
The Linux kernel CVE team has assigned CVE-2024-26801 to this issue.
Upstream advisory: https://lore.kernel.org/linux-cve-announce/2024040403-CVE-2024-26801-da9f@gregkh/T
In the Linux kernel, the following vulnerability has been resolved:
swiotlb: Fix double-allocation of slots due to broken alignment handling
Commit bbb73a103fbb ("swiotlb: fix a braino in the alignment check fix"), which was a fix for commit 0eee5ae10256 ("swiotlb: fix slot alignment checks"), causes a functional regression with vsock in a virtual machine using bouncing via a restricted DMA SWIOTLB pool.
When virtio allocates the virtqueues for the vsock device using dmaalloccoherent(), the SWIOTLB search can return page-unaligned allocations if 'area->index' was left unaligned by a previous allocation from the buffer:
# Final address in brackets is the SWIOTLB address returned to the caller | virtio-pci 0000:00:07.0: origaddr 0x0 allocsize 0x2000, iotlbalignmask 0x800 stride 0x2: got slot 1645-1649/7168 (0x98326800) | virtio-pci 0000:00:07.0: origaddr 0x0 allocsize 0x2000, iotlbalignmask 0x800 stride 0x2: got slot 1649-1653/7168 (0x98328800) | virtio-pci 0000:00:07.0: origaddr 0x0 allocsize 0x2000, iotlbalignmask 0x800 stride 0x2: got slot 1653-1657/7168 (0x9832a800)
This ends badly (typically buffer corruption and/or a hang) because swiotlballoc() is expecting a page-aligned allocation and so blindly returns a pointer to the 'struct page' corresponding to the allocation, therefore double-allocating the first half (2KiB slot) of the 4KiB page.
Fix the problem by treating the allocation alignment separately to any additional alignment requirements from the device, using the maximum of the two as the stride to search the buffer slots and taking care to ensure a minimum of page-alignment for buffers larger than a page.
This also resolves swiotlb allocation failures occuring due to the inclusion of ~PAGEMASK in 'iotlbalignmask' for large allocations and resulting in alignment requirements exceeding swiotlbmaxmappingsize().
In the Linux kernel, the following vulnerability has been resolved:
mlxsw: spectrumacltcam: Fix possible use-after-free during rehash
The Linux kernel CVE team has assigned CVE-2024-35854 to this issue.
Upstream advisory: https://lore.kernel.org/linux-cve-announce/2024051740-CVE-2024-35854-d17b@gregkh/T
In the Linux kernel, the following vulnerability has been resolved:
wifi: iwlwifi: mvm: guard against invalid STA ID on removal
Guard against invalid station IDs in iwlmvmmldrmstaid as that would result in out-of-bounds array accesses. This prevents issues should the driver get into a bad state during error handling.
In the Linux kernel, the following vulnerability has been resolved:
wifi: cfg80211: Lock wiphy in cfg80211getstation
Wiphy should be locked before calling rdevgetstation() (see lockdep assert in ieee80211getstation()).
This fixes the following kernel NULL dereference:
Unable to handle kernel NULL pointer dereference at virtual address 0000000000000050 Mem abort info: ESR = 0x0000000096000006 EC = 0x25: DABT (current EL), IL = 32 bits SET = 0, FnV = 0 EA = 0, S1PTW = 0 FSC = 0x06: level 2 translation fault Data abort info: ISV = 0, ISS = 0x00000006 CM = 0, WnR = 0 user pgtable: 4k pages, 48-bit VAs, pgdp=0000000003001000 [0000000000000050] pgd=0800000002dca003, p4d=0800000002dca003, pud=08000000028e9003, pmd=0000000000000000 Internal error: Oops: 0000000096000006 [#1] SMP Modules linked in: netconsole dwc3mesong12a dwc3ofsimple dwc3 ipgre gre ath10kpci ath10kcore ath9k ath9kcommon ath9khw ath CPU: 0 PID: 1091 Comm: kworker/u8:0 Not tainted 6.4.0-02144-g565f9a3a7911-dirty #705 Hardware name: RPT (r1) (DT) Workqueue: batevents batadvvelpthroughputmetricupdate pstate: 60000005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : ath10kstastatistics+0x10/0x2dc [ath10kcore] lr : stasetsinfo+0xcc/0xbd4 sp : ffff000007b43ad0 x29: ffff000007b43ad0 x28: ffff0000071fa900 x27: ffff00000294ca98 x26: ffff000006830880 x25: ffff000006830880 x24: ffff00000294c000 x23: 0000000000000001 x22: ffff000007b43c90 x21: ffff800008898acc x20: ffff00000294c6e8 x19: ffff000007b43c90 x18: 0000000000000000 x17: 445946354d552d78 x16: 62661f7200000000 x15: 57464f445946354d x14: 0000000000000000 x13: 00000000000000e3 x12: d5f0acbcebea978e x11: 00000000000000e3 x10: 000000010048fe41 x9 : 0000000000000000 x8 : ffff000007b43d90 x7 : 000000007a1e2125 x6 : 0000000000000000 x5 : ffff0000024e0900 x4 : ffff800000a0250c x3 : ffff000007b43c90 x2 : ffff00000294ca98 x1 : ffff000006831920 x0 : 0000000000000000 Call trace: ath10kstastatistics+0x10/0x2dc [ath10kcore] stasetsinfo+0xcc/0xbd4 ieee80211getstation+0x2c/0x44 cfg80211getstation+0x80/0x154 batadvvelpgetthroughput+0x138/0x1fc batadvvelpthroughputmetricupdate+0x1c/0xa4 processonework+0x1ec/0x414 workerthread+0x70/0x46c kthread+0xdc/0xe0 retfromfork+0x10/0x20 Code: a9bb7bfd 910003fd a90153f3 f9411c40 (f9402814)
This happens because STA has time to disconnect and reconnect before batadvvelpthroughputmetricupdate() delayed work gets scheduled. In this situation, ath10kstastate() can be in the middle of resetting arsta data when the work queue get chance to be scheduled and ends up accessing it. Locking wiphy prevents that.
A denial-of-service (DoS) attack was found in the mlx5 driver in the Linux kernel. A KVM guest VM using virtio-net can crash the host by sending a short packet (i.e. size < ETHHLEN). The packet may traverse through vhost-net, macvtap and vlan without any validation/drop. When this packet is presented to mlx5 driver on the host side, the kernel panic happens, since mlx5core assumes the frame size is always >= ETHHLEN.
This vulnerability affects both drivers/net/tun.c and drivers/net/tap.c. CVE-2024-41090 has been assigned to the TAP side of the issue.
Reference: https://www.openwall.com/lists/oss-security/2024/07/24/4