| Commit message (Collapse) | Author |
|---|
|
This reverts commit 444876b4151429efeb64f91bbf5a5d7059484f8a.
|
|
bpf, arm64: use more scalable stadd over ldxr / stxr loop in xadd
bpf, arm64: remove prefetch insn in xadd mapping
bpf, arm64: use separate register for state in stxr
bpf, arm64: implement jiting of BPF_J{LT, LE, SLT, SLE}
bpf, arm64: implement jiting of BPF_XADD
bpf: add BPF_J{LT,LE,SLT,SLE} instructions
lib/test_bpf: Add tests for unsigned BPF_JGT
arm64: fix endianness annotation for 'struct jit_ctx' and friends
bpf: free up BPF_JMP | BPF_CALL | BPF_X opcode
bpf: remove stubs for cBPF from arch code
bpf: split HAVE_BPF_JIT into cBPF and eBPF variant
{nl,mac}80211: add rssi to mesh candidates
mac80211: mesh: drop new node with weak power
wifi: cfg80211: avoid leaking stack data into trace
UPSTREAM: netpoll: Fix device name check in netpoll_setup()
tracing: Avoid adding tracer option before update_tracer_options
sched_getaffinity: don't assume 'cpumask_size()' is fully initialized
thread_info: Remove superflous struct decls
USB: core: Prevent nested device-reset calls
USB: core: Don't hold device lock while reading the "descriptors" sysfs file
tty: fix deadlock caused by calling printk() under tty_port->lock
flow: fix object-size-mismatch warning in flowi{4,6}_to_flowi_common()
lsm,selinux: pass flowi_common instead of flowi to the LSM hooks
leds: leds-qpnp: Fix uninitialized local variable
qcacld-3.0: Avoid possible array OOB
ASoC: msm-pcm-q6-v2: Add dsp buf check
asoc: Update copy_to_user to requested buffer size
asoc: msm-pcm-q6-v2: Update memset for period size
asoc: Reset the buffer if size is partial or zero
msm: adsprpc: Handle UAF in fastrpc internal munmap
msm: adsprpc: Handle UAF in fastrpc debugfs read
msm: adsprpc: Add missing spin_lock in `fastrpc_debugfs_read`
msm: ADSPRPC: Protect global remote heap maps
msm: adsprpc: Avoid race condition during map creation and free
adsprpc: update mmap list nodes before mmap free
sched: deadline: Add missing WALT code
sched: Reinstantiate EAS check_for_migration() implementation
sched: Remove left-over CPU-query from __migrate_task
BACKPORT: net: ipv6: Fix processing of RAs in presence of VRF
wifi: cfg80211: Fix use after free for wext
cfg80211: allow connect keys only with default (TX) key
nl80211: Update bss channel on channel switch for P2P_CLIENT
ALSA: oss: Fix potential deadlock at unregistration
Revert "ALSA: rawmidi: Fix racy buffer resize under concurrent accesses"
ALSA: rawmidi: Drop register_mutex in snd_rawmidi_free()
ALSA: rawmidi: Avoid OOB access to runtime buffer
HID: check empty report_list in hid_validate_values()
HID: core: Provide new max_buffer_size attribute to over-ride the default
HID: core: fix shift-out-of-bounds in hid_report_raw_event
tty: use new tty_insert_flip_string_and_push_buffer() in pty_write()
tty: extract tty_flip_buffer_commit() from tty_flip_buffer_push()
tracing: Fix infinite loop in tracing_read_pipe on overflowed print_trace_line
tracing: Fix memleak due to race between current_tracer and trace
tracing: Ensure trace buffer is at least 4096 bytes large
tracing: Fix tp_printk option related with tp_printk_stop_on_boot
blktrace: Fix output non-blktrace event when blk_classic option enabled
msm: kgsl: Prevent wrap around during user address mapping
iommu: Fix missing return check of arm_lpae_init_pte
q6asm: validate payload size before access
dsp: afe: Add check for sidetone iir config copy size.
q6core: Avoid OOB access in q6core
q6voice: Add buf size check for cvs cal data.
ASoC: msm-pcm-host-voice: Handle OOB access in hpcm_start.
Asoc: check for invalid voice session id
kconfig: display recursive dependency resolution hint just once
wireguard: version: bump
compat: handle backported rng and blake2s
qemu: set panic_on_warn=1 from cmdline
qemu: use vports on arm
device: check for metadata_dst with skb_valid_dst()
qemu: enable ACPI for SMP
socket: ignore v6 endpoints when ipv6 is disabled
socket: free skb in send6 when ipv6 is disabled
queueing: use CFI-safe ptr_ring cleanup function
crypto: curve25519-x86_64: use in/out register constraints more precisely
compat: drop Ubuntu 14.04
fixup! compat: redefine version constants for sublevel>=256
wireguard: version: bump
Makefile: strip prefixed v from version.h
crypto: curve25519-x86_64: solve register constraints with reserved registers
compat: udp_tunnel: don't take reference to non-init namespace
compat: siphash: use _unaligned version by default
ratelimiter: use kvcalloc() instead of kvzalloc()
receive: drop handshakes if queue lock is contended
receive: use ring buffer for incoming handshakes
device: reset peer src endpoint when netns exits
main: rename 'mod_init' & 'mod_exit' functions to be module-specific
netns: actually test for routing loops
compat: update for RHEL 8.5
compat: account for grsecurity backports and changes
compat: account for latest c8s backports
|
|
Add condition check to make sure that the end address
of private entry does not go out of partition.
Change-Id: Ifb942c30ebeb8bccb891eebdcae4700b64b76920
Signed-off-by: Sarannya S <quic_sarannya@quicinc.com>
|
|
This reverts commit 71dc69707730a693c883a94f2d390299b49ea144.
Reason for revert: Few boundary checks are missing
Change-Id: Ib6783b43ad447fe5ebaed20a6e7908b96fb87fdf
Signed-off-by: Sarannya S <quic_sarannya@quicinc.com>
|
|
Bug: 221009551
Test: build, boot
Signed-off-by: Jimmy Hu <hhhuuu@google.com>
Change-Id: I82add2a6cb5e3060c930105b1b8b4f45da85f5f8
|
|
Fixes: 4b7e37cbcd65 ("usb: new attributes implementation to enable/disable usb data")
Bug: 194649527
Test: build, boot
Signed-off-by: Jimmy Hu <hhhuuu@google.com>
Change-Id: I63f58c3df620e91367b23b405fa0e9a577313964
Signed-off-by: Albert Wang <albertccwang@google.com>
|
|
Bug: 184613044
Test: driver probe and attributes access normally
Signed-off-by: Albert Wang <albertccwang@google.com>
Change-Id: Ia34cfd8e76a21f7239e356608e46ddeebd6fa10a
|
|
If iommu unmap fails and leaves dma or anon buffers still mapped in the
iommu, do not free them.
Change-Id: Ice0e1a59c1ac0ee7a9d62d8899966b84fa63d5ca
Signed-off-by: Lynus Vaz <quic_lvaz@quicinc.com>
|
|
Currently, clean up is not done properly for anonymous buffer
(KGSL_MEM_ENTRY_USER). Fix it by freeing up resources allocated
during memdesc_sg_virt.
Change-Id: I75bff2e718b494c102a8075a5f27323e1823b212
Signed-off-by: Kamal Agrawal <kamaagra@codeaurora.org>
|
|
|
|
Add condition check to make sure that the end address
of private entry does not go out of partition.
Change-Id: I88b3c69d86d90905b214c13a8c632b134b487a49
Signed-off-by: Sarannya S <quic_sarannya@quicinc.com>
Signed-off-by: Pranav Mahesh Phansalkar <quic_pphansal@quicinc.com>
(cherry picked from commit d3154be15b022817c95973d77d67411da3ea71ef)
|
|
* INPUT_PROP_NO_DUMMY_RELEASE definition in this kernel collides with
INPUT_PROP_ACCELEROMETER definition in bionic and upstream kernel. As
a result, Android recognizes normal input devices like accelerometers
and causes strange behaviors. There are no references to this bit in
userspace and it is not in 4.9+ kernels, so let's drop this CAF jank.
Change-Id: Id9b4ec8d31470e663f533249c4bc4b9e94fd38be
|
|
commit 9c6d778800b921bde3bff3cff5003d1650f942d1 upstream.
Automatic kernel fuzzing revealed a recursive locking violation in
usb-storage:
============================================
WARNING: possible recursive locking detected
5.18.0 #3 Not tainted
--------------------------------------------
kworker/1:3/1205 is trying to acquire lock:
ffff888018638db8 (&us_interface_key[i]){+.+.}-{3:3}, at:
usb_stor_pre_reset+0x35/0x40 drivers/usb/storage/usb.c:230
but task is already holding lock:
ffff888018638db8 (&us_interface_key[i]){+.+.}-{3:3}, at:
usb_stor_pre_reset+0x35/0x40 drivers/usb/storage/usb.c:230
...
stack backtrace:
CPU: 1 PID: 1205 Comm: kworker/1:3 Not tainted 5.18.0 #3
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS
1.13.0-1ubuntu1.1 04/01/2014
Workqueue: usb_hub_wq hub_event
Call Trace:
<TASK>
__dump_stack lib/dump_stack.c:88 [inline]
dump_stack_lvl+0xcd/0x134 lib/dump_stack.c:106
print_deadlock_bug kernel/locking/lockdep.c:2988 [inline]
check_deadlock kernel/locking/lockdep.c:3031 [inline]
validate_chain kernel/locking/lockdep.c:3816 [inline]
__lock_acquire.cold+0x152/0x3ca kernel/locking/lockdep.c:5053
lock_acquire kernel/locking/lockdep.c:5665 [inline]
lock_acquire+0x1ab/0x520 kernel/locking/lockdep.c:5630
__mutex_lock_common kernel/locking/mutex.c:603 [inline]
__mutex_lock+0x14f/0x1610 kernel/locking/mutex.c:747
usb_stor_pre_reset+0x35/0x40 drivers/usb/storage/usb.c:230
usb_reset_device+0x37d/0x9a0 drivers/usb/core/hub.c:6109
r871xu_dev_remove+0x21a/0x270 drivers/staging/rtl8712/usb_intf.c:622
usb_unbind_interface+0x1bd/0x890 drivers/usb/core/driver.c:458
device_remove drivers/base/dd.c:545 [inline]
device_remove+0x11f/0x170 drivers/base/dd.c:537
__device_release_driver drivers/base/dd.c:1222 [inline]
device_release_driver_internal+0x1a7/0x2f0 drivers/base/dd.c:1248
usb_driver_release_interface+0x102/0x180 drivers/usb/core/driver.c:627
usb_forced_unbind_intf+0x4d/0xa0 drivers/usb/core/driver.c:1118
usb_reset_device+0x39b/0x9a0 drivers/usb/core/hub.c:6114
This turned out not to be an error in usb-storage but rather a nested
device reset attempt. That is, as the rtl8712 driver was being
unbound from a composite device in preparation for an unrelated USB
reset (that driver does not have pre_reset or post_reset callbacks),
its ->remove routine called usb_reset_device() -- thus nesting one
reset call within another.
Performing a reset as part of disconnect processing is a questionable
practice at best. However, the bug report points out that the USB
core does not have any protection against nested resets. Adding a
reset_in_progress flag and testing it will prevent such errors in the
future.
Link: https://lore.kernel.org/all/CAB7eexKUpvX-JNiLzhXBDWgfg2T9e9_0Tw4HQ6keN==voRbP0g@mail.gmail.com/
Cc: stable@vger.kernel.org
Reported-and-tested-by: Rondreis <linhaoguo86@gmail.com>
Change-Id: I0812c3b2aec376fffddb3e03f3351f66ff76bcc6
Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Link: https://lore.kernel.org/r/YwkflDxvg0KWqyZK@rowland.harvard.edu
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
commit 45bf39f8df7f05efb83b302c65ae3b9bc92b7065 upstream.
Ever since commit 83e83ecb79a8 ("usb: core: get config and string
descriptors for unauthorized devices") was merged in 2013, there has
been no mechanism for reallocating the rawdescriptors buffers in
struct usb_device after the initial enumeration. Before that commit,
the buffers would be deallocated when a device was deauthorized and
reallocated when it was authorized and enumerated.
This means that the locking in the read_descriptors() routine is not
needed, since the buffers it reads will never be reallocated while the
routine is running. This locking can interfere with user programs
trying to read a hub's descriptors via sysfs while new child devices
of the hub are being initialized, since the hub is locked during this
procedure.
Since the locking in read_descriptors() hasn't been needed for over
nine years, we can remove it.
Reported-and-tested-by: Troels Liebe Bentsen <troels@connectedcars.dk>
Change-Id: Ib38603b37746e8e3e22e2b4fd3040278ee391feb
Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
CC: stable@vger.kernel.org
Link: https://lore.kernel.org/r/Y9l+wDTRbuZABzsE@rowland.harvard.edu
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Ulrich Hecht <uli+cip@fpond.eu>
AG: Squash with "USB: core: remove device lock left behind by mismerge"
|
|
[ Upstream commit 6b9dbedbe3499fef862c4dff5217cf91f34e43b3 ]
pty_write() invokes kmalloc() which may invoke a normal printk() to print
failure message. This can cause a deadlock in the scenario reported by
syz-bot below:
CPU0 CPU1 CPU2
---- ---- ----
lock(console_owner);
lock(&port_lock_key);
lock(&port->lock);
lock(&port_lock_key);
lock(&port->lock);
lock(console_owner);
As commit dbdda842fe96 ("printk: Add console owner and waiter logic to
load balance console writes") said, such deadlock can be prevented by
using printk_deferred() in kmalloc() (which is invoked in the section
guarded by the port->lock). But there are too many printk() on the
kmalloc() path, and kmalloc() can be called from anywhere, so changing
printk() to printk_deferred() is too complicated and inelegant.
Therefore, this patch chooses to specify __GFP_NOWARN to kmalloc(), so
that printk() will not be called, and this deadlock problem can be
avoided.
Syzbot reported the following lockdep error:
======================================================
WARNING: possible circular locking dependency detected
5.4.143-00237-g08ccc19a-dirty #10 Not tainted
------------------------------------------------------
syz-executor.4/29420 is trying to acquire lock:
ffffffff8aedb2a0 (console_owner){....}-{0:0}, at: console_trylock_spinning kernel/printk/printk.c:1752 [inline]
ffffffff8aedb2a0 (console_owner){....}-{0:0}, at: vprintk_emit+0x2ca/0x470 kernel/printk/printk.c:2023
but task is already holding lock:
ffff8880119c9158 (&port->lock){-.-.}-{2:2}, at: pty_write+0xf4/0x1f0 drivers/tty/pty.c:120
which lock already depends on the new lock.
the existing dependency chain (in reverse order) is:
-> #2 (&port->lock){-.-.}-{2:2}:
__raw_spin_lock_irqsave include/linux/spinlock_api_smp.h:110 [inline]
_raw_spin_lock_irqsave+0x35/0x50 kernel/locking/spinlock.c:159
tty_port_tty_get drivers/tty/tty_port.c:288 [inline] <-- lock(&port->lock);
tty_port_default_wakeup+0x1d/0xb0 drivers/tty/tty_port.c:47
serial8250_tx_chars+0x530/0xa80 drivers/tty/serial/8250/8250_port.c:1767
serial8250_handle_irq.part.0+0x31f/0x3d0 drivers/tty/serial/8250/8250_port.c:1854
serial8250_handle_irq drivers/tty/serial/8250/8250_port.c:1827 [inline] <-- lock(&port_lock_key);
serial8250_default_handle_irq+0xb2/0x220 drivers/tty/serial/8250/8250_port.c:1870
serial8250_interrupt+0xfd/0x200 drivers/tty/serial/8250/8250_core.c:126
__handle_irq_event_percpu+0x109/0xa50 kernel/irq/handle.c:156
[...]
-> #1 (&port_lock_key){-.-.}-{2:2}:
__raw_spin_lock_irqsave include/linux/spinlock_api_smp.h:110 [inline]
_raw_spin_lock_irqsave+0x35/0x50 kernel/locking/spinlock.c:159
serial8250_console_write+0x184/0xa40 drivers/tty/serial/8250/8250_port.c:3198
<-- lock(&port_lock_key);
call_console_drivers kernel/printk/printk.c:1819 [inline]
console_unlock+0x8cb/0xd00 kernel/printk/printk.c:2504
vprintk_emit+0x1b5/0x470 kernel/printk/printk.c:2024 <-- lock(console_owner);
vprintk_func+0x8d/0x250 kernel/printk/printk_safe.c:394
printk+0xba/0xed kernel/printk/printk.c:2084
register_console+0x8b3/0xc10 kernel/printk/printk.c:2829
univ8250_console_init+0x3a/0x46 drivers/tty/serial/8250/8250_core.c:681
console_init+0x49d/0x6d3 kernel/printk/printk.c:2915
start_kernel+0x5e9/0x879 init/main.c:713
secondary_startup_64+0xa4/0xb0 arch/x86/kernel/head_64.S:241
-> #0 (console_owner){....}-{0:0}:
[...]
lock_acquire+0x127/0x340 kernel/locking/lockdep.c:4734
console_trylock_spinning kernel/printk/printk.c:1773 [inline] <-- lock(console_owner);
vprintk_emit+0x307/0x470 kernel/printk/printk.c:2023
vprintk_func+0x8d/0x250 kernel/printk/printk_safe.c:394
printk+0xba/0xed kernel/printk/printk.c:2084
fail_dump lib/fault-inject.c:45 [inline]
should_fail+0x67b/0x7c0 lib/fault-inject.c:144
__should_failslab+0x152/0x1c0 mm/failslab.c:33
should_failslab+0x5/0x10 mm/slab_common.c:1224
slab_pre_alloc_hook mm/slab.h:468 [inline]
slab_alloc_node mm/slub.c:2723 [inline]
slab_alloc mm/slub.c:2807 [inline]
__kmalloc+0x72/0x300 mm/slub.c:3871
kmalloc include/linux/slab.h:582 [inline]
tty_buffer_alloc+0x23f/0x2a0 drivers/tty/tty_buffer.c:175
__tty_buffer_request_room+0x156/0x2a0 drivers/tty/tty_buffer.c:273
tty_insert_flip_string_fixed_flag+0x93/0x250 drivers/tty/tty_buffer.c:318
tty_insert_flip_string include/linux/tty_flip.h:37 [inline]
pty_write+0x126/0x1f0 drivers/tty/pty.c:122 <-- lock(&port->lock);
n_tty_write+0xa7a/0xfc0 drivers/tty/n_tty.c:2356
do_tty_write drivers/tty/tty_io.c:961 [inline]
tty_write+0x512/0x930 drivers/tty/tty_io.c:1045
__vfs_write+0x76/0x100 fs/read_write.c:494
[...]
other info that might help us debug this:
Chain exists of:
console_owner --> &port_lock_key --> &port->lock
Link: https://lkml.kernel.org/r/20220511061951.1114-2-zhengqi.arch@bytedance.com
Link: https://lkml.kernel.org/r/20220510113809.80626-2-zhengqi.arch@bytedance.com
Fixes: b6da31b2c07c ("tty: Fix data race in tty_insert_flip_string_fixed_flag")
Change-Id: I911074eddfab961a40cbdcbc2b4b0a4b04a70165
Signed-off-by: Qi Zheng <zhengqi.arch@bytedance.com>
Acked-by: Jiri Slaby <jirislaby@kernel.org>
Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Akinobu Mita <akinobu.mita@gmail.com>
Cc: Vlastimil Babka <vbabka@suse.cz>
Cc: Steven Rostedt (Google) <rostedt@goodmis.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
|
|
As pointed out by Herbert in a recent related patch, the LSM hooks do
not have the necessary address family information to use the flowi
struct safely. As none of the LSMs currently use any of the protocol
specific flowi information, replace the flowi pointers with pointers
to the address family independent flowi_common struct.
Reported-by: Herbert Xu <herbert@gondor.apana.org.au>
Acked-by: James Morris <jamorris@linux.microsoft.com>
Signed-off-by: Paul Moore <paul@paul-moore.com>
Change-Id: Ic0f16cf514773f473705d48c787527f910943f1a
|
|
rgb_blink_store searches through rgb_sync->led_data for a valid entry
and bails out if none was found, i.e. `!led`.
However that variable is not set to NULL before the loop and might point
to random memory.
Fix by setting it to NULL in the declaration.
Change-Id: Ideb16c47defc6a5fd466d96a2a854ad83acf3651
|
|
Add bound check before access array to avoid out of bound issue.
Separate array bound and duplicate check of 11a and 11b since they have
different length and type.
Change-Id: Icb9382cd42385339532518759de0f6137c5203bd
CRs-Fixed: 3051517
|
|
Added reference count for contex map indicate memory under used
in remote call. And, this memory would not removed in internal
unmap to avoid UAF.
Change-Id: Ieb4ff6b298ff9c48953bc5b3539fdfe19a14b442
Acked-by: DEEPAK SANNAPAREDDY <sdeeredd@qti.qualcomm.com>
Signed-off-by: Vamsi Krishna Gattupalli <quic_vgattupa@quicinc.com>
|
|
Use lock to protect maps among multiple
threads to avoid race condition.
Change-Id: I0c216d23316d41a91c2292ef7469e6ca06d771ea
Signed-off-by: Swathi K <quic_c_kataka@quicinc.com>
|
|
There is an unmatched `spin_unlock` at the bottom.
This `spin_lock` was forgotten in
4aef69f481108b6fa16458fa0a07d07be4d8e97f.
Change-Id: I2d283bb32002b993185e4927200606c384fab414
|
|
Protect global remote heap map by using spin locks, so that no
concurrent threads can corrupt the map list
Change-Id: I688b532988bebc4ac6c4ed80b5bd857968671450
Acked-by: Himateja Reddy <hmreddy@qti.qualcomm.com>
Signed-off-by: Tharun Kumar Merugu <mtharu@codeaurora.org>
|
|
Avoid race condition among concurrent fastrpc threads while
creating and removing memory mappings.
Change-Id: Ibf9ab0d4d19137804dbff4237a973895c410330c
Acked-by: Thyagarajan Venkatanarayanan <venkatan@qti.qualcomm.com>
Signed-off-by: Tharun Kumar Merugu <mtharu@codeaurora.org>
|
|
Update mmap list links before every mmap free.
Change-Id: Icb612a329e8defd65414842bae20f459c02364b9
Acked-by: Thyagarajan Venkatanarayanan <venkatan@qti.qualcomm.com>
Signed-off-by: Tharun Kumar Merugu <mtharu@codeaurora.org>
|
|
If sharedmem cannot be unmapped from the mmu, it can still be accessed
by the GPU. Therefore it is not safe to free the backing memory. In the
case that unmap fails, do not free it or return it to the system.
Change-Id: Iad3e86d043f129a4d71cf862865d9033d4a315e3
Signed-off-by: Lynus Vaz <quic_lvaz@quicinc.com>
Signed-off-by: Kaushal Sanadhya <quic_ksanadhy@quicinc.com>
|
|
[ Upstream commit b12fece4c64857e5fab4290bf01b2e0317a88456 ]
Add a check for empty report_list in hid_validate_values().
The missing check causes a type confusion when issuing a list_entry()
on an empty report_list.
The problem is caused by the assumption that the device must
have valid report_list. While this will be true for all normal HID
devices, a suitably malicious device can violate the assumption.
Fixes: 1b15d2e5b807 ("HID: core: fix validation of report id 0")
Change-Id: I990e3685de15a63e636a008dce7c450966c47cf8
Signed-off-by: Pietro Borrello <borrello@diag.uniroma1.it>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Signed-off-by: Ulrich Hecht <uli+cip@fpond.eu>
|
|
commit b1a37ed00d7908a991c1d0f18a8cba3c2aa99bdc upstream.
Presently, when a report is processed, its proposed size, provided by
the user of the API (as Report Size * Report Count) is compared against
the subsystem default HID_MAX_BUFFER_SIZE (16k). However, some
low-level HID drivers allocate a reduced amount of memory to their
buffers (e.g. UHID only allocates UHID_DATA_MAX (4k) buffers), rending
this check inadequate in some cases.
In these circumstances, if the received report ends up being smaller
than the proposed report size, the remainder of the buffer is zeroed.
That is, the space between sizeof(csize) (size of the current report)
and the rsize (size proposed i.e. Report Size * Report Count), which can
be handled up to HID_MAX_BUFFER_SIZE (16k). Meaning that memset()
shoots straight past the end of the buffer boundary and starts zeroing
out in-use values, often resulting in calamity.
This patch introduces a new variable into 'struct hid_ll_driver' where
individual low-level drivers can over-ride the default maximum value of
HID_MAX_BUFFER_SIZE (16k) with something more sympathetic to the
interface.
Change-Id: I851ac2340e107f57aded660540218c693e0e73f4
Signed-off-by: Lee Jones <lee@kernel.org>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
[Lee: Backported to v4.14.y]
Signed-off-by: Lee Jones <lee@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Ulrich Hecht <uli+cip@fpond.eu>
|
|
commit ec61b41918587be530398b0d1c9a0d16619397e5 upstream.
Syzbot reported shift-out-of-bounds in hid_report_raw_event.
microsoft 0003:045E:07DA.0001: hid_field_extract() 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>
__dump_stack lib/dump_stack.c:88 [inline]
dump_stack_lvl+0x1e3/0x2cb lib/dump_stack.c:106
ubsan_epilogue lib/ubsan.c:151 [inline]
__ubsan_handle_shift_out_of_bounds+0x3a6/0x420 lib/ubsan.c:322
snto32 drivers/hid/hid-core.c:1323 [inline]
hid_input_fetch_field drivers/hid/hid-core.c:1572 [inline]
hid_process_report drivers/hid/hid-core.c:1665 [inline]
hid_report_raw_event+0xd56/0x18b0 drivers/hid/hid-core.c:1998
hid_input_report+0x408/0x4f0 drivers/hid/hid-core.c:2066
hid_irq_in+0x459/0x690 drivers/hid/usbhid/hid-core.c:284
__usb_hcd_giveback_urb+0x369/0x530 drivers/usb/core/hcd.c:1671
dummy_timer+0x86b/0x3110 drivers/usb/gadget/udc/dummy_hcd.c:1988
call_timer_fn+0xf5/0x210 kernel/time/timer.c:1474
expire_timers kernel/time/timer.c:1519 [inline]
__run_timers+0x76a/0x980 kernel/time/timer.c:1790
run_timer_softirq+0x63/0xf0 kernel/time/timer.c:1803
__do_softirq+0x277/0x75b kernel/softirq.c:571
__irq_exit_rcu+0xec/0x170 kernel/softirq.c:650
irq_exit_rcu+0x5/0x20 kernel/softirq.c:662
sysvec_apic_timer_interrupt+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.
Reported-by: syzbot+8b1641d2f14732407e23@syzkaller.appspotmail.com
Fixes: dde5845a529f ("[PATCH] Generic HID layer - code split")
Change-Id: Ieffc79279df91b52fcfa087a043835f08e2c2af8
Signed-off-by: ZhangPeng <zhangpeng362@huawei.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Ulrich Hecht <uli+cip@fpond.eu>
|
|
commit a501ab75e7624d133a5a3c7ec010687c8b961d23 upstream.
There is a race in pty_write(). pty_write() can be called in parallel
with e.g. ioctl(TIOCSTI) or ioctl(TCXONC) which also inserts chars to
the buffer. Provided, tty_flip_buffer_push() in pty_write() is called
outside the lock, it can commit inconsistent tail. This can lead to out
of bounds writes and other issues. See the Link below.
To fix this, we have to introduce a new helper called
tty_insert_flip_string_and_push_buffer(). It does both
tty_insert_flip_string() and tty_flip_buffer_commit() under the port
lock. It also calls queue_work(), but outside the lock. See
71a174b39f10 (pty: do tty_flip_buffer_push without port->lock in
pty_write) for the reasons.
Keep the helper internal-only (in drivers' tty.h). It is not intended to
be used widely.
Link: https://seclists.org/oss-sec/2022/q2/155
Fixes: 71a174b39f10 (pty: do tty_flip_buffer_push without port->lock in pty_write)
Change-Id: I1f08439cc9047ee56df0681c3dfc5cd18f4b5a37
|
|
commit 716b10580283fda66f2b88140e3964f8a7f9da89 upstream.
We will need this new helper in the next patch.
Cc: Hillf Danton <hdanton@sina.com>
Cc: 一只狗 <chennbnbnb@gmail.com>
Cc: Dan Carpenter <dan.carpenter@oracle.com>
Change-Id: Iff30e1534948b64bf060c2b0ac290e541e4194b4
Signed-off-by: Jiri Slaby <jslaby@suse.cz>
Link: https://lore.kernel.org/r/20220707082558.9250-1-jslaby@suse.cz
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Alex: Adjust to changing tty_schedule_flip instead of tty_flip_buffer_push
|
|
When setting svm region during the gpuobj import ioctl call for a usermem
address, there is a possibility of a very large input size causing the
region's 64-bit end address to wrap around. This can cause the region
to incorrectly be considered valid, ultimately allowing a use after free
scenario. To prevent this, detect the occurrence of a wrap and reject the
import.
Change-Id: I4a88f56c58b830d4342e47dc1d1f6290c78ab6b4
Signed-off-by: Mohammed Mirza Mandayappurath Manzoor <quic_mmandaya@quicinc.com>
|
|
UAF scenario may occur in clients with EL1 privileges for
iova mappings when we miss to check the return value of
arm_lpae_init_pte which may lead to an PTE be counted as
it was set even if it was already existing. This can cause a
dangling IOMMU PTE to be left mapped pointing to a
freed object and cause UAF in the client if the dangling PTE
is accessed after a failed unmap operation.
Fixes: 27de1978c331 ("ANDROID: GKI: iommu/io-pgtable-arm: LPAE related updates by vendor")
Change-Id: I674b9b520e705b8f8e63ba20ed76e64cb2fe0f47
Signed-off-by: Pratyush Brahma <quic_pbrahma@quicinc.com>
(cherry picked from commit b1405fc833e94c7b69fd4a63ed204407284a58dc)
|
|
Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
Signed-off-by: Bruno Martins <bgcngm@gmail.com>
Change-Id: I41c7efda7df90f5920f4512c04bc57d23742f142
|
|
Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
Change-Id: I02feaa08c8e6194933bb1952fda70d8935fc8043
|
|
When we try to transmit an skb with md_dst attached through wireguard
we hit a null pointer dereference in wg_xmit() due to the use of
dst_mtu() which calls into dst_blackhole_mtu() which in turn tries to
dereference dst->dev.
Since wireguard doesn't use md_dsts we should use skb_valid_dst(), which
checks for DST_METADATA flag, and if it's set, then falls back to
wireguard's device mtu. That gives us the best chance of transmitting
the packet; otherwise if the blackhole netdev is used we'd get
ETH_MIN_MTU.
[ 263.693506] BUG: kernel NULL pointer dereference, address: 00000000000000e0
[ 263.693908] #PF: supervisor read access in kernel mode
[ 263.694174] #PF: error_code(0x0000) - not-present page
[ 263.694424] PGD 0 P4D 0
[ 263.694653] Oops: 0000 [#1] PREEMPT SMP NOPTI
[ 263.694876] CPU: 5 PID: 951 Comm: mausezahn Kdump: loaded Not tainted 5.18.0-rc1+ #522
[ 263.695190] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1.fc35 04/01/2014
[ 263.695529] RIP: 0010:dst_blackhole_mtu+0x17/0x20
[ 263.695770] Code: 00 00 00 0f 1f 44 00 00 c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 48 8b 47 10 48 83 e0 fc 8b 40 04 85 c0 75 09 48 8b 07 <8b> 80 e0 00 00 00 c3 66 90 0f 1f 44 00 00 48 89 d7 be 01 00 00 00
[ 263.696339] RSP: 0018:ffffa4a4422fbb28 EFLAGS: 00010246
[ 263.696600] RAX: 0000000000000000 RBX: ffff8ac9c3553000 RCX: 0000000000000000
[ 263.696891] RDX: 0000000000000401 RSI: 00000000fffffe01 RDI: ffffc4a43fb48900
[ 263.697178] RBP: ffffa4a4422fbb90 R08: ffffffff9622635e R09: 0000000000000002
[ 263.697469] R10: ffffffff9b69a6c0 R11: ffffa4a4422fbd0c R12: ffff8ac9d18b1a00
[ 263.697766] R13: ffff8ac9d0ce1840 R14: ffff8ac9d18b1a00 R15: ffff8ac9c3553000
[ 263.698054] FS: 00007f3704c337c0(0000) GS:ffff8acaebf40000(0000) knlGS:0000000000000000
[ 263.698470] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 263.698826] CR2: 00000000000000e0 CR3: 0000000117a5c000 CR4: 00000000000006e0
[ 263.699214] Call Trace:
[ 263.699505] <TASK>
[ 263.699759] wg_xmit+0x411/0x450
[ 263.700059] ? bpf_skb_set_tunnel_key+0x46/0x2d0
[ 263.700382] ? dev_queue_xmit_nit+0x31/0x2b0
[ 263.700719] dev_hard_start_xmit+0xd9/0x220
[ 263.701047] __dev_queue_xmit+0x8b9/0xd30
[ 263.701344] __bpf_redirect+0x1a4/0x380
[ 263.701664] __dev_queue_xmit+0x83b/0xd30
[ 263.701961] ? packet_parse_headers+0xb4/0xf0
[ 263.702275] packet_sendmsg+0x9a8/0x16a0
[ 263.702596] ? _raw_spin_unlock_irqrestore+0x23/0x40
[ 263.702933] sock_sendmsg+0x5e/0x60
[ 263.703239] __sys_sendto+0xf0/0x160
[ 263.703549] __x64_sys_sendto+0x20/0x30
[ 263.703853] do_syscall_64+0x3b/0x90
[ 263.704162] entry_SYSCALL_64_after_hwframe+0x44/0xae
[ 263.704494] RIP: 0033:0x7f3704d50506
[ 263.704789] Code: 48 c7 c0 ff ff ff ff eb b7 66 2e 0f 1f 84 00 00 00 00 00 90 41 89 ca 64 8b 04 25 18 00 00 00 85 c0 75 11 b8 2c 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 72 c3 90 55 48 83 ec 30 44 89 4c 24 2c 4c 89
[ 263.705652] RSP: 002b:00007ffe954b0b88 EFLAGS: 00000246 ORIG_RAX: 000000000000002c
[ 263.706141] RAX: ffffffffffffffda RBX: 0000558bb259b490 RCX: 00007f3704d50506
[ 263.706544] RDX: 000000000000004a RSI: 0000558bb259b7b2 RDI: 0000000000000003
[ 263.706952] RBP: 0000000000000000 R08: 00007ffe954b0b90 R09: 0000000000000014
[ 263.707339] R10: 0000000000000000 R11: 0000000000000246 R12: 00007ffe954b0b90
[ 263.707735] R13: 000000000000004a R14: 0000558bb259b7b2 R15: 0000000000000001
[ 263.708132] </TASK>
[ 263.708398] Modules linked in: bridge netconsole bonding [last unloaded: bridge]
[ 263.708942] CR2: 00000000000000e0
Link: https://github.com/cilium/cilium/issues/19428
Reported-by: Martynas Pumputis <m@lambda.lt>
Signed-off-by: Nikolay Aleksandrov <razor@blackwall.org>
Acked-by: Daniel Borkmann <daniel@iogearbox.net>
[Jason: polyfilled for < 4.3]
Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
Change-Id: I3683705bd6e968609d18c9bbcab835e2460ea438
|
|
The previous commit fixed a memory leak on the send path in the event
that IPv6 is disabled at compile time, but how did a packet even arrive
there to begin with? It turns out we have previously allowed IPv6
endpoints even when IPv6 support is disabled at compile time. This is
awkward and inconsistent. Instead, let's just ignore all things IPv6,
the same way we do other malformed endpoints, in the case where IPv6 is
disabled.
Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
Change-Id: I7def019000309c6d1f9aef695f1d4f63460e59dd
|
|
I got a memory leak report:
unreferenced object 0xffff8881191fc040 (size 232):
comm "kworker/u17:0", pid 23193, jiffies 4295238848 (age 3464.870s)
hex dump (first 32 bytes):
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
backtrace:
[<ffffffff814c3ef4>] slab_post_alloc_hook+0x84/0x3b0
[<ffffffff814c8977>] kmem_cache_alloc_node+0x167/0x340
[<ffffffff832974fb>] __alloc_skb+0x1db/0x200
[<ffffffff82612b5d>] wg_socket_send_buffer_to_peer+0x3d/0xc0
[<ffffffff8260e94a>] wg_packet_send_handshake_initiation+0xfa/0x110
[<ffffffff8260ec81>] wg_packet_handshake_send_worker+0x21/0x30
[<ffffffff8119c558>] process_one_work+0x2e8/0x770
[<ffffffff8119ca2a>] worker_thread+0x4a/0x4b0
[<ffffffff811a88e0>] kthread+0x120/0x160
[<ffffffff8100242f>] ret_from_fork+0x1f/0x30
In function wg_socket_send_buffer_as_reply_to_skb() or wg_socket_send_
buffer_to_peer(), the semantics of send6() is required to free skb. But
when CONFIG_IPV6 is disable, kfree_skb() is missing. This patch adds it
to fix this bug.
Signed-off-by: Wang Hai <wanghai38@huawei.com>
Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
Change-Id: I48a684a0e1eebab6d803dca32684c53de99373be
|
|
We make too nuanced use of ptr_ring to entirely move to the skb_array
wrappers, but we at least should avoid the naughty function pointer cast
when cleaning up skbs. Otherwise RAP/CFI will honk at us. This patch
uses the __skb_array_destroy_skb wrapper for the cleanup, rather than
directly providing kfree_skb, which is what other drivers in the same
situation do too.
Reported-by: PaX Team <pageexec@freemail.hu>
Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
Change-Id: Ib9ee487345484769aab6b173738c77dcac0f6f57
|
|
Rather than passing all variables as modified, pass ones that are only
read into that parameter. This helps with old gcc versions when
alternatives are additionally used, and lets gcc's codegen be a little
bit more efficient. This also syncs up with the latest Vale/EverCrypt
output.
This also forward ports 3c9f3b6 ("crypto: curve25519-x86_64: solve
register constraints with reserved registers").
Cc: Aymeric Fromherz <aymeric.fromherz@inria.fr>
Cc: Mathias Krause <minipli@grsecurity.net>
Link: https://lore.kernel.org/wireguard/1554725710.1290070.1639240504281.JavaMail.zimbra@inria.fr/
Link: https://github.com/project-everest/hacl-star/pull/501
Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
Change-Id: Idc46e469140c53e1bbe436894c7750e8dcfbec47
|
|
It's been over a year since we announced sunsetting this.
Link: https://lore.kernel.org/wireguard/CAHmME9rckipsdZYW+LA=x6wCMybdFFA+VqoogFXnR=kHYiCteg@mail.gmail.com/T
Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
Change-Id: I362f83af6dc910819c96f81a9f45849ff48fbcbb
|
|
With the 4.4.256 and 4.9.256 kernels, the previous calculation for
integer comparison overflowed. This commit redefines the broken
constants to have more space for the sublevel.
Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
Signed-off-by: Bruno Martins <bgcngm@gmail.com>
Change-Id: I10023e96476c7f498e7f2fc8d29813ecc7c3b765
|
|
Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
Signed-off-by: Bruno Martins <bgcngm@gmail.com>
Change-Id: Icde0786c87bf7bbabc733fcf2f047e1a63e47808
|
|
We also no longer do anything dynamic with dkms.conf, and we don't
rewrite any files at all, but rather pass this through as a cflag to the
compiler optionally.
Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
Reported-by: Egbert Verhage <egbert@eggiecode.org>
Change-Id: Ieffe702464a3caeedcf6e9552da9dc339147cad2
|
|
The register constraints for the inline assembly in fsqr() and fsqr2()
are pretty tight on what the compiler may assign to the remaining three
register variables. The clobber list only allows the following to be
used: RDI, RSI, RBP and R12. With RAP reserving R12 and a kernel having
CONFIG_FRAME_POINTER=y, claiming RBP, there are only two registers left
so the compiler rightfully complains about impossible constraints.
Provide alternatives that'll allow a memory reference for 'out' to solve
the allocation constraint dilemma for this configuration.
Also make 'out' an input-only operand as it is only used as such. This
not only allows gcc to optimize its usage further, but also works around
older gcc versions, apparently failing to handle multiple alternatives
correctly, as in failing to initialize the 'out' operand with its input
value.
Signed-off-by: Mathias Krause <minipli@grsecurity.net>
Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
Change-Id: I7027868359c31d4e514118a2f79b4726e259ddb0
|
|
The comment to sk_change_net is instructive:
Kernel sockets, f.e. rtnl or icmp_socket, are a part of a namespace.
They should not hold a reference to a namespace in order to allow
to stop it.
Sockets after sk_change_net should be released using sk_release_kernel
We weren't following these rules before, and were instead using
__sock_create, which means we kept a reference to the namespace, which
in turn meant that interfaces were not cleaned up on namespace
exit.
Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
Change-Id: I03b2e58e45e3eb37c6324b23ca0d6f3fde2ebec7
|
|
On ARM v6 and later, we define CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS
because the ordinary load/store instructions (ldr, ldrh, ldrb) can
tolerate any misalignment of the memory address. However, load/store
double and load/store multiple instructions (ldrd, ldm) may still only
be used on memory addresses that are 32-bit aligned, and so we have to
use the CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS macro with care, or we
may end up with a severe performance hit due to alignment traps that
require fixups by the kernel. Testing shows that this currently happens
with clang-13 but not gcc-11. In theory, any compiler version can
produce this bug or other problems, as we are dealing with undefined
behavior in C99 even on architectures that support this in hardware,
see also https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100363.
Fortunately, the get_unaligned() accessors do the right thing: when
building for ARMv6 or later, the compiler will emit unaligned accesses
using the ordinary load/store instructions (but avoid the ones that
require 32-bit alignment). When building for older ARM, those accessors
will emit the appropriate sequence of ldrb/mov/orr instructions. And on
architectures that can truly tolerate any kind of misalignment, the
get_unaligned() accessors resolve to the leXX_to_cpup accessors that
operate on aligned addresses.
Since the compiler will in fact emit ldrd or ldm instructions when
building this code for ARM v6 or later, the solution is to use the
unaligned accessors unconditionally on architectures where this is
known to be fast. The _aligned version of the hash function is
however still needed to get the best performance on architectures
that cannot do any unaligned access in hardware.
This new version avoids the undefined behavior and should produce
the fastest hash on all architectures we support.
Reported-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Reviewed-by: Jason A. Donenfeld <Jason@zx2c4.com>
Acked-by: Ard Biesheuvel <ardb@kernel.org>
Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
Change-Id: Ifd9995cd389b5c6600b9569a3eee0bd0167f91b0
|
|
Use 2-factor argument form kvcalloc() instead of kvzalloc().
Signed-off-by: Gustavo A. R. Silva <gustavoars@kernel.org>
Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
Change-Id: Ib525508a66c48d47c17c9a8b11ff40d79ae0b853
|
|
If we're being delivered packets from multiple CPUs so quickly that the
ring lock is contended for CPU tries, then it's safe to assume that the
queue is near capacity anyway, so just drop the packet rather than
spinning. This helps deal with multicore DoS that can interfere with
data path performance. It _still_ does not completely fix the issue, but
it again chips away at it.
Reported-by: Streun Fabio <fstreun@student.ethz.ch>
Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
Change-Id: I6e0a372a0b26907cc4ac425ecc17bdca8e07a2aa
|
|
Apparently the spinlock on incoming_handshake's skb_queue is highly
contended, and a torrent of handshake or cookie packets can bring the
data plane to its knees, simply by virtue of enqueueing the handshake
packets to be processed asynchronously. So, we try switching this to a
ring buffer to hopefully have less lock contention. This alleviates the
problem somewhat, though it still isn't perfect, so future patches will
have to improve this further. However, it at least doesn't completely
diminish the data plane.
Reported-by: Streun Fabio <fstreun@student.ethz.ch>
Reported-by: Joel Wanner <joel.wanner@inf.ethz.ch>
Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
Change-Id: I6e515a2092f55c8dd9cd4962300c7d01fa23cd60
|
|
Each peer's endpoint contains a dst_cache entry that takes a reference
to another netdev. When the containing namespace exits, we take down the
socket and prevent future sockets from being created (by setting
creating_net to NULL), which removes that potential reference on the
netns. However, it doesn't release references to the netns that a netdev
cached in dst_cache might be taking, so the netns still might fail to
exit. Since the socket is gimped anyway, we can simply clear all the
dst_caches (by way of clearing the endpoint src), which will release all
references.
However, the current dst_cache_reset function only releases those
references lazily. But it turns out that all of our usages of
wg_socket_clear_peer_endpoint_src are called from contexts that are not
exactly high-speed or bottle-necked. For example, when there's
connection difficulty, or when userspace is reconfiguring the interface.
And in particular for this patch, when the netns is exiting. So for
those cases, it makes more sense to call dst_release immediately. For
that, we add a small helper function to dst_cache.
This patch also adds a test to netns.sh from Hangbin Liu to ensure this
doesn't regress.
Test-by: Hangbin Liu <liuhangbin@gmail.com>
Reported-by: Xiumei Mu <xmu@redhat.com>
Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
Change-Id: Ie3c2d3ffbf27c94bdfd3bc37e314d14c306c217a
|
