Command injection via array-ish $command parameter of procopen()
Accounts. The issue was addressed with improved checks.
Accounts. The issue was addressed with improved checks.
Impact
If an attacker can alter the integrity option passed to fetch(), they can let fetch() accept requests as valid even if they have been tampered.
Patches
Fixed in https://github.com/nodejs/undici/commit/d542b8cd39ec1ba303f038ea26098c3f355974f3. Fixes has been released in v5.28.4 and v6.11.1.
Workarounds
Ensure that integrity cannot be tampered with.
References
https://hackerone.com/reports/2377760
An issue was discovered in Mbed TLS 2.18.0 through 2.28.x before 2.28.8 and 3.x before 3.6.0 and Mbed Crypto. The PSA Crypto API mishandles shared memory.
Impact
Undici cleared Authorization and Proxy-Authorization headers for fetch(), but did not clear them for undici.request().
Patches
This has been patched in https://github.com/nodejs/undici/commit/6805746680d27a5369d7fb67bc05f95a28247d75. Fixes has been released in v5.28.4 and v6.11.1.
Workarounds
use fetch() or disable maxRedirections.
References
Linzi Shang reported this.
https://hackerone.com/reports/2408074 https://github.com/nodejs/undici/security/advisories/GHSA-3787-6prv-h9w3
Last updated 24 July 2024
Last updated 24 July 2024
Accounts. The issue was addressed with improved checks.
Versions of the package sanitize-html before 2.12.1 are vulnerable to Information Exposure when used on the backend and with the style attribute allowed, allowing enumeration of files in the system (including project dependencies). An attacker could exploit this vulnerability to gather details about the file system structure and dependencies of the targeted server.
Impact An attacker could send a JWE containing compressed data that used large amounts of memory and CPU when decompressed by Decrypt or DecryptMulti. Those functions now return an error if the decompressed data would exceed 250kB or 10x the compressed size (whichever is larger). Thanks to Enze Wang@Alioth and Jianjun Chen@Zhongguancun Lab (@zer0yu and @chenjj) for reporting.
Patches The problem is fixed in the following packages and versions: - github.com/go-jose/go-jose/v4 version 4.0.1 - github.com/go-jose/go-jose/v3 version 3.0.3 - gopkg.in/go-jose/go-jose.v2 version 2.6.3
The problem will not be fixed in the following package because the package is archived: - gopkg.in/square/go-jose.v2
Accounts. The issue was addressed with improved checks.
Accounts. The issue was addressed with improved checks.
Jinja is an extensible templating engine. The xmlattr filter in affected versions of Jinja accepts keys containing non-attribute characters. XML/HTML attributes cannot contain spaces, /, >, or =, as each would then be interpreted as starting a separate attribute. If an application accepts keys (as opposed to only values) as user input, and renders these in pages that other users see as well, an attacker could use this to inject other attributes and perform XSS. The fix for CVE-2024-22195 only addressed spaces but not other characters. Accepting keys as user input is now explicitly considered an unintended use case of the xmlattr filter, and code that does so without otherwise validating the input should be flagged as insecure, regardless of Jinja version. Accepting values as user input continues to be safe. This vulnerability is fixed in 3.1.4.
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.
An issue was discovered in GNOME GLib before 2.78.5, and 2.79.x and 2.80.x before 2.80.1. When a GDBus-based client subscribes to signals from a trusted system service such as NetworkManager on a shared computer, other users of the same computer can send spoofed D-Bus signals that the GDBus-based client will wrongly interpret as having been sent by the trusted system service. This could lead to the GDBus-based client behaving incorrectly, with an application-dependent impact.
In the Linux kernel, the following vulnerability has been resolved:
btrfs: make sure that WRITTEN is set on all metadata blocks
We previously would call btrfscheckleaf() if we had the check integrity code enabled, which meant that we could only run the extended leaf checks if we had WRITTEN set on the header flags.
This leaves a gap in our checking, because we could end up with corruption on disk where WRITTEN isn't set on the leaf, and then the extended leaf checks don't get run which we rely on to validate all of the item pointers to make sure we don't access memory outside of the extent buffer.
However, since 732fab95abe2 ("btrfs: check-integrity: remove CONFIGBTRFSFSCHECKINTEGRITY option") we no longer call btrfscheckleaf() from btrfsmarkbufferdirty(), which means we only ever call it on blocks that are being written out, and thus have WRITTEN set, or that are being read in, which should have WRITTEN set.
Add checks to make sure we have WRITTEN set appropriately, and then make sure btrfscheckleaf() always does the item checking. This will protect us from file systems that have been corrupted and no longer have WRITTEN set on some of the blocks.
This was hit on a crafted image tweaking the WRITTEN bit and reported by KASAN as out-of-bound access in the eb accessors. The example is a dir item at the end of an eb.
[2.042] BTRFS warning (device loop1): bad eb member start: ptr 0x3fff start 30572544 member offset 16410 size 2 [2.040] general protection fault, probably for non-canonical address 0xe0009d1000000003: 0000 [#1] PREEMPT SMP KASAN NOPTI [2.537] KASAN: maybe wild-memory-access in range [0x0005088000000018-0x000508800000001f] [2.729] CPU: 0 PID: 2587 Comm: mount Not tainted 6.8.2 #1 [2.729] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014 [2.621] RIP: 0010:btrfsget16+0x34b/0x6d0 [2.621] RSP: 0018:ffff88810871fab8 EFLAGS: 00000206 [2.621] RAX: 0000a11000000003 RBX: ffff888104ff8720 RCX: ffff88811b2288c0 [2.621] RDX: dffffc0000000000 RSI: ffffffff81dd8aca RDI: ffff88810871f748 [2.621] RBP: 000000000000401a R08: 0000000000000001 R09: ffffed10210e3ee9 [2.621] R10: ffff88810871f74f R11: 205d323430333737 R12: 000000000000001a [2.621] R13: 000508800000001a R14: 1ffff110210e3f5d R15: ffffffff850011e8 [2.621] FS: 00007f56ea275840(0000) GS:ffff88811b200000(0000) knlGS:0000000000000000 [2.621] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [2.621] CR2: 00007febd13b75c0 CR3: 000000010bb50000 CR4: 00000000000006f0 [2.621] Call Trace: [2.621] <TASK> [2.621] ? showregs+0x74/0x80 [2.621] ? dieaddr+0x46/0xc0 [2.621] ? excgeneralprotection+0x161/0x2a0 [2.621] ? asmexcgeneralprotection+0x26/0x30 [2.621] ? btrfsget16+0x33a/0x6d0 [2.621] ? btrfsget16+0x34b/0x6d0 [2.621] ? btrfsget16+0x33a/0x6d0 [2.621] ? pfxbtrfsget16+0x10/0x10 [2.621] ? pfxmutexunlock+0x10/0x10 [2.621] btrfsmatchdiritemname+0x101/0x1a0 [2.621] btrfslookupdiritem+0x1f3/0x280 [2.621] ? pfxbtrfslookupdiritem+0x10/0x10 [2.621] btrfsgettree+0xd25/0x1910
[ copy more details from report ]
In the Linux kernel, the following vulnerability has been resolved:
firewire: nosy: ensure userlength is taken into account when fetching packet contents
Ensure that packetbufferget respects the userlength provided. If the length of the head packet exceeds the userlength, packetbufferget will now return 0 to signify to the user that no data were read and a larger buffer size is required. Helps prevent user space overflows.
In the Linux kernel, the following vulnerability has been resolved:
drm/amdgpu: once more fix the call oder in amdgputtmmove() v2
This reverts drm/amdgpu: fix ftrace event amdgpubomove always move on same heap. The basic problem here is that after the move the old location is simply not available any more.
Some fixes were suggested, but essentially we should call the move notification before actually moving things because only this way we have the correct order for DMA-buf and VM move notifications as well.
Also rework the statistic handling so that we don't update the eviction counter before the move.
v2: add missing NULL check
In the Linux kernel, the following vulnerability has been resolved:
Bluetooth: Fix use-after-free bugs caused by scosocktimeout
The Linux kernel CVE team has assigned CVE-2024-27398 to this issue.
Upstream advisory: https://lore.kernel.org/linux-cve-announce/2024051355-CVE-2024-27398-08ef@gregkh/T
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:
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: 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: 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:
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:
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
An attacker can prepare a local repository in such a way that, when cloned, will execute arbitrary code during the operation.
Cloning local Git repository by untrusted user allows the untrusted user to modify objects in the cloned repository at will
Git is a revision control system. Prior to versions 2.45.1, 2.44.1, 2.43.4, 2.42.2, 2.41.1, 2.40.2, and 2.39.4, when cloning a local source repository that contains symlinks via the filesystem, Git may create hardlinks to arbitrary user-readable files on the same filesystem as the target repository in the objects/ directory. Cloning a local repository over the filesystem may creating hardlinks to arbitrary user-owned files on the same filesystem in the target Git repository's objects/ directory. When cloning a repository over the filesystem (without explicitly specifying the file:// protocol or --no-local), the optimizations for local cloning will be used, which include attempting to hard link the object files instead of copying them. While the code includes checks against symbolic links in the source repository, which were added during the fix for CVE-2022-39253, these checks can still be raced because the hard link operation ultimately follows symlinks. If the object on the filesystem appears as a file during the check, and then a symlink during the operation, this will allow the adversary to bypass the check and create hardlinks in the destination objects directory to arbitrary, user-readable files. The problem has been patched in versions 2.45.1, 2.44.1, 2.43.4, 2.42.2, 2.41.1, 2.40.2, and 2.39.4.