Vulnerabilidades

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> Drivers: hv: vmbus: Don&amp;#39;t dereference ACPI root object handle<br /> <br /> Since the commit referenced in the Fixes: tag below the VMBus client driver<br /> is walking the ACPI namespace up from the VMBus ACPI device to the ACPI<br /> namespace root object trying to find Hyper-V MMIO ranges.<br /> <br /> However, if it is not able to find them it ends trying to walk resources of<br /> the ACPI namespace root object itself.<br /> This object has all-ones handle, which causes a NULL pointer dereference<br /> in the ACPI code (from dereferencing this pointer with an offset).<br /> <br /> This in turn causes an oops on boot with VMBus host implementations that do<br /> not provide Hyper-V MMIO ranges in their VMBus ACPI device or its<br /> ancestors.<br /> The QEMU VMBus implementation is an example of such implementation.<br /> <br /> I guess providing these ranges is optional, since all tested Windows<br /> versions seem to be able to use VMBus devices without them.<br /> <br /> Fix this by explicitly terminating the lookup at the ACPI namespace root<br /> object.<br /> <br /> Note that Linux guests under KVM/QEMU do not use the Hyper-V PV interface<br /> by default - they only do so if the KVM PV interface is missing or<br /> disabled.<br /> <br /> Example stack trace of such oops:<br /> [ 3.710827] ? __die+0x1f/0x60<br /> [ 3.715030] ? page_fault_oops+0x159/0x460<br /> [ 3.716008] ? exc_page_fault+0x73/0x170<br /> [ 3.716959] ? asm_exc_page_fault+0x22/0x30<br /> [ 3.717957] ? acpi_ns_lookup+0x7a/0x4b0<br /> [ 3.718898] ? acpi_ns_internalize_name+0x79/0xc0<br /> [ 3.720018] acpi_ns_get_node_unlocked+0xb5/0xe0<br /> [ 3.721120] ? acpi_ns_check_object_type+0xfe/0x200<br /> [ 3.722285] ? acpi_rs_convert_aml_to_resource+0x37/0x6e0<br /> [ 3.723559] ? down_timeout+0x3a/0x60<br /> [ 3.724455] ? acpi_ns_get_node+0x3a/0x60<br /> [ 3.725412] acpi_ns_get_node+0x3a/0x60<br /> [ 3.726335] acpi_ns_evaluate+0x1c3/0x2c0<br /> [ 3.727295] acpi_ut_evaluate_object+0x64/0x1b0<br /> [ 3.728400] acpi_rs_get_method_data+0x2b/0x70<br /> [ 3.729476] ? vmbus_platform_driver_probe+0x1d0/0x1d0 [hv_vmbus]<br /> [ 3.730940] ? vmbus_platform_driver_probe+0x1d0/0x1d0 [hv_vmbus]<br /> [ 3.732411] acpi_walk_resources+0x78/0xd0<br /> [ 3.733398] vmbus_platform_driver_probe+0x9f/0x1d0 [hv_vmbus]<br /> [ 3.734802] platform_probe+0x3d/0x90<br /> [ 3.735684] really_probe+0x19b/0x400<br /> [ 3.736570] ? __device_attach_driver+0x100/0x100<br /> [ 3.737697] __driver_probe_device+0x78/0x160<br /> [ 3.738746] driver_probe_device+0x1f/0x90<br /> [ 3.739743] __driver_attach+0xc2/0x1b0<br /> [ 3.740671] bus_for_each_dev+0x70/0xc0<br /> [ 3.741601] bus_add_driver+0x10e/0x210<br /> [ 3.742527] driver_register+0x55/0xf0<br /> [ 3.744412] ? 0xffffffffc039a000<br /> [ 3.745207] hv_acpi_init+0x3c/0x1000 [hv_vmbus]

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/i915/perf: add sentinel to xehp_oa_b_counters<br /> <br /> Arrays passed to reg_in_range_table should end with empty record.<br /> <br /> The patch solves KASAN detected bug with signature:<br /> BUG: KASAN: global-out-of-bounds in xehp_is_valid_b_counter_addr+0x2c7/0x350 [i915]<br /> Read of size 4 at addr ffffffffa1555d90 by task perf/1518<br /> <br /> CPU: 4 PID: 1518 Comm: perf Tainted: G U 6.4.0-kasan_438-g3303d06107f3+ #1<br /> Hardware name: Intel Corporation Meteor Lake Client Platform/MTL-P DDR5 SODIMM SBS RVP, BIOS MTLPFWI1.R00.3223.D80.2305311348 05/31/2023<br /> Call Trace:<br /> <br /> ...<br /> xehp_is_valid_b_counter_addr+0x2c7/0x350 [i915]<br /> <br /> (cherry picked from commit 2f42c5afb34b5696cf5fe79e744f99be9b218798)

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> bpf: Make bpf_refcount_acquire fallible for non-owning refs<br /> <br /> This patch fixes an incorrect assumption made in the original<br /> bpf_refcount series [0], specifically that the BPF program calling<br /> bpf_refcount_acquire on some node can always guarantee that the node is<br /> alive. In that series, the patch adding failure behavior to rbtree_add<br /> and list_push_{front, back} breaks this assumption for non-owning<br /> references.<br /> <br /> Consider the following program:<br /> <br /> n = bpf_kptr_xchg(&amp;mapval, NULL);<br /> /* skip error checking */<br /> <br /> bpf_spin_lock(&amp;l);<br /> if(bpf_rbtree_add(&amp;t, &amp;n-&gt;rb, less)) {<br /> bpf_refcount_acquire(n);<br /> /* Failed to add, do something else with the node */<br /> }<br /> bpf_spin_unlock(&amp;l);<br /> <br /> It&amp;#39;s incorrect to assume that bpf_refcount_acquire will always succeed in this<br /> scenario. bpf_refcount_acquire is being called in a critical section<br /> here, but the lock being held is associated with rbtree t, which isn&amp;#39;t<br /> necessarily the lock associated with the tree that the node is already<br /> in. So after bpf_rbtree_add fails to add the node and calls bpf_obj_drop<br /> in it, the program has no ownership of the node&amp;#39;s lifetime. Therefore<br /> the node&amp;#39;s refcount can be decr&amp;#39;d to 0 at any time after the failing<br /> rbtree_add. If this happens before the refcount_acquire above, the node<br /> might be free&amp;#39;d, and regardless refcount_acquire will be incrementing a<br /> 0 refcount.<br /> <br /> Later patches in the series exercise this scenario, resulting in the<br /> expected complaint from the kernel (without this patch&amp;#39;s changes):<br /> <br /> refcount_t: addition on 0; use-after-free.<br /> WARNING: CPU: 1 PID: 207 at lib/refcount.c:25 refcount_warn_saturate+0xbc/0x110<br /> Modules linked in: bpf_testmod(O)<br /> CPU: 1 PID: 207 Comm: test_progs Tainted: G O 6.3.0-rc7-02231-g723de1a718a2-dirty #371<br /> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.15.0-0-g2dd4b9b3f840-prebuilt.qemu.org 04/01/2014<br /> RIP: 0010:refcount_warn_saturate+0xbc/0x110<br /> Code: 6f 64 f6 02 01 e8 84 a3 5c ff 0f 0b eb 9d 80 3d 5e 64 f6 02 00 75 94 48 c7 c7 e0 13 d2 82 c6 05 4e 64 f6 02 01 e8 64 a3 5c ff 0b e9 7a ff ff ff 80 3d 38 64 f6 02 00 0f 85 6d ff ff ff 48 c7<br /> RSP: 0018:ffff88810b9179b0 EFLAGS: 00010082<br /> RAX: 0000000000000000 RBX: 0000000000000002 RCX: 0000000000000000<br /> RDX: 0000000000000202 RSI: 0000000000000008 RDI: ffffffff857c3680<br /> RBP: ffff88810027d3c0 R08: ffffffff8125f2a4 R09: ffff88810b9176e7<br /> R10: ffffed1021722edc R11: 746e756f63666572 R12: ffff88810027d388<br /> R13: ffff88810027d3c0 R14: ffffc900005fe030 R15: ffffc900005fe048<br /> FS: 00007fee0584a700(0000) GS:ffff88811b280000(0000) knlGS:0000000000000000<br /> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> CR2: 00005634a96f6c58 CR3: 0000000108ce9002 CR4: 0000000000770ee0<br /> DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000<br /> DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400<br /> PKRU: 55555554<br /> Call Trace:<br /> <br /> bpf_refcount_acquire_impl+0xb5/0xc0<br /> <br /> (rest of output snipped)<br /> <br /> The patch addresses this by changing bpf_refcount_acquire_impl to use<br /> refcount_inc_not_zero instead of refcount_inc and marking<br /> bpf_refcount_acquire KF_RET_NULL.<br /> <br /> For owning references, though, we know the above scenario is not possible<br /> and thus that bpf_refcount_acquire will always succeed. Some verifier<br /> bookkeeping is added to track "is input owning ref?" for bpf_refcount_acquire<br /> calls and return false from is_kfunc_ret_null for bpf_refcount_acquire on<br /> owning refs despite it being marked KF_RET_NULL.<br /> <br /> Existing selftests using bpf_refcount_acquire are modified where<br /> necessary to NULL-check its return value.<br /> <br /> [0]: https://lore.kernel.org/bpf/20230415201811.343116-1-davemarchevsky@fb.com/

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> media: radio-shark: Add endpoint checks<br /> <br /> The syzbot fuzzer was able to provoke a WARNING from the radio-shark2<br /> driver:<br /> <br /> ------------[ cut here ]------------<br /> usb 1-1: BOGUS urb xfer, pipe 1 != type 3<br /> WARNING: CPU: 0 PID: 3271 at drivers/usb/core/urb.c:504 usb_submit_urb+0xed2/0x1880 drivers/usb/core/urb.c:504<br /> Modules linked in:<br /> CPU: 0 PID: 3271 Comm: kworker/0:3 Not tainted 6.1.0-rc4-syzkaller #0<br /> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 10/26/2022<br /> Workqueue: usb_hub_wq hub_event<br /> RIP: 0010:usb_submit_urb+0xed2/0x1880 drivers/usb/core/urb.c:504<br /> Code: 7c 24 18 e8 00 36 ea fb 48 8b 7c 24 18 e8 36 1c 02 ff 41 89 d8 44 89 e1 4c 89 ea 48 89 c6 48 c7 c7 a0 b6 90 8a e8 9a 29 b8 03 0b e9 58 f8 ff ff e8 d2 35 ea fb 48 81 c5 c0 05 00 00 e9 84 f7<br /> RSP: 0018:ffffc90003876dd0 EFLAGS: 00010282<br /> RAX: 0000000000000000 RBX: 0000000000000003 RCX: 0000000000000000<br /> RDX: ffff8880750b0040 RSI: ffffffff816152b8 RDI: fffff5200070edac<br /> RBP: ffff8880172d81e0 R08: 0000000000000005 R09: 0000000000000000<br /> R10: 0000000080000000 R11: 0000000000000000 R12: 0000000000000001<br /> R13: ffff8880285c5040 R14: 0000000000000002 R15: ffff888017158200<br /> FS: 0000000000000000(0000) GS:ffff8880b9a00000(0000) knlGS:0000000000000000<br /> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> CR2: 00007ffe03235b90 CR3: 000000000bc8e000 CR4: 00000000003506f0<br /> DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000<br /> DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400<br /> Call Trace:<br /> <br /> usb_start_wait_urb+0x101/0x4b0 drivers/usb/core/message.c:58<br /> usb_bulk_msg+0x226/0x550 drivers/usb/core/message.c:387<br /> shark_write_reg+0x1ff/0x2e0 drivers/media/radio/radio-shark2.c:88<br /> ...<br /> <br /> The problem was caused by the fact that the driver does not check<br /> whether the endpoints it uses are actually present and have the<br /> appropriate types. This can be fixed by adding a simple check of<br /> these endpoints (and similarly for the radio-shark driver).

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> nvme-tcp: don&amp;#39;t access released socket during error recovery<br /> <br /> While the error recovery work is temporarily failing reconnect attempts,<br /> running the &amp;#39;nvme list&amp;#39; command causes a kernel NULL pointer dereference<br /> by calling getsockname() with a released socket.<br /> <br /> During error recovery work, the nvme tcp socket is released and a new one<br /> created, so it is not safe to access the socket without proper check.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> x86: fix clear_user_rep_good() exception handling annotation<br /> <br /> This code no longer exists in mainline, because it was removed in<br /> commit d2c95f9d6802 ("x86: don&amp;#39;t use REP_GOOD or ERMS for user memory<br /> clearing") upstream.<br /> <br /> However, rather than backport the full range of x86 memory clearing and<br /> copying cleanups, fix the exception table annotation placement for the<br /> final &amp;#39;rep movsb&amp;#39; in clear_user_rep_good(): rather than pointing at the<br /> actual instruction that did the user space access, it pointed to the<br /> register move just before it.<br /> <br /> That made sense from a code flow standpoint, but not from an actual<br /> usage standpoint: it means that if user access takes an exception, the<br /> exception handler won&amp;#39;t actually find the instruction in the exception<br /> tables.<br /> <br /> As a result, rather than fixing it up and returning -EFAULT, it would<br /> then turn it into a kernel oops report instead, something like:<br /> <br /> BUG: unable to handle page fault for address: 0000000020081000<br /> #PF: supervisor write access in kernel mode<br /> #PF: error_code(0x0002) - not-present page<br /> ...<br /> RIP: 0010:clear_user_rep_good+0x1c/0x30 arch/x86/lib/clear_page_64.S:147<br /> ...<br /> Call Trace:<br /> __clear_user arch/x86/include/asm/uaccess_64.h:103 [inline]<br /> clear_user arch/x86/include/asm/uaccess_64.h:124 [inline]<br /> iov_iter_zero+0x709/0x1290 lib/iov_iter.c:800<br /> iomap_dio_hole_iter fs/iomap/direct-io.c:389 [inline]<br /> iomap_dio_iter fs/iomap/direct-io.c:440 [inline]<br /> __iomap_dio_rw+0xe3d/0x1cd0 fs/iomap/direct-io.c:601<br /> iomap_dio_rw+0x40/0xa0 fs/iomap/direct-io.c:689<br /> ext4_dio_read_iter fs/ext4/file.c:94 [inline]<br /> ext4_file_read_iter+0x4be/0x690 fs/ext4/file.c:145<br /> call_read_iter include/linux/fs.h:2183 [inline]<br /> do_iter_readv_writev+0x2e0/0x3b0 fs/read_write.c:733<br /> do_iter_read+0x2f2/0x750 fs/read_write.c:796<br /> vfs_readv+0xe5/0x150 fs/read_write.c:916<br /> do_preadv+0x1b6/0x270 fs/read_write.c:1008<br /> __do_sys_preadv2 fs/read_write.c:1070 [inline]<br /> __se_sys_preadv2 fs/read_write.c:1061 [inline]<br /> __x64_sys_preadv2+0xef/0x150 fs/read_write.c:1061<br /> do_syscall_x64 arch/x86/entry/common.c:50 [inline]<br /> do_syscall_64+0x39/0xb0 arch/x86/entry/common.c:80<br /> entry_SYSCALL_64_after_hwframe+0x63/0xcd<br /> <br /> which then looks like a filesystem bug rather than the incorrect<br /> exception annotation that it is.<br /> <br /> [ The alternative to this one-liner fix is to take the upstream series<br /> that cleans this all up:<br /> <br /> 68674f94ffc9 ("x86: don&amp;#39;t use REP_GOOD or ERMS for small memory copies")<br /> 20f3337d350c ("x86: don&amp;#39;t use REP_GOOD or ERMS for small memory clearing")<br /> adfcf4231b8c ("x86: don&amp;#39;t use REP_GOOD or ERMS for user memory copies")<br /> * d2c95f9d6802 ("x86: don&amp;#39;t use REP_GOOD or ERMS for user memory clearing")<br /> 3639a535587d ("x86: move stac/clac from user copy routines into callers")<br /> 577e6a7fd50d ("x86: inline the &amp;#39;rep movs&amp;#39; in user copies for the FSRM case")<br /> 8c9b6a88b7e2 ("x86: improve on the non-rep &amp;#39;clear_user&amp;#39; function")<br /> 427fda2c8a49 ("x86: improve on the non-rep &amp;#39;copy_user&amp;#39; function")<br /> * e046fe5a36a9 ("x86: set FSRS automatically on AMD CPUs that have FSRM")<br /> e1f2750edc4a ("x86: remove &amp;#39;zerorest&amp;#39; argument from __copy_user_nocache()")<br /> 034ff37d3407 ("x86: rewrite &amp;#39;__copy_user_nocache&amp;#39; function")<br /> <br /> with either the whole series or at a minimum the two marked commits<br /> being needed to fix this issue ]

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> wifi: ath9k: hif_usb: fix memory leak of remain_skbs<br /> <br /> hif_dev-&gt;remain_skb is allocated and used exclusively in<br /> ath9k_hif_usb_rx_stream(). It is implied that an allocated remain_skb is<br /> processed and subsequently freed (in error paths) only during the next<br /> call of ath9k_hif_usb_rx_stream().<br /> <br /> So, if the urbs are deallocated between those two calls due to the device<br /> deinitialization or suspend, it is possible that ath9k_hif_usb_rx_stream()<br /> is not called next time and the allocated remain_skb is leaked. Our local<br /> Syzkaller instance was able to trigger that.<br /> <br /> remain_skb makes sense when receiving two consecutive urbs which are<br /> logically linked together, i.e. a specific data field from the first skb<br /> indicates a cached skb to be allocated, memcpy&amp;#39;d with some data and<br /> subsequently processed in the next call to ath9k_hif_usb_rx_stream(). Urbs<br /> deallocation supposedly makes that link irrelevant so we need to free the<br /> cached skb in those cases.<br /> <br /> Fix the leak by introducing a function to explicitly free remain_skb (if<br /> it is not NULL) when the rx urbs have been deallocated. remain_skb is NULL<br /> when it has not been allocated at all (hif_dev struct is kzalloced) or<br /> when it has been processed in next call to ath9k_hif_usb_rx_stream().<br /> <br /> Found by Linux Verification Center (linuxtesting.org) with Syzkaller.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ASoC: lpass: Fix for KASAN use_after_free out of bounds<br /> <br /> When we run syzkaller we get below Out of Bounds error.<br /> <br /> "KASAN: slab-out-of-bounds Read in regcache_flat_read"<br /> <br /> Below is the backtrace of the issue:<br /> <br /> BUG: KASAN: slab-out-of-bounds in regcache_flat_read+0x10c/0x110<br /> Read of size 4 at addr ffffff8088fbf714 by task syz-executor.4/14144<br /> CPU: 6 PID: 14144 Comm: syz-executor.4 Tainted: G W<br /> Hardware name: Qualcomm Technologies, Inc. sc7280 CRD platform (rev5+) (DT)<br /> Call trace:<br /> dump_backtrace+0x0/0x4ec<br /> show_stack+0x34/0x50<br /> dump_stack_lvl+0xdc/0x11c<br /> print_address_description+0x30/0x2d8<br /> kasan_report+0x178/0x1e4<br /> __asan_report_load4_noabort+0x44/0x50<br /> regcache_flat_read+0x10c/0x110<br /> regcache_read+0xf8/0x5a0<br /> _regmap_read+0x45c/0x86c<br /> _regmap_update_bits+0x128/0x290<br /> regmap_update_bits_base+0xc0/0x15c<br /> snd_soc_component_update_bits+0xa8/0x22c<br /> snd_soc_component_write_field+0x68/0xd4<br /> tx_macro_put_dec_enum+0x1d0/0x268<br /> snd_ctl_elem_write+0x288/0x474<br /> <br /> By Error checking and checking valid values issue gets rectifies.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> wifi: ath6kl: reduce WARN to dev_dbg() in callback<br /> <br /> The warn is triggered on a known race condition, documented in the code above<br /> the test, that is correctly handled. Using WARN() hinders automated testing.<br /> Reducing severity.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> octeon_ep: cancel queued works in probe error path<br /> <br /> If it fails to get the devices&amp;#39;s MAC address, octep_probe exits while<br /> leaving the delayed work intr_poll_task queued. When the work later<br /> runs, it&amp;#39;s a use after free.<br /> <br /> Move the cancelation of intr_poll_task from octep_remove into<br /> octep_device_cleanup. This does not change anything in the octep_remove<br /> flow, but octep_device_cleanup is called also in the octep_probe error<br /> path, where the cancelation is needed.<br /> <br /> Note that the cancelation of ctrl_mbox_task has to follow<br /> intr_poll_task&amp;#39;s, because the ctrl_mbox_task may be queued by<br /> intr_poll_task.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> netfilter: conntrack: fix wrong ct-&gt;timeout value<br /> <br /> (struct nf_conn)-&gt;timeout is an interval before the conntrack<br /> confirmed. After confirmed, it becomes a timestamp.<br /> <br /> It is observed that timeout of an unconfirmed conntrack:<br /> - Set by calling ctnetlink_change_timeout(). As a result,<br /> `nfct_time_stamp` was wrongly added to `ct-&gt;timeout` twice.<br /> - Get by calling ctnetlink_dump_timeout(). As a result,<br /> `nfct_time_stamp` was wrongly subtracted.<br /> <br /> Call Trace:<br /> <br /> dump_stack_lvl<br /> ctnetlink_dump_timeout<br /> __ctnetlink_glue_build<br /> ctnetlink_glue_build<br /> __nfqnl_enqueue_packet<br /> nf_queue<br /> nf_hook_slow<br /> ip_mc_output<br /> ? __pfx_ip_finish_output<br /> ip_send_skb<br /> ? __pfx_dst_output<br /> udp_send_skb<br /> udp_sendmsg<br /> ? __pfx_ip_generic_getfrag<br /> sock_sendmsg<br /> <br /> Separate the 2 cases in:<br /> - Setting `ct-&gt;timeout` in __nf_ct_set_timeout().<br /> - Getting `ct-&gt;timeout` in ctnetlink_dump_timeout().<br /> <br /> Pablo appends:<br /> <br /> Update ctnetlink to set up the timeout _after_ the IPS_CONFIRMED flag is<br /> set on, otherwise conntrack creation via ctnetlink breaks.<br /> <br /> Note that the problem described in this patch occurs since the<br /> introduction of the nfnetlink_queue conntrack support, select a<br /> sufficiently old Fixes: tag for -stable kernel to pick up this fix.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> bpf, arm64: Fixed a BTI error on returning to patched function<br /> <br /> When BPF_TRAMP_F_CALL_ORIG is set, BPF trampoline uses BLR to jump<br /> back to the instruction next to call site to call the patched function.<br /> For BTI-enabled kernel, the instruction next to call site is usually<br /> PACIASP, in this case, it&amp;#39;s safe to jump back with BLR. But when<br /> the call site is not followed by a PACIASP or bti, a BTI exception<br /> is triggered.<br /> <br /> Here is a fault log:<br /> <br /> Unhandled 64-bit el1h sync exception on CPU0, ESR 0x0000000034000002 -- BTI<br /> CPU: 0 PID: 263 Comm: test_progs Tainted: GF<br /> Hardware name: linux,dummy-virt (DT)<br /> pstate: 40400805 (nZcv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=-c)<br /> pc : bpf_fentry_test1+0xc/0x30<br /> lr : bpf_trampoline_6442573892_0+0x48/0x1000<br /> sp : ffff80000c0c3a50<br /> x29: ffff80000c0c3a90 x28: ffff0000c2e6c080 x27: 0000000000000000<br /> x26: 0000000000000000 x25: 0000000000000000 x24: 0000000000000050<br /> x23: 0000000000000000 x22: 0000ffffcfd2a7f0 x21: 000000000000000a<br /> x20: 0000ffffcfd2a7f0 x19: 0000000000000000 x18: 0000000000000000<br /> x17: 0000000000000000 x16: 0000000000000000 x15: 0000ffffcfd2a7f0<br /> x14: 0000000000000000 x13: 0000000000000000 x12: 0000000000000000<br /> x11: 0000000000000000 x10: ffff80000914f5e4 x9 : ffff8000082a1528<br /> x8 : 0000000000000000 x7 : 0000000000000000 x6 : 0101010101010101<br /> x5 : 0000000000000000 x4 : 00000000fffffff2 x3 : 0000000000000001<br /> x2 : ffff8001f4b82000 x1 : 0000000000000000 x0 : 0000000000000001<br /> Kernel panic - not syncing: Unhandled exception<br /> CPU: 0 PID: 263 Comm: test_progs Tainted: GF<br /> Hardware name: linux,dummy-virt (DT)<br /> Call trace:<br /> dump_backtrace+0xec/0x144<br /> show_stack+0x24/0x7c<br /> dump_stack_lvl+0x8c/0xb8<br /> dump_stack+0x18/0x34<br /> panic+0x1cc/0x3ec<br /> __el0_error_handler_common+0x0/0x130<br /> el1h_64_sync_handler+0x60/0xd0<br /> el1h_64_sync+0x78/0x7c<br /> bpf_fentry_test1+0xc/0x30<br /> bpf_fentry_test1+0xc/0x30<br /> bpf_prog_test_run_tracing+0xdc/0x2a0<br /> __sys_bpf+0x438/0x22a0<br /> __arm64_sys_bpf+0x30/0x54<br /> invoke_syscall+0x78/0x110<br /> el0_svc_common.constprop.0+0x6c/0x1d0<br /> do_el0_svc+0x38/0xe0<br /> el0_svc+0x30/0xd0<br /> el0t_64_sync_handler+0x1ac/0x1b0<br /> el0t_64_sync+0x1a0/0x1a4<br /> Kernel Offset: disabled<br /> CPU features: 0x0000,00034c24,f994fdab<br /> Memory Limit: none<br /> <br /> And the instruction next to call site of bpf_fentry_test1 is ADD,<br /> not PACIASP:<br /> <br /> :<br /> bti c<br /> nop<br /> nop<br /> add w0, w0, #0x1<br /> paciasp<br /> <br /> For BPF prog, JIT always puts a PACIASP after call site for BTI-enabled<br /> kernel, so there is no problem. To fix it, replace BLR with RET to bypass<br /> the branch target check.