Vulnerabilidades

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> crypto: comp - Use same definition of context alloc and free ops<br /> <br /> In commit 42d9f6c77479 ("crypto: acomp - Move scomp stream allocation<br /> code into acomp"), the crypto_acomp_streams struct was made to rely on<br /> having the alloc_ctx and free_ctx operations defined in the same order<br /> as the scomp_alg struct. But in that same commit, the alloc_ctx and<br /> free_ctx members of scomp_alg may be randomized by structure layout<br /> randomization, since they are contained in a pure ops structure<br /> (containing only function pointers). If the pointers within scomp_alg<br /> are randomized, but those in crypto_acomp_streams are not, then<br /> the order may no longer match. This fixes the problem by removing the<br /> union from scomp_alg so that both crypto_acomp_streams and scomp_alg<br /> will share the same definition of alloc_ctx and free_ctx, ensuring<br /> they will always have the same layout.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> smc: Fix use-after-free in __pnet_find_base_ndev().<br /> <br /> syzbot reported use-after-free of net_device in __pnet_find_base_ndev(),<br /> which was called during connect(). [0]<br /> <br /> smc_pnet_find_ism_resource() fetches sk_dst_get(sk)-&gt;dev and passes<br /> down to pnet_find_base_ndev(), where RTNL is held. Then, UAF happened<br /> at __pnet_find_base_ndev() when the dev is first used.<br /> <br /> This means dev had already been freed before acquiring RTNL in<br /> pnet_find_base_ndev().<br /> <br /> While dev is going away, dst-&gt;dev could be swapped with blackhole_netdev,<br /> and the dev&amp;#39;s refcnt by dst will be released.<br /> <br /> We must hold dev&amp;#39;s refcnt before calling smc_pnet_find_ism_resource().<br /> <br /> Also, smc_pnet_find_roce_resource() has the same problem.<br /> <br /> Let&amp;#39;s use __sk_dst_get() and dst_dev_rcu() in the two functions.<br /> <br /> [0]:<br /> BUG: KASAN: use-after-free in __pnet_find_base_ndev+0x1b1/0x1c0 net/smc/smc_pnet.c:926<br /> Read of size 1 at addr ffff888036bac33a by task syz.0.3632/18609<br /> <br /> CPU: 1 UID: 0 PID: 18609 Comm: syz.0.3632 Not tainted syzkaller #0 PREEMPT(full)<br /> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 08/18/2025<br /> Call Trace:<br /> <br /> dump_stack_lvl+0x189/0x250 lib/dump_stack.c:120<br /> print_address_description mm/kasan/report.c:378 [inline]<br /> print_report+0xca/0x240 mm/kasan/report.c:482<br /> kasan_report+0x118/0x150 mm/kasan/report.c:595<br /> __pnet_find_base_ndev+0x1b1/0x1c0 net/smc/smc_pnet.c:926<br /> pnet_find_base_ndev net/smc/smc_pnet.c:946 [inline]<br /> smc_pnet_find_ism_by_pnetid net/smc/smc_pnet.c:1103 [inline]<br /> smc_pnet_find_ism_resource+0xef/0x390 net/smc/smc_pnet.c:1154<br /> smc_find_ism_device net/smc/af_smc.c:1030 [inline]<br /> smc_find_proposal_devices net/smc/af_smc.c:1115 [inline]<br /> __smc_connect+0x372/0x1890 net/smc/af_smc.c:1545<br /> smc_connect+0x877/0xd90 net/smc/af_smc.c:1715<br /> __sys_connect_file net/socket.c:2086 [inline]<br /> __sys_connect+0x313/0x440 net/socket.c:2105<br /> __do_sys_connect net/socket.c:2111 [inline]<br /> __se_sys_connect net/socket.c:2108 [inline]<br /> __x64_sys_connect+0x7a/0x90 net/socket.c:2108<br /> do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]<br /> do_syscall_64+0xfa/0x3b0 arch/x86/entry/syscall_64.c:94<br /> entry_SYSCALL_64_after_hwframe+0x77/0x7f<br /> RIP: 0033:0x7f47cbf8eba9<br /> Code: ff ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 3d 01 f0 ff ff 73 01 c3 48 c7 c1 a8 ff ff ff f7 d8 64 89 01 48<br /> RSP: 002b:00007f47ccdb1038 EFLAGS: 00000246 ORIG_RAX: 000000000000002a<br /> RAX: ffffffffffffffda RBX: 00007f47cc1d5fa0 RCX: 00007f47cbf8eba9<br /> RDX: 0000000000000010 RSI: 0000200000000280 RDI: 000000000000000b<br /> RBP: 00007f47cc011e19 R08: 0000000000000000 R09: 0000000000000000<br /> R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000<br /> R13: 00007f47cc1d6038 R14: 00007f47cc1d5fa0 R15: 00007ffc512f8aa8<br /> <br /> <br /> The buggy address belongs to the physical page:<br /> page: refcount:0 mapcount:0 mapping:0000000000000000 index:0xffff888036bacd00 pfn:0x36bac<br /> flags: 0xfff00000000000(node=0|zone=1|lastcpupid=0x7ff)<br /> raw: 00fff00000000000 ffffea0001243d08 ffff8880b863fdc0 0000000000000000<br /> raw: ffff888036bacd00 0000000000000000 00000000ffffffff 0000000000000000<br /> page dumped because: kasan: bad access detected<br /> page_owner tracks the page as freed<br /> page last allocated via order 2, migratetype Unmovable, gfp_mask 0x446dc0(GFP_KERNEL_ACCOUNT|__GFP_ZERO|__GFP_NOWARN|__GFP_RETRY_MAYFAIL|__GFP_COMP), pid 16741, tgid 16741 (syz-executor), ts 343313197788, free_ts 380670750466<br /> set_page_owner include/linux/page_owner.h:32 [inline]<br /> post_alloc_hook+0x240/0x2a0 mm/page_alloc.c:1851<br /> prep_new_page mm/page_alloc.c:1859 [inline]<br /> get_page_from_freelist+0x21e4/0x22c0 mm/page_alloc.c:3858<br /> __alloc_frozen_pages_noprof+0x181/0x370 mm/page_alloc.c:5148<br /> alloc_pages_mpol+0x232/0x4a0 mm/mempolicy.c:2416<br /> ___kmalloc_large_node+0x5f/0x1b0 mm/slub.c:4317<br /> __kmalloc_large_node_noprof+0x18/0x90 mm/slub.c:4348<br /> __do_kmalloc_node mm/slub.c:4364 [inline]<br /> __kvmalloc_node<br /> ---truncated---

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> RISC-V: KVM: Write hgatp register with valid mode bits<br /> <br /> According to the RISC-V Privileged Architecture Spec, when MODE=Bare<br /> is selected,software must write zero to the remaining fields of hgatp.<br /> <br /> We have detected the valid mode supported by the HW before, So using a<br /> valid mode to detect how many vmid bits are supported.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> Squashfs: fix uninit-value in squashfs_get_parent<br /> <br /> Syzkaller reports a "KMSAN: uninit-value in squashfs_get_parent" bug.<br /> <br /> This is caused by open_by_handle_at() being called with a file handle<br /> containing an invalid parent inode number. In particular the inode number<br /> is that of a symbolic link, rather than a directory.<br /> <br /> Squashfs_get_parent() gets called with that symbolic link inode, and<br /> accesses the parent member field.<br /> <br /> unsigned int parent_ino = squashfs_i(inode)-&gt;parent;<br /> <br /> Because non-directory inodes in Squashfs do not have a parent value, this<br /> is uninitialised, and this causes an uninitialised value access.<br /> <br /> The fix is to initialise parent with the invalid inode 0, which will cause<br /> an EINVAL error to be returned.<br /> <br /> Regular inodes used to share the parent field with the block_list_start<br /> field. This is removed in this commit to enable the parent field to<br /> contain the invalid inode number 0.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> bpf: Skip scalar adjustment for BPF_NEG if dst is a pointer<br /> <br /> In check_alu_op(), the verifier currently calls check_reg_arg() and<br /> adjust_scalar_min_max_vals() unconditionally for BPF_NEG operations.<br /> However, if the destination register holds a pointer, these scalar<br /> adjustments are unnecessary and potentially incorrect.<br /> <br /> This patch adds a check to skip the adjustment logic when the destination<br /> register contains a pointer.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> vhost: vringh: Modify the return value check<br /> <br /> The return value of copy_from_iter and copy_to_iter can&amp;#39;t be negative,<br /> check whether the copied lengths are equal.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> smb: client: fix crypto buffers in non-linear memory<br /> <br /> The crypto API, through the scatterlist API, expects input buffers to be<br /> in linear memory. We handle this with the cifs_sg_set_buf() helper<br /> that converts vmalloc&amp;#39;d memory to their corresponding pages.<br /> <br /> However, when we allocate our aead_request buffer (@creq in<br /> smb2ops.c::crypt_message()), we do so with kvzalloc(), which possibly<br /> puts aead_request-&gt;__ctx in vmalloc area.<br /> <br /> AEAD algorithm then uses -&gt;__ctx for its private/internal data and<br /> operations, and uses sg_set_buf() for such data on a few places.<br /> <br /> This works fine as long as @creq falls into kmalloc zone (small<br /> requests) or vmalloc&amp;#39;d memory is still within linear range.<br /> <br /> Tasks&amp;#39; stacks are vmalloc&amp;#39;d by default (CONFIG_VMAP_STACK=y), so too<br /> many tasks will increment the base stacks&amp;#39; addresses to a point where<br /> virt_addr_valid(buf) will fail (BUG() in sg_set_buf()) when that<br /> happens.<br /> <br /> In practice: too many parallel reads and writes on an encrypted mount<br /> will trigger this bug.<br /> <br /> To fix this, always alloc @creq with kmalloc() instead.<br /> Also drop the @sensitive_size variable/arguments since<br /> kfree_sensitive() doesn&amp;#39;t need it.<br /> <br /> Backtrace:<br /> <br /> [ 945.272081] ------------[ cut here ]------------<br /> [ 945.272774] kernel BUG at include/linux/scatterlist.h:209!<br /> [ 945.273520] Oops: invalid opcode: 0000 [#1] SMP DEBUG_PAGEALLOC NOPTI<br /> [ 945.274412] CPU: 7 UID: 0 PID: 56 Comm: kworker/u33:0 Kdump: loaded Not tainted 6.15.0-lku-11779-g8e9d6efccdd7-dirty #1 PREEMPT(voluntary)<br /> [ 945.275736] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.16.3-2-gc13ff2cd-prebuilt.qemu.org 04/01/2014<br /> [ 945.276877] Workqueue: writeback wb_workfn (flush-cifs-2)<br /> [ 945.277457] RIP: 0010:crypto_gcm_init_common+0x1f9/0x220<br /> [ 945.278018] Code: b0 00 00 00 48 83 c4 08 5b 5d 41 5c 41 5d 41 5e 41 5f c3 cc cc cc cc 48 c7 c0 00 00 00 80 48 2b 05 5c 58 e5 00 e9 58 ff ff ff 0b 0f 0b 0f 0b 0f 0b 0f 0b 0f 0b 48 c7 04 24 01 00 00 00 48 8b<br /> [ 945.279992] RSP: 0018:ffffc90000a27360 EFLAGS: 00010246<br /> [ 945.280578] RAX: 0000000000000000 RBX: ffffc90001d85060 RCX: 0000000000000030<br /> [ 945.281376] RDX: 0000000000080000 RSI: 0000000000000000 RDI: ffffc90081d85070<br /> [ 945.282145] RBP: ffffc90001d85010 R08: ffffc90001d85000 R09: 0000000000000000<br /> [ 945.282898] R10: ffffc90001d85090 R11: 0000000000001000 R12: ffffc90001d85070<br /> [ 945.283656] R13: ffff888113522948 R14: ffffc90001d85060 R15: ffffc90001d85010<br /> [ 945.284407] FS: 0000000000000000(0000) GS:ffff8882e66cf000(0000) knlGS:0000000000000000<br /> [ 945.285262] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> [ 945.285884] CR2: 00007fa7ffdd31f4 CR3: 000000010540d000 CR4: 0000000000350ef0<br /> [ 945.286683] Call Trace:<br /> [ 945.286952] <br /> [ 945.287184] ? crypt_message+0x33f/0xad0 [cifs]<br /> [ 945.287719] crypto_gcm_encrypt+0x36/0xe0<br /> [ 945.288152] crypt_message+0x54a/0xad0 [cifs]<br /> [ 945.288724] smb3_init_transform_rq+0x277/0x300 [cifs]<br /> [ 945.289300] smb_send_rqst+0xa3/0x160 [cifs]<br /> [ 945.289944] cifs_call_async+0x178/0x340 [cifs]<br /> [ 945.290514] ? __pfx_smb2_writev_callback+0x10/0x10 [cifs]<br /> [ 945.291177] smb2_async_writev+0x3e3/0x670 [cifs]<br /> [ 945.291759] ? find_held_lock+0x32/0x90<br /> [ 945.292212] ? netfs_advance_write+0xf2/0x310<br /> [ 945.292723] netfs_advance_write+0xf2/0x310<br /> [ 945.293210] netfs_write_folio+0x346/0xcc0<br /> [ 945.293689] ? __pfx__raw_spin_unlock_irq+0x10/0x10<br /> [ 945.294250] netfs_writepages+0x117/0x460<br /> [ 945.294724] do_writepages+0xbe/0x170<br /> [ 945.295152] ? find_held_lock+0x32/0x90<br /> [ 945.295600] ? kvm_sched_clock_read+0x11/0x20<br /> [ 945.296103] __writeback_single_inode+0x56/0x4b0<br /> [ 945.296643] writeback_sb_inodes+0x229/0x550<br /> [ 945.297140] __writeback_inodes_wb+0x4c/0xe0<br /> [ 945.297642] wb_writeback+0x2f1/0x3f0<br /> [ 945.298069] wb_workfn+0x300/0x490<br /> [ 945.298472] process_one_work+0x1fe/0x590<br /> [ 945.298949] worker_thread+0x1ce/0x3c0<br /> [ 945.299397] ? __pfx_worker_thread+0x10/0x10<br /> [ 945.299900] kthr<br /> ---truncated---

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: dlink: handle copy_thresh allocation failure<br /> <br /> The driver did not handle failure of `netdev_alloc_skb_ip_align()`.<br /> If the allocation failed, dereferencing `skb-&gt;protocol` could lead to<br /> a NULL pointer dereference.<br /> <br /> This patch tries to allocate `skb`. If the allocation fails, it falls<br /> back to the normal path.<br /> <br /> Tested-on: D-Link DGE-550T Rev-A3

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> f2fs: fix UAF issue in f2fs_merge_page_bio()<br /> <br /> As JY reported in bugzilla [1],<br /> <br /> Unable to handle kernel NULL pointer dereference at virtual address 0000000000000000<br /> pc : [0xffffffe51d249484] f2fs_is_cp_guaranteed+0x70/0x98<br /> lr : [0xffffffe51d24adbc] f2fs_merge_page_bio+0x520/0x6d4<br /> CPU: 3 UID: 0 PID: 6790 Comm: kworker/u16:3 Tainted: P B W OE 6.12.30-android16-5-maybe-dirty-4k #1 5f7701c9cbf727d1eebe77c89bbbeb3371e895e5<br /> Tainted: [P]=PROPRIETARY_MODULE, [B]=BAD_PAGE, [W]=WARN, [O]=OOT_MODULE, [E]=UNSIGNED_MODULE<br /> Workqueue: writeback wb_workfn (flush-254:49)<br /> Call trace:<br /> f2fs_is_cp_guaranteed+0x70/0x98<br /> f2fs_inplace_write_data+0x174/0x2f4<br /> f2fs_do_write_data_page+0x214/0x81c<br /> f2fs_write_single_data_page+0x28c/0x764<br /> f2fs_write_data_pages+0x78c/0xce4<br /> do_writepages+0xe8/0x2fc<br /> __writeback_single_inode+0x4c/0x4b4<br /> writeback_sb_inodes+0x314/0x540<br /> __writeback_inodes_wb+0xa4/0xf4<br /> wb_writeback+0x160/0x448<br /> wb_workfn+0x2f0/0x5dc<br /> process_scheduled_works+0x1c8/0x458<br /> worker_thread+0x334/0x3f0<br /> kthread+0x118/0x1ac<br /> ret_from_fork+0x10/0x20<br /> <br /> [1] https://bugzilla.kernel.org/show_bug.cgi?id=220575<br /> <br /> The panic was caused by UAF issue w/ below race condition:<br /> <br /> kworker<br /> - writepages<br /> - f2fs_write_cache_pages<br /> - f2fs_write_single_data_page<br /> - f2fs_do_write_data_page<br /> - f2fs_inplace_write_data<br /> - f2fs_merge_page_bio<br /> - add_inu_page<br /> : cache page #1 into bio &amp; cache bio in<br /> io-&gt;bio_list<br /> - f2fs_write_single_data_page<br /> - f2fs_do_write_data_page<br /> - f2fs_inplace_write_data<br /> - f2fs_merge_page_bio<br /> - add_inu_page<br /> : cache page #2 into bio which is linked<br /> in io-&gt;bio_list<br /> write<br /> - f2fs_write_begin<br /> : write page #1<br /> - f2fs_folio_wait_writeback<br /> - f2fs_submit_merged_ipu_write<br /> - f2fs_submit_write_bio<br /> : submit bio which inclues page #1 and #2<br /> <br /> software IRQ<br /> - f2fs_write_end_io<br /> - fscrypt_free_bounce_page<br /> : freed bounced page which belongs to page #2<br /> - inc_page_count( , WB_DATA_TYPE(data_folio), false)<br /> : data_folio points to fio-&gt;encrypted_page<br /> the bounced page can be freed before<br /> accessing it in f2fs_is_cp_guarantee()<br /> <br /> It can reproduce w/ below testcase:<br /> Run below script in shell #1:<br /> for ((i=1;i&gt;0;i++)) do xfs_io -f /mnt/f2fs/enc/file \<br /> -c "pwrite 0 32k" -c "fdatasync"<br /> <br /> Run below script in shell #2:<br /> for ((i=1;i&gt;0;i++)) do xfs_io -f /mnt/f2fs/enc/file \<br /> -c "pwrite 0 32k" -c "fdatasync"<br /> <br /> So, in f2fs_merge_page_bio(), let&amp;#39;s avoid using fio-&gt;encrypted_page after<br /> commit page into internal ipu cache.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ocfs2: fix double free in user_cluster_connect()<br /> <br /> user_cluster_disconnect() frees "conn-&gt;cc_private" which is "lc" but then<br /> the error handling frees "lc" a second time. Set "lc" to NULL on this<br /> path to avoid a double free.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> vhost: vringh: Fix copy_to_iter return value check<br /> <br /> The return value of copy_to_iter can&amp;#39;t be negative, check whether the<br /> copied length is equal to the requested length instead of checking for<br /> negative values.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> LoongArch: BPF: Sign-extend struct ops return values properly<br /> <br /> The ns_bpf_qdisc selftest triggers a kernel panic:<br /> <br /> Oops[#1]:<br /> CPU 0 Unable to handle kernel paging request at virtual address 0000000000741d58, era == 90000000851b5ac0, ra == 90000000851b5aa4<br /> CPU: 0 UID: 0 PID: 449 Comm: test_progs Tainted: G OE 6.16.0+ #3 PREEMPT(full)<br /> Tainted: [O]=OOT_MODULE, [E]=UNSIGNED_MODULE<br /> Hardware name: QEMU QEMU Virtual Machine, BIOS unknown 2/2/2022<br /> pc 90000000851b5ac0 ra 90000000851b5aa4 tp 90000001076b8000 sp 90000001076bb600<br /> a0 0000000000741ce8 a1 0000000000000001 a2 90000001076bb5c0 a3 0000000000000008<br /> a4 90000001004c4620 a5 9000000100741ce8 a6 0000000000000000 a7 0100000000000000<br /> t0 0000000000000010 t1 0000000000000000 t2 9000000104d24d30 t3 0000000000000001<br /> t4 4f2317da8a7e08c4 t5 fffffefffc002f00 t6 90000001004c4620 t7 ffffffffc61c5b3d<br /> t8 0000000000000000 u0 0000000000000001 s9 0000000000000050 s0 90000001075bc800<br /> s1 0000000000000040 s2 900000010597c400 s3 0000000000000008 s4 90000001075bc880<br /> s5 90000001075bc8f0 s6 0000000000000000 s7 0000000000741ce8 s8 0000000000000000<br /> ra: 90000000851b5aa4 __qdisc_run+0xac/0x8d8<br /> ERA: 90000000851b5ac0 __qdisc_run+0xc8/0x8d8<br /> CRMD: 000000b0 (PLV0 -IE -DA +PG DACF=CC DACM=CC -WE)<br /> PRMD: 00000004 (PPLV0 +PIE -PWE)<br /> EUEN: 00000007 (+FPE +SXE +ASXE -BTE)<br /> ECFG: 00071c1d (LIE=0,2-4,10-12 VS=7)<br /> ESTAT: 00010000 [PIL] (IS= ECode=1 EsubCode=0)<br /> BADV: 0000000000741d58<br /> PRID: 0014c010 (Loongson-64bit, Loongson-3A5000)<br /> Modules linked in: bpf_testmod(OE) [last unloaded: bpf_testmod(OE)]<br /> Process test_progs (pid: 449, threadinfo=000000009af02b3a, task=00000000e9ba4956)<br /> Stack : 0000000000000000 90000001075bc8ac 90000000869524a8 9000000100741ce8<br /> 90000001075bc800 9000000100415300 90000001075bc8ac 0000000000000000<br /> 900000010597c400 900000008694a000 0000000000000000 9000000105b59000<br /> 90000001075bc800 9000000100741ce8 0000000000000050 900000008513000c<br /> 9000000086936000 0000000100094d4c fffffff400676208 0000000000000000<br /> 9000000105b59000 900000008694a000 9000000086bf0dc0 9000000105b59000<br /> 9000000086bf0d68 9000000085147010 90000001075be788 0000000000000000<br /> 9000000086bf0f98 0000000000000001 0000000000000010 9000000006015840<br /> 0000000000000000 9000000086be6c40 0000000000000000 0000000000000000<br /> 0000000000000000 4f2317da8a7e08c4 0000000000000101 4f2317da8a7e08c4<br /> ...<br /> Call Trace:<br /> [] __qdisc_run+0xc8/0x8d8<br /> [] __dev_queue_xmit+0x578/0x10f0<br /> [] ip6_finish_output2+0x2f0/0x950<br /> [] ip6_finish_output+0x2b8/0x448<br /> [] ip6_xmit+0x304/0x858<br /> [] inet6_csk_xmit+0x100/0x170<br /> [] __tcp_transmit_skb+0x490/0xdd0<br /> [] tcp_connect+0xbcc/0x1168<br /> [] tcp_v6_connect+0x580/0x8a0<br /> [] __inet_stream_connect+0x170/0x480<br /> [] inet_stream_connect+0x50/0x88<br /> [] __sys_connect+0xe4/0x110<br /> [] sys_connect+0x18/0x28<br /> [] do_syscall+0x94/0x1a0<br /> [] handle_syscall+0xb8/0x158<br /> <br /> Code: 4001ad80 2400873f 2400832d 001137ff 001133ff 6407b41f 001503cc 0280041d<br /> <br /> ---[ end trace 0000000000000000 ]---<br /> <br /> The bpf_fifo_dequeue prog returns a skb which is a pointer. The pointer<br /> is treated as a 32bit value and sign extend to 64bit in epilogue. This<br /> behavior is right for most bpf prog types but wrong for struct ops which<br /> requires LoongArch ABI.<br /> <br /> So let&amp;#39;s sign extend struct ops return values according to the LoongArch<br /> ABI ([1]) and return value spec in function model.<br /> <br /> [1]: https://loongson.github.io/LoongArch-Documentation/LoongArch-ELF-ABI-EN.html