Chromium: CVE-2024-4761 Out of bounds write in V8
Chromium: CVE-2024-4947 Type Confusion in V8
Chromium: CVE-2024-4671 Use after free in Visuals
The debugger in affected versions of Werkzeug can allow an attacker to execute code on a developer's machine under some circumstances. This requires the attacker to get the developer to interact with a domain and subdomain they control, and enter the debugger PIN, but if they are successful it allows access to the debugger even if it is only running on localhost. This also requires the attacker to guess a URL in the developer's application that will trigger the debugger.
In the Linux kernel, the following vulnerability has been resolved:
comedi: vmk80xx: fix incomplete endpoint checking
While vmk80xx does have endpoint checking implemented, some things can fall through the cracks. Depending on the hardware model, URBs can have either bulk or interrupt type, and current version of vmk80xxfindusbendpoints() function does not take that fully into account. While this warning does not seem to be too harmful, at the very least it will crash systems with 'paniconwarn' set on them.
Fix the issue found by Syzkaller [1] by somewhat simplifying the endpoint checking process with usbfindcommonendpoints() and ensuring that only expected endpoint types are present.
This patch has not been tested on real hardware.
[1] Syzkaller report: usb 1-1: BOGUS urb xfer, pipe 1 != type 3 WARNING: CPU: 0 PID: 781 at drivers/usb/core/urb.c:504 usbsubmiturb+0xc4e/0x18c0 drivers/usb/core/urb.c:503 ... Call Trace: <TASK> usbstartwaiturb+0x113/0x520 drivers/usb/core/message.c:59 vmk80xxresetdevice drivers/comedi/drivers/vmk80xx.c:227 [inline] vmk80xxautoattach+0xa1c/0x1a40 drivers/comedi/drivers/vmk80xx.c:818 comediautoconfig+0x238/0x380 drivers/comedi/drivers.c:1067 usbprobeinterface+0x5cd/0xb00 drivers/usb/core/driver.c:399 ...
Similar issue also found by Syzkaller:
drm/amdkfd: Fix memory leak in createprocess failure
In the Linux kernel, the following vulnerability has been resolved:
netfilter: flowtable: incorrect pppoe tuple
pppoe traffic reaching ingress path does not match the flowtable entry because the pppoe header is expected to be at the network header offset. This bug causes a mismatch in the flow table lookup, so pppoe packets enter the classical forwarding path.
In the Linux kernel, the following vulnerability has been resolved:
clk: Get runtime PM before walking tree during disableunused
Doug reported [1] the following hung task:
INFO: task swapper/0:1 blocked for more than 122 seconds. Not tainted 5.15.149-21875-gf795ebc40eb8 #1 "echo 0 > /proc/sys/kernel/hungtasktimeoutsecs" disables this message. task:swapper/0 state:D stack: 0 pid: 1 ppid: 0 flags:0x00000008 Call trace: switchto+0xf4/0x1f4 schedule+0x418/0xb80 schedule+0x5c/0x10c rpmresume+0xe0/0x52c rpmresume+0x178/0x52c pmruntimeresume+0x58/0x98 clkpmruntimeget+0x30/0xb0 clkdisableunusedsubtree+0x58/0x208 clkdisableunusedsubtree+0x38/0x208 clkdisableunusedsubtree+0x38/0x208 clkdisableunusedsubtree+0x38/0x208 clkdisableunusedsubtree+0x38/0x208 clkdisableunused+0x4c/0xe4 dooneinitcall+0xcc/0x2d8 doinitcalllevel+0xa4/0x148 doinitcalls+0x5c/0x9c dobasicsetup+0x24/0x30 kernelinitfreeable+0xec/0x164 kernelinit+0x28/0x120 retfromfork+0x10/0x20 INFO: task kworker/u16:0:9 blocked for more than 122 seconds. Not tainted 5.15.149-21875-gf795ebc40eb8 #1 "echo 0 > /proc/sys/kernel/hungtasktimeoutsecs" disables this message. task:kworker/u16:0 state:D stack: 0 pid: 9 ppid: 2 flags:0x00000008 Workqueue: eventsunbound deferredprobeworkfunc Call trace: switchto+0xf4/0x1f4 schedule+0x418/0xb80 schedule+0x5c/0x10c schedulepreemptdisabled+0x2c/0x48 mutexlock+0x238/0x488 mutexlockslowpath+0x1c/0x28 mutexlock+0x50/0x74 clkpreparelock+0x7c/0x9c clkcorepreparelock+0x20/0x44 clkprepare+0x24/0x30 clkbulkprepare+0x40/0xb0 mdssruntimeresume+0x54/0x1c8 pmgenericruntimeresume+0x30/0x44 genpdruntimeresume+0x68/0x7c genpdruntimeresume+0x108/0x1f4 rpmcallback+0x84/0x144 rpmcallback+0x30/0x88 rpmresume+0x1f4/0x52c rpmresume+0x178/0x52c pmruntimeresume+0x58/0x98 deviceattach+0xe0/0x170 deviceinitialprobe+0x1c/0x28 busprobedevice+0x3c/0x9c deviceadd+0x644/0x814 mipidsideviceregisterfull+0xe4/0x170 devmmipidsideviceregisterfull+0x28/0x70 tisnbridgeprobe+0x1dc/0x2c0 auxiliarybusprobe+0x4c/0x94 reallyprobe+0xcc/0x2c8 driverprobedevice+0xa8/0x130 driverprobedevice+0x48/0x110 deviceattachdriver+0xa4/0xcc busforeachdrv+0x8c/0xd8 deviceattach+0xf8/0x170 deviceinitialprobe+0x1c/0x28 busprobedevice+0x3c/0x9c deferredprobeworkfunc+0x9c/0xd8 processonework+0x148/0x518 workerthread+0x138/0x350 kthread+0x138/0x1e0 retfromfork+0x10/0x20
The first thread is walking the clk tree and calling clkpmruntimeget() to power on devices required to read the clk hardware via struct clkops::isenabled(). This thread holds the clk preparelock, and is trying to runtime PM resume a device, when it finds that the device is in the process of resuming so the thread schedule()s away waiting for the device to finish resuming before continuing. The second thread is runtime PM resuming the same device, but the runtime resume callback is calling clkprepare(), trying to grab the preparelock waiting on the first thread.
This is a classic ABBA deadlock. To properly fix the deadlock, we must never runtime PM resume or suspend a device with the clk preparelock held. Actually doing that is near impossible today because the global preparelock would have to be dropped in the middle of the tree, the device runtime PM resumed/suspended, and then the preparelock grabbed again to ensure consistency of the clk tree topology. If anything changes with the clk tree in the meantime, we've lost and will need to start the operation all over again.
Luckily, most of the time we're simply incrementing or decrementing the runtime PM count on an active device, so we don't have the chance to schedule away with the preparelock held. Let's fix this immediate problem that can be ---truncated---
In the Linux kernel, the following vulnerability has been resolved:
mm/memory-failure: fix deadlock when hugetlboptimizevmemmap is enabled
The Linux kernel CVE team has assigned CVE-2024-26987 to this issue.
Upstream advisory: https://lore.kernel.org/linux-cve-announce/2024050143-CVE-2024-26987-507c@gregkh/T
In the Linux kernel, the following vulnerability has been resolved:
netfilter: nftables: restore set elements when delete set fails
From abort path, nftmapelemactivate() needs to restore refcounters to the original state. Currently, it uses the set->ops->walk() to iterate over these set elements. The existing set iterator skips inactive elements in the next generation, this does not work from the abort path to restore the original state since it has to skip active elements instead (not inactive ones).
This patch moves the check for inactive elements to the set iterator callback, then it reverses the logic for the .activate case which needs to skip active elements.
Toggle next generation bit for elements when delete set command is invoked and call nftclear() from .activate (abort) path to restore the next generation bit.
The splat below shows an object in mappings memleak:
[43929.457523] ------------[ cut here ]------------ [43929.457532] WARNING: CPU: 0 PID: 1139 at include/net/netfilter/nftables.h:1237 nftsetelemdatadeactivate+0xe4/0xf0 [nftables] [...] [43929.458014] RIP: 0010:nftsetelemdatadeactivate+0xe4/0xf0 [nftables] [43929.458076] Code: 83 f8 01 77 ab 49 8d 7c 24 08 e8 37 5e d0 de 49 8b 6c 24 08 48 8d 7d 50 e8 e9 5c d0 de 8b 45 50 8d 50 ff 89 55 50 85 c0 75 86 <0f> 0b eb 82 0f 0b eb b3 0f 1f 40 00 90 90 90 90 90 90 90 90 90 90 [43929.458081] RSP: 0018:ffff888140f9f4b0 EFLAGS: 00010246 [43929.458086] RAX: 0000000000000000 RBX: ffff8881434f5288 RCX: dffffc0000000000 [43929.458090] RDX: 00000000ffffffff RSI: ffffffffa26d28a7 RDI: ffff88810ecc9550 [43929.458093] RBP: ffff88810ecc9500 R08: 0000000000000001 R09: ffffed10281f3e8f [43929.458096] R10: 0000000000000003 R11: ffff0000ffff0000 R12: ffff8881434f52a0 [43929.458100] R13: ffff888140f9f5f4 R14: ffff888151c7a800 R15: 0000000000000002 [43929.458103] FS: 00007f0c687c4740(0000) GS:ffff888390800000(0000) knlGS:0000000000000000 [43929.458107] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [43929.458111] CR2: 00007f58dbe5b008 CR3: 0000000123602005 CR4: 00000000001706f0 [43929.458114] Call Trace: [43929.458118] <TASK> [43929.458121] ? warn+0x9f/0x1a0 [43929.458127] ? nftsetelemdatadeactivate+0xe4/0xf0 [nftables] [43929.458188] ? reportbug+0x1b1/0x1e0 [43929.458196] ? handlebug+0x3c/0x70 [43929.458200] ? excinvalidop+0x17/0x40 [43929.458211] ? nftsetelemdatadeactivate+0xd7/0xf0 [nftables] [43929.458271] ? nftsetelemdatadeactivate+0xe4/0xf0 [nftables] [43929.458332] nftmapelemdeactivate+0x24/0x30 [nftables] [43929.458392] nftrhashwalk+0xdd/0x180 [nftables] [43929.458453] ? pfxnftrhashwalk+0x10/0x10 [nftables] [43929.458512] ? rbinsertcolor+0x2e/0x280 [43929.458520] nftmapdeactivate+0xdc/0x1e0 [nftables] [43929.458582] ? pfxnftmapdeactivate+0x10/0x10 [nftables] [43929.458642] ? pfxnftmapelemdeactivate+0x10/0x10 [nftables] [43929.458701] ? rcureadunlock+0x46/0x70 [43929.458709] nftdelset+0xff/0x110 [nftables] [43929.458769] nftflushtable+0x16f/0x460 [nftables] [43929.458830] nftablesdeltable+0x501/0x580 [nftables]
In the Linux kernel, the following vulnerability has been resolved:
speakup: Avoid crash on very long word
In case a console is set up really large and contains a really long word (> 256 characters), we have to stop before the length of the word buffer.
In the Linux kernel, the following vulnerability has been resolved:
serial: mxs-auart: add spinlock around changing cts state
The uarthandlectschange() function in serialcore expects the caller to hold uport->lock. For example, I have seen the below kernel splat, when the Bluetooth driver is loaded on an i.MX28 board.
[ 85.119255] ------------[ cut here ]------------ [ 85.124413] WARNING: CPU: 0 PID: 27 at /drivers/tty/serial/serialcore.c:3453 uarthandlectschange+0xb4/0xec [ 85.134694] Modules linked in: hciuart bluetooth ecdhgeneric ecc wlcoresdio configfs [ 85.143314] CPU: 0 PID: 27 Comm: kworker/u3:0 Not tainted 6.6.3-00021-gd62a2f068f92 #1 [ 85.151396] Hardware name: Freescale MXS (Device Tree) [ 85.156679] Workqueue: hci0 hcipoweron [bluetooth] (...) [ 85.191765] uarthandlectschange from mxsauartirqhandle+0x380/0x3f4 [ 85.198787] mxsauartirqhandle from handleirqeventpercpu+0x88/0x210 (...)
In the Linux kernel, the following vulnerability has been resolved:
netfilter: brnetfilter: skip conntrack input hook for promisc packets
For historical reasons, when bridge device is in promisc mode, packets that are directed to the taps follow bridge input hook path. This patch adds a workaround to reset conntrack for these packets.
Jianbo Liu reports warning splats in their test infrastructure where cloned packets reach the brnetfilter input hook to confirm the conntrack object.
Scratch one bit from BRINPUTSKBCB to annotate that this packet has reached the input hook because it is passed up to the bridge device to reach the taps.
[ 57.571874] WARNING: CPU: 1 PID: 0 at net/bridge/brnetfilterhooks.c:616 brnflocalin+0x157/0x180 [brnetfilter] [ 57.572749] Modules linked in: xtMASQUERADE nfconntracknetlink nfnetlink iptablenat xtaddrtype xtconntrack nfnat brnetfilter rpcsecgsskrb5 authrpcgss oidregistry overlay rpcrdma rdmaucm ibiser libiscsi scsitransportisc si ibumad rdmacm ibipoib iwcm ibcm mlx5ib ibuverbs ibcore mlx5ctl mlx5core [ 57.575158] CPU: 1 PID: 0 Comm: swapper/1 Not tainted 6.8.0+ #19 [ 57.575700] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014 [ 57.576662] RIP: 0010:brnflocalin+0x157/0x180 [brnetfilter] [ 57.577195] Code: fe ff ff 41 bd 04 00 00 00 be 04 00 00 00 e9 4a ff ff ff be 04 00 00 00 48 89 ef e8 f3 a9 3c e1 66 83 ad b4 00 00 00 04 eb 91 <0f> 0b e9 f1 fe ff ff 0f 0b e9 df fe ff ff 48 89 df e8 b3 53 47 e1 [ 57.578722] RSP: 0018:ffff88885f845a08 EFLAGS: 00010202 [ 57.579207] RAX: 0000000000000002 RBX: ffff88812dfe8000 RCX: 0000000000000000 [ 57.579830] RDX: ffff88885f845a60 RSI: ffff8881022dc300 RDI: 0000000000000000 [ 57.580454] RBP: ffff88885f845a60 R08: 0000000000000001 R09: 0000000000000003 [ 57.581076] R10: 00000000ffff1300 R11: 0000000000000002 R12: 0000000000000000 [ 57.581695] R13: ffff8881047ffe00 R14: ffff888108dbee00 R15: ffff88814519b800 [ 57.582313] FS: 0000000000000000(0000) GS:ffff88885f840000(0000) knlGS:0000000000000000 [ 57.583040] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 57.583564] CR2: 000000c4206aa000 CR3: 0000000103847001 CR4: 0000000000370eb0 [ 57.584194] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [ 57.584820] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 [ 57.585440] Call Trace: [ 57.585721] <IRQ> [ 57.585976] ? warn+0x7d/0x130 [ 57.586323] ? brnflocalin+0x157/0x180 [brnetfilter] [ 57.586811] ? reportbug+0xf1/0x1c0 [ 57.587177] ? handlebug+0x3f/0x70 [ 57.587539] ? excinvalidop+0x13/0x60 [ 57.587929] ? asmexcinvalidop+0x16/0x20 [ 57.588336] ? brnflocalin+0x157/0x180 [brnetfilter] [ 57.588825] nfhookslow+0x3d/0xd0 [ 57.589188] ? brhandlevlan+0x4b/0x110 [ 57.589579] brpassframeup+0xfc/0x150 [ 57.589970] ? brportflagschange+0x40/0x40 [ 57.590396] brhandleframefinish+0x346/0x5e0 [ 57.590837] ? iptdotable+0x32e/0x430 [ 57.591221] ? brhandlelocalfinish+0x20/0x20 [ 57.591656] brnfhookthresh+0x4b/0xf0 [brnetfilter] [ 57.592286] ? brhandlelocalfinish+0x20/0x20 [ 57.592802] brnfpreroutingfinish+0x178/0x480 [brnetfilter] [ 57.593348] ? brhandlelocalfinish+0x20/0x20 [ 57.593782] ? nfnatipv4prerouting+0x25/0x60 [nfnat] [ 57.594279] brnfprerouting+0x24c/0x550 [brnetfilter] [ 57.594780] ? brnfhookthresh+0xf0/0xf0 [brnetfilter] [ 57.595280] brhandleframe+0x1f3/0x3d0 [ 57.595676] ? brhandlelocalfinish+0x20/0x20 [ 57.596118] ? brhandleframefinish+0x5e0/0x5e0 [ 57.596566] netifreceiveskbcore+0x25b/0xfc0 [ 57.597017] ? napibuildskb+0x37/0x40 [ 57.597418] netifreceiveskblistcore+0xfb/0x220
In the Linux kernel, the following vulnerability has been resolved:
netfilter: flowtable: validate pppoe header
Ensure there is sufficient room to access the protocol field of the PPPoe header. Validate it once before the flowtable lookup, then use a helper function to access protocol field.
In the Linux kernel, the following vulnerability has been resolved:
tun: limit printing rate when illegal packet received by tun dev
The Linux kernel CVE team has assigned CVE-2024-27013 to this issue.
Upstream advisory: https://lore.kernel.org/linux-cve-announce/2024050149-CVE-2024-27013-2c26@gregkh/T
In the Linux kernel, the following vulnerability has been resolved:
netfilter: nftsetpipapo: walk over current view on netlink dump
The generation mask can be updated while netlink dump is in progress. The pipapo set backend walk iterator cannot rely on it to infer what view of the datastructure is to be used. Add notation to specify if user wants to read/update the set.
Based on patch from Florian Westphal.
In the Linux kernel, the following vulnerability has been resolved:
netfilter: nftables: Fix potential data-race in nftobjtypeget()
nftunregisterobj() can concurrent with nftobjtypeget(), and there is not any protection when iterate over nftablesobjects list in nftobjtypeget(). Therefore, there is potential data-race of nftablesobjects list entry.
Use listforeachentryrcu() to iterate over nftablesobjects list in nftobjtypeget(), and use rcureadlock() in the caller nftobjtypeget() to protect the entire type query process.
In the Linux kernel, the following vulnerability has been resolved:
init/main.c: Fix potential staticcommandline memory overflow
The Linux kernel CVE team has assigned CVE-2024-26988 to this issue.
Upstream advisory: https://lore.kernel.org/linux-cve-announce/2024050143-CVE-2024-26988-c304@gregkh/T
In the Linux kernel, the following vulnerability has been resolved:
net/mlx5e: Prevent deadlock while disabling aRFS
The Linux kernel CVE team has assigned CVE-2024-27014 to this issue.
Upstream advisory: https://lore.kernel.org/linux-cve-announce/2024050149-CVE-2024-27014-d2dc@gregkh/T
In the Linux kernel, the following vulnerability has been resolved:
drm: nv04: Fix out of bounds access
The Linux kernel CVE team has assigned CVE-2024-27008 to this issue.
Upstream advisory: https://lore.kernel.org/linux-cve-announce/2024050148-CVE-2024-27008-5964@gregkh/T
In the Linux kernel, the following vulnerability has been resolved:
r8169: fix LED-related deadlock on module removal
Binding devmledclassdevregister() to the netdev is problematic because on module removal we get a RTNL-related deadlock. Fix this by avoiding the device-managed LED functions.
Note: We can safely call ledclassdevunregister() for a LED even if registering it failed, because ledclassdevunregister() detects this and is a no-op in this case.
Accounts. The issue was addressed with improved checks.
A heap-based buffer overflow vulnerability exists in the LookupTable::SetLUT functionality of Mathieu Malaterre Grassroot DICOM 3.0.23. A specially crafted malformed file can lead to memory corruption. An attacker can provide a malicious file to trigger this vulnerability.
An out-of-bounds write vulnerability exists in the JPEG2000Codec::DecodeByStreamsCommon functionality of Mathieu Malaterre Grassroot DICOM 3.0.23. A specially crafted DICOM file can lead to a heap buffer overflow. An attacker can provide a malicious file to trigger this vulnerability.
In the Linux kernel, the following vulnerability has been resolved:
drm/amdgpu: validate the parameters of bo mapping operations more clearly
The Linux kernel CVE team has assigned CVE-2024-26922 to this issue.
Upstream advisory: https://lore.kernel.org/linux-cve-announce/2024042317-CVE-2024-26922-896d@gregkh/T
Buffer Overflow vulenrability in Ffmpeg v.N113007-g8d24a28d06 allows a local attacker to execute arbitrary code via the libavcodec/jpegxlparser.c in genaliasmap.
Buffer Overflow vulnerability in Ffmpeg v.N113007-g8d24a28d06 allows a local attacker to execute arbitrary code via the libavfilter/avfshowspectrum.c:1789:52 component in showspectrumpicrequestframe
Buffer Overflow vulnerability in Ffmpeg v.N113007-g8d24a28d06 allows a local attacker to execute arbitrary code via a floating point exception (FPE) error at libavfilter/vfminterpolate.c:1078:60 in interpolate.
Buffer Overflow vulnerability in Ffmpeg v.N113007-g8d24a28d06 allows a local attacker to execute arbitrary code via the libavfilter/freverse.c:269:26 in areverserequestframe.
Buffer Overflow vulnerability in Ffmpeg v.N113007-g8d24a28d06 allows a local attacker to execute arbitrary code via the libavfilter/avfshowwaves.c:722:24 in showwavesfilterframe