ASoC: SOF: Fix buffer copy size error in ext bytes get and add checks #125

singalsu · 2018-09-11T12:46:13Z

This patch replaces the copy_to_user() size with the value that was
passed to the function minus the user data header length. It prevents
to exceed the user space buffer. The size originates from topology. The
compare to topology specified length is also added to ext bytes put.

The other changes add debug prints to kernel log to see the actual size
limits.

Signed-off-by: Seppo Ingalsuo seppo.ingalsuo@linux.intel.com

ranj063 · 2018-09-11T21:30:07Z

sound/soc/sof/control.c

+	/* Limit size to prevent read of kernel data */
+	if (size > max_length) {
+		size = max_length;
+		dev_dbg(sdev->dev, "warning: the copy length was limited\n");


@singalsu Should this be an error? Does it make sense to copy partial data?

The size of copy originates from topology. I agree this should be better to be an error. There's need to fix topology if this happens.

ranj063 · 2018-09-11T21:30:48Z

sound/soc/sof/control.c

+		size = max_length;
+		dev_dbg(sdev->dev, "warning: the copy length was limited\n");
+	}
+
 	dev_dbg(sdev->dev, "getting data and command is %d\n", scontrol->cmd);


can we please remove this line? this was added for debug purposes when working on the demo.

ranj063 · 2018-09-12T01:10:07Z

sound/soc/sof/control.c

-	if (copy_to_user(binary_data + 2, cdata->data->data,
-			 SOF_IPC_MSG_MAX_SIZE - sizeof(struct sof_ipc_ctrl_data)))
+
+	if (copy_to_user(binary_data + 2, cdata->data->data, size))


@singalsu should this be "size" bytes or max_length bytes or the size sent by the FW?

The design problem with ASoC get is that the size should originate from firmware or at least have possibility to return the actual bytes read. Now the request is for the topology specified length but since it varies the request is always the max length. I used as example for this fix the similar ext bytes get function for Skylake.

But it should be acceptable for the user space to get a max length response and then use the uapi headers to get the relevant data. In EQ case the first uint32_t word after the user copy header is the length to use.

So, I'd keep this as is in the patch.

singalsu · 2018-09-12T10:33:32Z

@ranj063 I've updated the PR now (addressed 2 of 3). If you test this you will need to apply also PR #121. Without that the bytes get fails to work due to no data at DSP.

ranj063 · 2018-09-12T13:48:37Z

sound/soc/sof/control.c

+	if (err < 0)
+		dev_err(sdev->dev, "error: failed to idle %d\n", err);
+
+	return ret;


@singalsu I see why you have err and ret, but its confusing to see err just above and return "ret" instead. I think we should just use one and return the latest return value from the runtime_put. What do you think?

That's a good question. I need to find out if err means that the operation has failed with incorrect data or is this just something to note into debug trace. Failing with idle doesn't sound like the ext bytes get has failed. I never saw this to happen in my tests though.

There's also the return value from the IPC command that is not stored & checked. That might be the most relevant for return code.

@singalsu I think we should skip checking the return value for runtime_put if we arent going to use the value at all.
It is more important to check the return value for runtime_get_sync.

lgirdwood · 2018-09-13T07:48:11Z

sound/soc/sof/control.c

@@ -302,10 +302,13 @@ int snd_sof_bytes_ext_put(struct snd_kcontrol *kcontrol,
 		return -EFAULT;

 	length = header[1];
-	dev_dbg(sdev->dev, "size of bytes put data is %d\n", length);
+	if (max_length > be->max)


We probably want a dev_warn() here stating that userspace is sending too much data and it has been truncated

lgirdwood · 2018-09-13T07:49:23Z

sound/soc/sof/control.c

+	 * the limit from ext bytes size from topology and SOF IPC
+	 * size limit.
+	 */
+	size -= 2 * sizeof(u32);


what is 2 * sizeof int32_t ?

@lgirdwood when sending the bytes from the userspace, the first 2 u32's are actually not part of the actual data to be sent to the firmware. Instead the first uint is a tag and the second is the size of bytes being sent. So we subtract those from the size to be passed to the firmware.
@singalsu can we please update the comment to reflect it and maybe define a macro like BYTE_CTL_HEADER_SIZE instead of 2?

Lets find the C structure that defines this ABI and subtract it's sizeof otherwise this code will break with any ABI update or on another architecture.

Yep, I'll search for struct.

I followed the example in sound/soc/intel/skylake/skl-topology.c function skl_tplg_tlv_control_get(). I'm wondering why the size need to be decremented. It prevents getting the max topology defined length of ext bytes data.

I searched in ASoC more examples and found one.

Function wm_coeff_tlv_get() in wm_adsp.c does not place the tag & size into header and does not decrement the size.

That way there would be no need for header struct knowledge but I haven't tested yet if that would work.

@ranj063 @lgirdwood Based on my quick test the ext bytes get works without placing the header to data[0] and data[1]. I can read back successfully the previously written coefficients to user space. Maybe using this header for get is a misunderstanding.

The header definitely is present in ext bytes put copy_from_user() so this looks different. Any thoughts on this?

@singalsu I would follow any prior art that is upstream on the matter. Lets do the same.

singalsu · 2018-09-21T12:06:50Z

@ranj063 @lgirdwood I've updated the PR now. Though I'm not sure if use of struct snd_ctl_tlv was your recommendation or should I use a SOF version of it. In line 385 I set the numid to zero. Also I wasn't sure about that vs. having macro in SOF. And it's not checked in bytes put. Thoughts?

lgirdwood · 2018-09-22T14:45:42Z

sound/soc/sof/control.c

+					SOF_IPC_COMP_GET_DATA,
+					SOF_CTRL_TYPE_DATA_GET, scontrol->cmd);
+
+	header.numid = 0;


Should't this be the same ID as passed in binary_data ?

Do you mean that numid should be set to scontrol->cmd (e.g. SOF_CTRL_CMD_BINARY)? And should we add check to put function that numid == scontrol->cmd?

This patch adds to bytes put a check to not exceed the topology defined bytes control length. The tlv control header is used for retrieving length instead to directly access the header words. In bytes get the size field in the header is set the to the value that is passed to the function minus the header length. It prevents to write past the user space buffer. The size parameter originates from topology. Checks for size violations vs. topology and IPC are added. The other changes add debug prints to kernel log to see the actual size limits and do code cleanup. Signed-off-by: Seppo Ingalsuo <seppo.ingalsuo@linux.intel.com>

singalsu · 2018-09-24T14:34:29Z

@lgirdwood I just pushed updated version. The numid is now compared to/set to scontrol->cmd. Hope you meant this with your comment.

…part2 Documentation: teaching: labs: filesystems_part2: Fix typos

MAINTAINERS: update

…ed bind() Syzbot detected a NULL pointer dereference of nfc_llcp_sock->dev pointer (which is a 'struct nfc_dev *') with calls to llcp_sock_sendmsg() after a failed llcp_sock_bind(). The message being sent is a SOCK_DGRAM. KASAN report: BUG: KASAN: null-ptr-deref in nfc_alloc_send_skb+0x2d/0xc0 Read of size 4 at addr 00000000000005c8 by task llcp_sock_nfc_a/899 CPU: 5 PID: 899 Comm: llcp_sock_nfc_a Not tainted 5.16.0-rc6-next-20211224-00001-gc6437fbf18b0 thesofproject#125 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.14.0-2 04/01/2014 Call Trace: <TASK> dump_stack_lvl+0x45/0x59 ? nfc_alloc_send_skb+0x2d/0xc0 __kasan_report.cold+0x117/0x11c ? mark_lock+0x480/0x4f0 ? nfc_alloc_send_skb+0x2d/0xc0 kasan_report+0x38/0x50 nfc_alloc_send_skb+0x2d/0xc0 nfc_llcp_send_ui_frame+0x18c/0x2a0 ? nfc_llcp_send_i_frame+0x230/0x230 ? __local_bh_enable_ip+0x86/0xe0 ? llcp_sock_connect+0x470/0x470 ? llcp_sock_connect+0x470/0x470 sock_sendmsg+0x8e/0xa0 ____sys_sendmsg+0x253/0x3f0 ... The issue was visible only with multiple simultaneous calls to bind() and sendmsg(), which resulted in most of the bind() calls to fail. The bind() was failing on checking if there is available WKS/SDP/SAP (respective bit in 'struct nfc_llcp_local' fields). When there was no available WKS/SDP/SAP, the bind returned error but the sendmsg() to such socket was able to trigger mentioned NULL pointer dereference of nfc_llcp_sock->dev. The code looks simply racy and currently it protects several paths against race with checks for (!nfc_llcp_sock->local) which is NULL-ified in error paths of bind(). The llcp_sock_sendmsg() did not have such check but called function nfc_llcp_send_ui_frame() had, although not protected with lock_sock(). Therefore the race could look like (same socket is used all the time): CPU0 CPU1 ==== ==== llcp_sock_bind() - lock_sock() - success - release_sock() - return 0 llcp_sock_sendmsg() - lock_sock() - release_sock() llcp_sock_bind(), same socket - lock_sock() - error - nfc_llcp_send_ui_frame() - if (!llcp_sock->local) - llcp_sock->local = NULL - nfc_put_device(dev) - dereference llcp_sock->dev - release_sock() - return -ERRNO The nfc_llcp_send_ui_frame() checked llcp_sock->local outside of the lock, which is racy and ineffective check. Instead, its caller llcp_sock_sendmsg(), should perform the check inside lock_sock(). Reported-and-tested-by: syzbot+7f23bcddf626e0593a39@syzkaller.appspotmail.com Fixes: b874dec ("NFC: Implement LLCP connection less Tx path") Cc: <stable@vger.kernel.org> Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@canonical.com> Signed-off-by: David S. Miller <davem@davemloft.net>

Like commit 1cf3bfc ("bpf: Support 64-bit pointers to kfuncs") for s390x, add support for 64-bit pointers to kfuncs for LoongArch. Since the infrastructure is already implemented in BPF core, the only thing need to be done is to override bpf_jit_supports_far_kfunc_call(). Before this change, several test_verifier tests failed: # ./test_verifier | grep # | grep FAIL thesofproject#119/p calls: invalid kfunc call: ptr_to_mem to struct with non-scalar FAIL thesofproject#120/p calls: invalid kfunc call: ptr_to_mem to struct with nesting depth > 4 FAIL thesofproject#121/p calls: invalid kfunc call: ptr_to_mem to struct with FAM FAIL thesofproject#122/p calls: invalid kfunc call: reg->type != PTR_TO_CTX FAIL thesofproject#123/p calls: invalid kfunc call: void * not allowed in func proto without mem size arg FAIL thesofproject#124/p calls: trigger reg2btf_ids[reg->type] for reg->type > __BPF_REG_TYPE_MAX FAIL thesofproject#125/p calls: invalid kfunc call: reg->off must be zero when passed to release kfunc FAIL thesofproject#126/p calls: invalid kfunc call: don't match first member type when passed to release kfunc FAIL thesofproject#127/p calls: invalid kfunc call: PTR_TO_BTF_ID with negative offset FAIL thesofproject#128/p calls: invalid kfunc call: PTR_TO_BTF_ID with variable offset FAIL thesofproject#129/p calls: invalid kfunc call: referenced arg needs refcounted PTR_TO_BTF_ID FAIL thesofproject#130/p calls: valid kfunc call: referenced arg needs refcounted PTR_TO_BTF_ID FAIL thesofproject#486/p map_kptr: ref: reference state created and released on xchg FAIL This is because the kfuncs in the loaded module are far away from __bpf_call_base: ffff800002009440 t bpf_kfunc_call_test_fail1 [bpf_testmod] 9000000002e128d8 T __bpf_call_base The offset relative to __bpf_call_base does NOT fit in s32, which breaks the assumption in BPF core. Enable bpf_jit_supports_far_kfunc_call() lifts this limit. Note that to reproduce the above result, tools/testing/selftests/bpf/config should be applied, and run the test with JIT enabled, unpriv BPF enabled. With this change, the test_verifier tests now all passed: # ./test_verifier ... Summary: 777 PASSED, 0 SKIPPED, 0 FAILED Tested-by: Tiezhu Yang <yangtiezhu@loongson.cn> Signed-off-by: Hengqi Chen <hengqi.chen@gmail.com> Signed-off-by: Huacai Chen <chenhuacai@loongson.cn>

Element replace (with a socket different from the one stored) may race with socket's close() link popping & unlinking. __sock_map_delete() unconditionally unrefs the (wrong) element: // set map[0] = s0 map_update_elem(map, 0, s0) // drop fd of s0 close(s0) sock_map_close() lock_sock(sk) (s0!) sock_map_remove_links(sk) link = sk_psock_link_pop() sock_map_unlink(sk, link) sock_map_delete_from_link // replace map[0] with s1 map_update_elem(map, 0, s1) sock_map_update_elem (s1!) lock_sock(sk) sock_map_update_common psock = sk_psock(sk) spin_lock(&stab->lock) osk = stab->sks[idx] sock_map_add_link(..., &stab->sks[idx]) sock_map_unref(osk, &stab->sks[idx]) psock = sk_psock(osk) sk_psock_put(sk, psock) if (refcount_dec_and_test(&psock)) sk_psock_drop(sk, psock) spin_unlock(&stab->lock) unlock_sock(sk) __sock_map_delete spin_lock(&stab->lock) sk = *psk // s1 replaced s0; sk == s1 if (!sk_test || sk_test == sk) // sk_test (s0) != sk (s1); no branch sk = xchg(psk, NULL) if (sk) sock_map_unref(sk, psk) // unref s1; sks[idx] will dangle psock = sk_psock(sk) sk_psock_put(sk, psock) if (refcount_dec_and_test()) sk_psock_drop(sk, psock) spin_unlock(&stab->lock) release_sock(sk) Then close(map) enqueues bpf_map_free_deferred, which finally calls sock_map_free(). This results in some refcount_t warnings along with a KASAN splat [1]. Fix __sock_map_delete(), do not allow sock_map_unref() on elements that may have been replaced. [1]: BUG: KASAN: slab-use-after-free in sock_map_free+0x10e/0x330 Write of size 4 at addr ffff88811f5b9100 by task kworker/u64:12/1063 CPU: 14 UID: 0 PID: 1063 Comm: kworker/u64:12 Not tainted 6.12.0+ thesofproject#125 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Arch Linux 1.16.3-1-1 04/01/2014 Workqueue: events_unbound bpf_map_free_deferred Call Trace: <TASK> dump_stack_lvl+0x68/0x90 print_report+0x174/0x4f6 kasan_report+0xb9/0x190 kasan_check_range+0x10f/0x1e0 sock_map_free+0x10e/0x330 bpf_map_free_deferred+0x173/0x320 process_one_work+0x846/0x1420 worker_thread+0x5b3/0xf80 kthread+0x29e/0x360 ret_from_fork+0x2d/0x70 ret_from_fork_asm+0x1a/0x30 </TASK> Allocated by task 1202: kasan_save_stack+0x1e/0x40 kasan_save_track+0x10/0x30 __kasan_slab_alloc+0x85/0x90 kmem_cache_alloc_noprof+0x131/0x450 sk_prot_alloc+0x5b/0x220 sk_alloc+0x2c/0x870 unix_create1+0x88/0x8a0 unix_create+0xc5/0x180 __sock_create+0x241/0x650 __sys_socketpair+0x1ce/0x420 __x64_sys_socketpair+0x92/0x100 do_syscall_64+0x93/0x180 entry_SYSCALL_64_after_hwframe+0x76/0x7e Freed by task 46: kasan_save_stack+0x1e/0x40 kasan_save_track+0x10/0x30 kasan_save_free_info+0x37/0x60 __kasan_slab_free+0x4b/0x70 kmem_cache_free+0x1a1/0x590 __sk_destruct+0x388/0x5a0 sk_psock_destroy+0x73e/0xa50 process_one_work+0x846/0x1420 worker_thread+0x5b3/0xf80 kthread+0x29e/0x360 ret_from_fork+0x2d/0x70 ret_from_fork_asm+0x1a/0x30 The buggy address belongs to the object at ffff88811f5b9080 which belongs to the cache UNIX-STREAM of size 1984 The buggy address is located 128 bytes inside of freed 1984-byte region [ffff88811f5b9080, ffff88811f5b9840) The buggy address belongs to the physical page: page: refcount:1 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x11f5b8 head: order:3 mapcount:0 entire_mapcount:0 nr_pages_mapped:0 pincount:0 memcg:ffff888127d49401 flags: 0x17ffffc0000040(head|node=0|zone=2|lastcpupid=0x1fffff) page_type: f5(slab) raw: 0017ffffc0000040 ffff8881042e4500 dead000000000122 0000000000000000 raw: 0000000000000000 00000000800f000f 00000001f5000000 ffff888127d49401 head: 0017ffffc0000040 ffff8881042e4500 dead000000000122 0000000000000000 head: 0000000000000000 00000000800f000f 00000001f5000000 ffff888127d49401 head: 0017ffffc0000003 ffffea00047d6e01 ffffffffffffffff 0000000000000000 head: 0000000000000008 0000000000000000 00000000ffffffff 0000000000000000 page dumped because: kasan: bad access detected Memory state around the buggy address: ffff88811f5b9000: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc ffff88811f5b9080: fa fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ^ ffff88811f5b9180: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ffff88811f5b9200: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb Disabling lock debugging due to kernel taint refcount_t: addition on 0; use-after-free. WARNING: CPU: 14 PID: 1063 at lib/refcount.c:25 refcount_warn_saturate+0xce/0x150 CPU: 14 UID: 0 PID: 1063 Comm: kworker/u64:12 Tainted: G B 6.12.0+ thesofproject#125 Tainted: [B]=BAD_PAGE Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Arch Linux 1.16.3-1-1 04/01/2014 Workqueue: events_unbound bpf_map_free_deferred RIP: 0010:refcount_warn_saturate+0xce/0x150 Code: 34 73 eb 03 01 e8 82 53 ad fe 0f 0b eb b1 80 3d 27 73 eb 03 00 75 a8 48 c7 c7 80 bd 95 84 c6 05 17 73 eb 03 01 e8 62 53 ad fe <0f> 0b eb 91 80 3d 06 73 eb 03 00 75 88 48 c7 c7 e0 bd 95 84 c6 05 RSP: 0018:ffff88815c49fc70 EFLAGS: 00010282 RAX: 0000000000000000 RBX: ffff88811f5b9100 RCX: 0000000000000000 RDX: 0000000000000000 RSI: 0000000000000004 RDI: 0000000000000001 RBP: 0000000000000002 R08: 0000000000000001 R09: ffffed10bcde6349 R10: ffff8885e6f31a4b R11: 0000000000000000 R12: ffff88813be0b000 R13: ffff88811f5b9100 R14: ffff88811f5b9080 R15: ffff88813be0b024 FS: 0000000000000000(0000) GS:ffff8885e6f00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 000055dda99b0250 CR3: 000000015dbac000 CR4: 0000000000752ef0 PKRU: 55555554 Call Trace: <TASK> ? __warn.cold+0x5f/0x1ff ? refcount_warn_saturate+0xce/0x150 ? report_bug+0x1ec/0x390 ? handle_bug+0x58/0x90 ? exc_invalid_op+0x13/0x40 ? asm_exc_invalid_op+0x16/0x20 ? refcount_warn_saturate+0xce/0x150 sock_map_free+0x2e5/0x330 bpf_map_free_deferred+0x173/0x320 process_one_work+0x846/0x1420 worker_thread+0x5b3/0xf80 kthread+0x29e/0x360 ret_from_fork+0x2d/0x70 ret_from_fork_asm+0x1a/0x30 </TASK> irq event stamp: 10741 hardirqs last enabled at (10741): [<ffffffff84400ec6>] asm_sysvec_apic_timer_interrupt+0x16/0x20 hardirqs last disabled at (10740): [<ffffffff811e532d>] handle_softirqs+0x60d/0x770 softirqs last enabled at (10506): [<ffffffff811e55a9>] __irq_exit_rcu+0x109/0x210 softirqs last disabled at (10301): [<ffffffff811e55a9>] __irq_exit_rcu+0x109/0x210 refcount_t: underflow; use-after-free. WARNING: CPU: 14 PID: 1063 at lib/refcount.c:28 refcount_warn_saturate+0xee/0x150 CPU: 14 UID: 0 PID: 1063 Comm: kworker/u64:12 Tainted: G B W 6.12.0+ thesofproject#125 Tainted: [B]=BAD_PAGE, [W]=WARN Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Arch Linux 1.16.3-1-1 04/01/2014 Workqueue: events_unbound bpf_map_free_deferred RIP: 0010:refcount_warn_saturate+0xee/0x150 Code: 17 73 eb 03 01 e8 62 53 ad fe 0f 0b eb 91 80 3d 06 73 eb 03 00 75 88 48 c7 c7 e0 bd 95 84 c6 05 f6 72 eb 03 01 e8 42 53 ad fe <0f> 0b e9 6e ff ff ff 80 3d e6 72 eb 03 00 0f 85 61 ff ff ff 48 c7 RSP: 0018:ffff88815c49fc70 EFLAGS: 00010282 RAX: 0000000000000000 RBX: ffff88811f5b9100 RCX: 0000000000000000 RDX: 0000000000000000 RSI: 0000000000000004 RDI: 0000000000000001 RBP: 0000000000000003 R08: 0000000000000001 R09: ffffed10bcde6349 R10: ffff8885e6f31a4b R11: 0000000000000000 R12: ffff88813be0b000 R13: ffff88811f5b9100 R14: ffff88811f5b9080 R15: ffff88813be0b024 FS: 0000000000000000(0000) GS:ffff8885e6f00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 000055dda99b0250 CR3: 000000015dbac000 CR4: 0000000000752ef0 PKRU: 55555554 Call Trace: <TASK> ? __warn.cold+0x5f/0x1ff ? refcount_warn_saturate+0xee/0x150 ? report_bug+0x1ec/0x390 ? handle_bug+0x58/0x90 ? exc_invalid_op+0x13/0x40 ? asm_exc_invalid_op+0x16/0x20 ? refcount_warn_saturate+0xee/0x150 sock_map_free+0x2d3/0x330 bpf_map_free_deferred+0x173/0x320 process_one_work+0x846/0x1420 worker_thread+0x5b3/0xf80 kthread+0x29e/0x360 ret_from_fork+0x2d/0x70 ret_from_fork_asm+0x1a/0x30 </TASK> irq event stamp: 10741 hardirqs last enabled at (10741): [<ffffffff84400ec6>] asm_sysvec_apic_timer_interrupt+0x16/0x20 hardirqs last disabled at (10740): [<ffffffff811e532d>] handle_softirqs+0x60d/0x770 softirqs last enabled at (10506): [<ffffffff811e55a9>] __irq_exit_rcu+0x109/0x210 softirqs last disabled at (10301): [<ffffffff811e55a9>] __irq_exit_rcu+0x109/0x210 Fixes: 604326b ("bpf, sockmap: convert to generic sk_msg interface") Signed-off-by: Michal Luczaj <mhal@rbox.co> Signed-off-by: Daniel Borkmann <daniel@iogearbox.net> Reviewed-by: John Fastabend <john.fastabend@gmail.com> Link: https://lore.kernel.org/bpf/20241202-sockmap-replace-v1-3-1e88579e7bd5@rbox.co

singalsu requested a review from ranj063 September 11, 2018 12:46

ranj063 reviewed Sep 11, 2018

View reviewed changes

ranj063 reviewed Sep 12, 2018

View reviewed changes

singalsu force-pushed the fix_ext_bytes_get_proposal branch from 7a64a66 to 171e225 Compare September 12, 2018 10:28

ranj063 reviewed Sep 12, 2018

View reviewed changes

singalsu requested a review from lgirdwood September 13, 2018 07:31

lgirdwood reviewed Sep 13, 2018

View reviewed changes

singalsu force-pushed the fix_ext_bytes_get_proposal branch from 171e225 to 0c7c77a Compare September 21, 2018 11:52

lgirdwood reviewed Sep 22, 2018

View reviewed changes

singalsu force-pushed the fix_ext_bytes_get_proposal branch from 0c7c77a to 36a50af Compare September 24, 2018 14:28

lgirdwood merged commit b5cde88 into thesofproject:topic/sof-dev Sep 24, 2018

paulstelian97 pushed a commit to paulstelian97/linux that referenced this pull request May 4, 2020

Merge pull request thesofproject#125 from Sergiu121/labs/filesystems_…

67b5176

…part2 Documentation: teaching: labs: filesystems_part2: Fix typos

aiChaoSONG pushed a commit to aiChaoSONG/linux that referenced this pull request May 6, 2021

Merge pull request thesofproject#125 from ojeda/maintainers

35b9d14

MAINTAINERS: update

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

ASoC: SOF: Fix buffer copy size error in ext bytes get and add checks #125

ASoC: SOF: Fix buffer copy size error in ext bytes get and add checks #125

singalsu commented Sep 11, 2018

ranj063 Sep 11, 2018

singalsu Sep 12, 2018

ranj063 Sep 11, 2018

singalsu Sep 12, 2018

ranj063 Sep 12, 2018

singalsu Sep 12, 2018

singalsu commented Sep 12, 2018

ranj063 Sep 12, 2018

singalsu Sep 12, 2018

ranj063 Sep 12, 2018

lgirdwood Sep 13, 2018

lgirdwood Sep 13, 2018

ranj063 Sep 18, 2018

lgirdwood Sep 18, 2018

singalsu Sep 18, 2018

singalsu Sep 18, 2018

singalsu Sep 18, 2018

lgirdwood Sep 18, 2018

singalsu commented Sep 21, 2018

lgirdwood Sep 22, 2018

singalsu Sep 24, 2018

singalsu commented Sep 24, 2018

ASoC: SOF: Fix buffer copy size error in ext bytes get and add checks #125

ASoC: SOF: Fix buffer copy size error in ext bytes get and add checks #125

Conversation

singalsu commented Sep 11, 2018

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

singalsu commented Sep 12, 2018

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

singalsu commented Sep 21, 2018

Choose a reason for hiding this comment

Choose a reason for hiding this comment

singalsu commented Sep 24, 2018