Vulnerabilidades

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> Bluetooth: use RCU for hci_conn_params and iterate safely in hci_sync<br /> <br /> hci_update_accept_list_sync iterates over hdev-&gt;pend_le_conns and<br /> hdev-&gt;pend_le_reports, and waits for controller events in the loop body,<br /> without holding hdev lock.<br /> <br /> Meanwhile, these lists and the items may be modified e.g. by<br /> le_scan_cleanup. This can invalidate the list cursor or any other item<br /> in the list, resulting to invalid behavior (eg use-after-free).<br /> <br /> Use RCU for the hci_conn_params action lists. Since the loop bodies in<br /> hci_sync block and we cannot use RCU or hdev-&gt;lock for the whole loop,<br /> copy list items first and then iterate on the copy. Only the flags field<br /> is written from elsewhere, so READ_ONCE/WRITE_ONCE should guarantee we<br /> read valid values.<br /> <br /> Free params everywhere with hci_conn_params_free so the cleanup is<br /> guaranteed to be done properly.<br /> <br /> This fixes the following, which can be triggered e.g. by BlueZ new<br /> mgmt-tester case "Add + Remove Device Nowait - Success", or by changing<br /> hci_le_set_cig_params to always return false, and running iso-tester:<br /> <br /> ==================================================================<br /> BUG: KASAN: slab-use-after-free in hci_update_passive_scan_sync (net/bluetooth/hci_sync.c:2536 net/bluetooth/hci_sync.c:2723 net/bluetooth/hci_sync.c:2841)<br /> Read of size 8 at addr ffff888001265018 by task kworker/u3:0/32<br /> <br /> Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.2-1.fc38 04/01/2014<br /> Workqueue: hci0 hci_cmd_sync_work<br /> Call Trace:<br /> <br /> dump_stack_lvl (./arch/x86/include/asm/irqflags.h:134 lib/dump_stack.c:107)<br /> print_report (mm/kasan/report.c:320 mm/kasan/report.c:430)<br /> ? __virt_addr_valid (./include/linux/mmzone.h:1915 ./include/linux/mmzone.h:2011 arch/x86/mm/physaddr.c:65)<br /> ? hci_update_passive_scan_sync (net/bluetooth/hci_sync.c:2536 net/bluetooth/hci_sync.c:2723 net/bluetooth/hci_sync.c:2841)<br /> kasan_report (mm/kasan/report.c:538)<br /> ? hci_update_passive_scan_sync (net/bluetooth/hci_sync.c:2536 net/bluetooth/hci_sync.c:2723 net/bluetooth/hci_sync.c:2841)<br /> hci_update_passive_scan_sync (net/bluetooth/hci_sync.c:2536 net/bluetooth/hci_sync.c:2723 net/bluetooth/hci_sync.c:2841)<br /> ? __pfx_hci_update_passive_scan_sync (net/bluetooth/hci_sync.c:2780)<br /> ? mutex_lock (kernel/locking/mutex.c:282)<br /> ? __pfx_mutex_lock (kernel/locking/mutex.c:282)<br /> ? __pfx_mutex_unlock (kernel/locking/mutex.c:538)<br /> ? __pfx_update_passive_scan_sync (net/bluetooth/hci_sync.c:2861)<br /> hci_cmd_sync_work (net/bluetooth/hci_sync.c:306)<br /> process_one_work (./arch/x86/include/asm/preempt.h:27 kernel/workqueue.c:2399)<br /> worker_thread (./include/linux/list.h:292 kernel/workqueue.c:2538)<br /> ? __pfx_worker_thread (kernel/workqueue.c:2480)<br /> kthread (kernel/kthread.c:376)<br /> ? __pfx_kthread (kernel/kthread.c:331)<br /> ret_from_fork (arch/x86/entry/entry_64.S:314)<br /> <br /> <br /> Allocated by task 31:<br /> kasan_save_stack (mm/kasan/common.c:46)<br /> kasan_set_track (mm/kasan/common.c:52)<br /> __kasan_kmalloc (mm/kasan/common.c:374 mm/kasan/common.c:383)<br /> hci_conn_params_add (./include/linux/slab.h:580 ./include/linux/slab.h:720 net/bluetooth/hci_core.c:2277)<br /> hci_connect_le_scan (net/bluetooth/hci_conn.c:1419 net/bluetooth/hci_conn.c:1589)<br /> hci_connect_cis (net/bluetooth/hci_conn.c:2266)<br /> iso_connect_cis (net/bluetooth/iso.c:390)<br /> iso_sock_connect (net/bluetooth/iso.c:899)<br /> __sys_connect (net/socket.c:2003 net/socket.c:2020)<br /> __x64_sys_connect (net/socket.c:2027)<br /> do_syscall_64 (arch/x86/entry/common.c:50 arch/x86/entry/common.c:80)<br /> entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:120)<br /> <br /> Freed by task 15:<br /> kasan_save_stack (mm/kasan/common.c:46)<br /> kasan_set_track (mm/kasan/common.c:52)<br /> kasan_save_free_info (mm/kasan/generic.c:523)<br /> __kasan_slab_free (mm/kasan/common.c:238 mm/kasan/common.c:200 mm/kasan/common.c:244)<br /> __kmem_cache_free (mm/slub.c:1807 mm/slub.c:3787 mm/slub.c:3800)<br /> hci_conn_params_del (net/bluetooth/hci_core.c:2323)<br /> le_scan_cleanup (net/bluetooth/hci_conn.c:202)<br /> process_one_work (./arch/x86/include/asm/preempt.<br /> ---truncated---

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> HID: nvidia-shield: Reference hid_device devm allocation of input_dev name<br /> <br /> Use hid_device for devm allocation of the input_dev name to avoid a<br /> use-after-free. input_unregister_device would trigger devres cleanup of all<br /> resources associated with the input_dev, free-ing the name. The name would<br /> subsequently be used in a uevent fired at the end of unregistering the<br /> input_dev.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> cacheinfo: Fix shared_cpu_map to handle shared caches at different levels<br /> <br /> The cacheinfo sets up the shared_cpu_map by checking whether the caches<br /> with the same index are shared between CPUs. However, this will trigger<br /> slab-out-of-bounds access if the CPUs do not have the same cache hierarchy.<br /> Another problem is the mismatched shared_cpu_map when the shared cache does<br /> not have the same index between CPUs.<br /> <br /> CPU0 I D L3<br /> index 0 1 2 x<br /> ^ ^ ^ ^<br /> index 0 1 2 3<br /> CPU1 I D L2 L3<br /> <br /> This patch checks each cache is shared with all caches on other CPUs.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> firmware: stratix10-svc: Fix a potential resource leak in svc_create_memory_pool()<br /> <br /> svc_create_memory_pool() is only called from stratix10_svc_drv_probe().<br /> Most of resources in the probe are managed, but not this memremap() call.<br /> <br /> There is also no memunmap() call in the file.<br /> <br /> So switch to devm_memremap() to avoid a resource leak.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> firmware: arm_ffa: Fix FFA device names for logical partitions<br /> <br /> Each physical partition can provide multiple services each with UUID.<br /> Each such service can be presented as logical partition with a unique<br /> combination of VM ID and UUID. The number of distinct UUID in a system<br /> will be less than or equal to the number of logical partitions.<br /> <br /> However, currently it fails to register more than one logical partition<br /> or service within a physical partition as the device name contains only<br /> VM ID while both VM ID and UUID are maintained in the partition information.<br /> The kernel complains with the below message:<br /> <br /> | sysfs: cannot create duplicate filename &amp;#39;/devices/arm-ffa-8001&amp;#39;<br /> | CPU: 1 PID: 1 Comm: swapper/0 Not tainted 6.3.0-rc7 #8<br /> | Hardware name: FVP Base RevC (DT)<br /> | Call trace:<br /> | dump_backtrace+0xf8/0x118<br /> | show_stack+0x18/0x24<br /> | dump_stack_lvl+0x50/0x68<br /> | dump_stack+0x18/0x24<br /> | sysfs_create_dir_ns+0xe0/0x13c<br /> | kobject_add_internal+0x220/0x3d4<br /> | kobject_add+0x94/0x100<br /> | device_add+0x144/0x5d8<br /> | device_register+0x20/0x30<br /> | ffa_device_register+0x88/0xd8<br /> | ffa_setup_partitions+0x108/0x1b8<br /> | ffa_init+0x2ec/0x3a4<br /> | do_one_initcall+0xcc/0x240<br /> | do_initcall_level+0x8c/0xac<br /> | do_initcalls+0x54/0x94<br /> | do_basic_setup+0x1c/0x28<br /> | kernel_init_freeable+0x100/0x16c<br /> | kernel_init+0x20/0x1a0<br /> | ret_from_fork+0x10/0x20<br /> | kobject_add_internal failed for arm-ffa-8001 with -EEXIST, don&amp;#39;t try to<br /> | register things with the same name in the same directory.<br /> | arm_ffa arm-ffa: unable to register device arm-ffa-8001 err=-17<br /> | ARM FF-A: ffa_setup_partitions: failed to register partition ID 0x8001<br /> <br /> By virtue of being random enough to avoid collisions when generated in a<br /> distributed system, there is no way to compress UUID keys to the number<br /> of bits required to identify each. We can eliminate &amp;#39;-&amp;#39; in the name but<br /> it is not worth eliminating 4 bytes and add unnecessary logic for doing<br /> that. Also v1.0 doesn&amp;#39;t provide the UUID of the partitions which makes<br /> it hard to use the same for the device name.<br /> <br /> So to keep it simple, let us alloc an ID using ida_alloc() and append the<br /> same to "arm-ffa" to make up a unique device name. Also stash the id value<br /> in ffa_dev to help freeing the ID later when the device is destroyed.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> cifs: fix DFS traversal oops without CONFIG_CIFS_DFS_UPCALL<br /> <br /> When compiled with CONFIG_CIFS_DFS_UPCALL disabled, cifs_dfs_d_automount<br /> is NULL. cifs.ko logic for mapping CIFS_FATTR_DFS_REFERRAL attributes to<br /> S_AUTOMOUNT and corresponding dentry flags is retained regardless of<br /> CONFIG_CIFS_DFS_UPCALL, leading to a NULL pointer dereference in<br /> VFS follow_automount() when traversing a DFS referral link:<br /> BUG: kernel NULL pointer dereference, address: 0000000000000000<br /> ...<br /> Call Trace:<br /> <br /> __traverse_mounts+0xb5/0x220<br /> ? cifs_revalidate_mapping+0x65/0xc0 [cifs]<br /> step_into+0x195/0x610<br /> ? lookup_fast+0xe2/0xf0<br /> path_lookupat+0x64/0x140<br /> filename_lookup+0xc2/0x140<br /> ? __create_object+0x299/0x380<br /> ? kmem_cache_alloc+0x119/0x220<br /> ? user_path_at_empty+0x31/0x50<br /> user_path_at_empty+0x31/0x50<br /> __x64_sys_chdir+0x2a/0xd0<br /> ? exit_to_user_mode_prepare+0xca/0x100<br /> do_syscall_64+0x42/0x90<br /> entry_SYSCALL_64_after_hwframe+0x72/0xdc<br /> <br /> This fix adds an inline cifs_dfs_d_automount() {return -EREMOTE} handler<br /> when CONFIG_CIFS_DFS_UPCALL is disabled. An alternative would be to<br /> avoid flagging S_AUTOMOUNT, etc. without CONFIG_CIFS_DFS_UPCALL. This<br /> approach was chosen as it provides more control over the error path.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/msm/mdp5: Add check for kzalloc<br /> <br /> As kzalloc may fail and return NULL pointer,<br /> it should be better to check the return value<br /> in order to avoid the NULL pointer dereference.<br /> <br /> Patchwork: https://patchwork.freedesktop.org/patch/514154/

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> xsk: check IFF_UP earlier in Tx path<br /> <br /> Xsk Tx can be triggered via either sendmsg() or poll() syscalls. These<br /> two paths share a call to common function xsk_xmit() which has two<br /> sanity checks within. A pseudo code example to show the two paths:<br /> <br /> __xsk_sendmsg() : xsk_poll():<br /> if (unlikely(!xsk_is_bound(xs))) if (unlikely(!xsk_is_bound(xs)))<br /> return -ENXIO; return mask;<br /> if (unlikely(need_wait)) (...)<br /> return -EOPNOTSUPP; xsk_xmit()<br /> mark napi id<br /> (...)<br /> xsk_xmit()<br /> <br /> xsk_xmit():<br /> if (unlikely(!(xs-&gt;dev-&gt;flags &amp; IFF_UP)))<br /> return -ENETDOWN;<br /> if (unlikely(!xs-&gt;tx))<br /> return -ENOBUFS;<br /> <br /> As it can be observed above, in sendmsg() napi id can be marked on<br /> interface that was not brought up and this causes a NULL ptr<br /> dereference:<br /> <br /> [31757.505631] BUG: kernel NULL pointer dereference, address: 0000000000000018<br /> [31757.512710] #PF: supervisor read access in kernel mode<br /> [31757.517936] #PF: error_code(0x0000) - not-present page<br /> [31757.523149] PGD 0 P4D 0<br /> [31757.525726] Oops: 0000 [#1] PREEMPT SMP NOPTI<br /> [31757.530154] CPU: 26 PID: 95641 Comm: xdpsock Not tainted 6.2.0-rc5+ #40<br /> [31757.536871] Hardware name: Intel Corporation S2600WFT/S2600WFT, BIOS SE5C620.86B.02.01.0008.031920191559 03/19/2019<br /> [31757.547457] RIP: 0010:xsk_sendmsg+0xde/0x180<br /> [31757.551799] Code: 00 75 a2 48 8b 00 a8 04 75 9b 84 d2 74 69 8b 85 14 01 00 00 85 c0 75 1b 48 8b 85 28 03 00 00 48 8b 80 98 00 00 00 48 8b 40 20 40 18 89 85 14 01 00 00 8b bd 14 01 00 00 81 ff 00 01 00 00 0f<br /> [31757.570840] RSP: 0018:ffffc90034f27dc0 EFLAGS: 00010246<br /> [31757.576143] RAX: 0000000000000000 RBX: ffffc90034f27e18 RCX: 0000000000000000<br /> [31757.583389] RDX: 0000000000000001 RSI: ffffc90034f27e18 RDI: ffff88984cf3c100<br /> [31757.590631] RBP: ffff88984714a800 R08: ffff88984714a800 R09: 0000000000000000<br /> [31757.597877] R10: 0000000000000001 R11: 0000000000000000 R12: 00000000fffffffa<br /> [31757.605123] R13: 0000000000000000 R14: 0000000000000003 R15: 0000000000000000<br /> [31757.612364] FS: 00007fb4c5931180(0000) GS:ffff88afdfa00000(0000) knlGS:0000000000000000<br /> [31757.620571] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> [31757.626406] CR2: 0000000000000018 CR3: 000000184b41c003 CR4: 00000000007706e0<br /> [31757.633648] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000<br /> [31757.640894] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400<br /> [31757.648139] PKRU: 55555554<br /> [31757.650894] Call Trace:<br /> [31757.653385] <br /> [31757.655524] sock_sendmsg+0x8f/0xa0<br /> [31757.659077] ? sockfd_lookup_light+0x12/0x70<br /> [31757.663416] __sys_sendto+0xfc/0x170<br /> [31757.667051] ? do_sched_setscheduler+0xdb/0x1b0<br /> [31757.671658] __x64_sys_sendto+0x20/0x30<br /> [31757.675557] do_syscall_64+0x38/0x90<br /> [31757.679197] entry_SYSCALL_64_after_hwframe+0x72/0xdc<br /> [31757.687969] Code: 8e f6 ff 44 8b 4c 24 2c 4c 8b 44 24 20 41 89 c4 44 8b 54 24 28 48 8b 54 24 18 b8 2c 00 00 00 48 8b 74 24 10 8b 7c 24 08 0f 05 3d 00 f0 ff ff 77 3a 44 89 e7 48 89 44 24 08 e8 b5 8e f6 ff 48<br /> [31757.707007] RSP: 002b:00007ffd49c73c70 EFLAGS: 00000293 ORIG_RAX: 000000000000002c<br /> [31757.714694] RAX: ffffffffffffffda RBX: 000055a996565380 RCX: 00007fb4c5727c16<br /> [31757.721939] RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000003<br /> [31757.729184] RBP: 0000000000000040 R08: 0000000000000000 R09: 0000000000000000<br /> [31757.736429] R10: 0000000000000040 R11: 0000000000000293 R12: 0000000000000000<br /> [31757.743673] R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000<br /> [31757.754940] <br /> <br /> To fix this, let&amp;#39;s make xsk_xmit a function that will be responsible for<br /> generic Tx, where RCU is handled accordingly and pull out sanity checks<br /> and xs-&gt;zc handling. Populate sanity checks to __xsk_sendmsg() and<br /> xsk_poll().

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> nfsd: call op_release, even when op_func returns an error<br /> <br /> For ops with "trivial" replies, nfsd4_encode_operation will shortcut<br /> most of the encoding work and skip to just marshalling up the status.<br /> One of the things it skips is calling op_release. This could cause a<br /> memory leak in the layoutget codepath if there is an error at an<br /> inopportune time.<br /> <br /> Have the compound processing engine always call op_release, even when<br /> op_func sets an error in op-&gt;status. With this change, we also need<br /> nfsd4_block_get_device_info_scsi to set the gd_device pointer to NULL<br /> on error to avoid a double free.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> thermal/drivers/hisi: Drop second sensor hi3660<br /> <br /> The commit 74c8e6bffbe1 ("driver core: Add __alloc_size hint to devm<br /> allocators") exposes a panic "BRK handler: Fatal exception" on the<br /> hi3660_thermal_probe funciton.<br /> This is because the function allocates memory for only one<br /> sensors array entry, but tries to fill up a second one.<br /> <br /> Fix this by removing the unneeded second access.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> btrfs: add handling for RAID1C23/DUP to btrfs_reduce_alloc_profile<br /> <br /> Callers of `btrfs_reduce_alloc_profile` expect it to return exactly<br /> one allocation profile flag, and failing to do so may ultimately<br /> result in a WARN_ON and remount-ro when allocating new blocks, like<br /> the below transaction abort on 6.1.<br /> <br /> `btrfs_reduce_alloc_profile` has two ways of determining the profile,<br /> first it checks if a conversion balance is currently running and<br /> uses the profile we&amp;#39;re converting to. If no balance is currently<br /> running, it returns the max-redundancy profile which at least one<br /> block in the selected block group has.<br /> <br /> This works by simply checking each known allocation profile bit in<br /> redundancy order. However, `btrfs_reduce_alloc_profile` has not been<br /> updated as new flags have been added - first with the `DUP` profile<br /> and later with the RAID1C34 profiles.<br /> <br /> Because of the way it checks, if we have blocks with different<br /> profiles and at least one is known, that profile will be selected.<br /> However, if none are known we may return a flag set with multiple<br /> allocation profiles set.<br /> <br /> This is currently only possible when a balance from one of the three<br /> unhandled profiles to another of the unhandled profiles is canceled<br /> after allocating at least one block using the new profile.<br /> <br /> In that case, a transaction abort like the below will occur and the<br /> filesystem will need to be mounted with -o skip_balance to get it<br /> mounted rw again (but the balance cannot be resumed without a<br /> similar abort).<br /> <br /> [770.648] ------------[ cut here ]------------<br /> [770.648] BTRFS: Transaction aborted (error -22)<br /> [770.648] WARNING: CPU: 43 PID: 1159593 at fs/btrfs/extent-tree.c:4122 find_free_extent+0x1d94/0x1e00 [btrfs]<br /> [770.648] CPU: 43 PID: 1159593 Comm: btrfs Tainted: G W 6.1.0-0.deb11.7-powerpc64le #1 Debian 6.1.20-2~bpo11+1a~test<br /> [770.648] Hardware name: T2P9D01 REV 1.00 POWER9 0x4e1202 opal:skiboot-bc106a0 PowerNV<br /> [770.648] NIP: c00800000f6784fc LR: c00800000f6784f8 CTR: c000000000d746c0<br /> [770.648] REGS: c000200089afe9a0 TRAP: 0700 Tainted: G W (6.1.0-0.deb11.7-powerpc64le Debian 6.1.20-2~bpo11+1a~test)<br /> [770.648] MSR: 9000000002029033 CR: 28848282 XER: 20040000<br /> [770.648] CFAR: c000000000135110 IRQMASK: 0<br /> GPR00: c00800000f6784f8 c000200089afec40 c00800000f7ea800 0000000000000026<br /> GPR04: 00000001004820c2 c000200089afea00 c000200089afe9f8 0000000000000027<br /> GPR08: c000200ffbfe7f98 c000000002127f90 ffffffffffffffd8 0000000026d6a6e8<br /> GPR12: 0000000028848282 c000200fff7f3800 5deadbeef0000122 c00000002269d000<br /> GPR16: c0002008c7797c40 c000200089afef17 0000000000000000 0000000000000000<br /> GPR20: 0000000000000000 0000000000000001 c000200008bc5a98 0000000000000001<br /> GPR24: 0000000000000000 c0000003c73088d0 c000200089afef17 c000000016d3a800<br /> GPR28: c0000003c7308800 c00000002269d000 ffffffffffffffea 0000000000000001<br /> [770.648] NIP [c00800000f6784fc] find_free_extent+0x1d94/0x1e00 [btrfs]<br /> [770.648] LR [c00800000f6784f8] find_free_extent+0x1d90/0x1e00 [btrfs]<br /> [770.648] Call Trace:<br /> [770.648] [c000200089afec40] [c00800000f6784f8] find_free_extent+0x1d90/0x1e00 [btrfs] (unreliable)<br /> [770.648] [c000200089afed30] [c00800000f681398] btrfs_reserve_extent+0x1a0/0x2f0 [btrfs]<br /> [770.648] [c000200089afeea0] [c00800000f681bf0] btrfs_alloc_tree_block+0x108/0x670 [btrfs]<br /> [770.648] [c000200089afeff0] [c00800000f66bd68] __btrfs_cow_block+0x170/0x850 [btrfs]<br /> [770.648] [c000200089aff100] [c00800000f66c58c] btrfs_cow_block+0x144/0x288 [btrfs]<br /> [770.648] [c000200089aff1b0] [c00800000f67113c] btrfs_search_slot+0x6b4/0xcb0 [btrfs]<br /> [770.648] [c000200089aff2a0] [c00800000f679f60] lookup_inline_extent_backref+0x128/0x7c0 [btrfs]<br /> [770.648] [c000200089aff3b0] [c00800000f67b338] lookup_extent_backref+0x70/0x190 [btrfs]<br /> [770.648] [c000200089aff470] [c00800000f67b54c] __btrfs_free_extent+0xf4/0x1490 [btrfs]<br /> [770.648] [<br /> ---truncated---

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> media: pci: tw68: Fix null-ptr-deref bug in buf prepare and finish<br /> <br /> When the driver calls tw68_risc_buffer() to prepare the buffer, the<br /> function call dma_alloc_coherent may fail, resulting in a empty buffer<br /> buf-&gt;cpu. Later when we free the buffer or access the buffer, null ptr<br /> deref is triggered.<br /> <br /> This bug is similar to the following one:<br /> https://git.linuxtv.org/media_stage.git/commit/?id=2b064d91440b33fba5b452f2d1b31f13ae911d71.<br /> <br /> We believe the bug can be also dynamically triggered from user side.<br /> Similarly, we fix this by checking the return value of tw68_risc_buffer()<br /> and the value of buf-&gt;cpu before buffer free.