Vulnerabilidades

*** Pendiente de traducción *** Rejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/ttm: Don&amp;#39;t leak a resource on eviction error<br /> <br /> On eviction errors other than -EMULTIHOP we were leaking a resource.<br /> Fix.<br /> <br /> v2:<br /> - Avoid yet another goto (Andi Shyti)

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> sh: dma: Fix DMA channel offset calculation<br /> <br /> Various SoCs of the SH3, SH4 and SH4A family, which use this driver,<br /> feature a differing number of DMA channels, which can be distributed<br /> between up to two DMAC modules. The existing implementation fails to<br /> correctly accommodate for all those variations, resulting in wrong<br /> channel offset calculations and leading to kernel panics.<br /> <br /> Rewrite dma_base_addr() in order to properly calculate channel offsets<br /> in a DMAC module. Fix dmaor_read_reg() and dmaor_write_reg(), so that<br /> the correct DMAC module base is selected for the DMAOR register.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: macb: fix a memory corruption in extended buffer descriptor mode<br /> <br /> For quite some time we were chasing a bug which looked like a sudden<br /> permanent failure of networking and mmc on some of our devices.<br /> The bug was very sensitive to any software changes and even more to<br /> any kernel debug options.<br /> <br /> Finally we got a setup where the problem was reproducible with<br /> CONFIG_DMA_API_DEBUG=y and it revealed the issue with the rx dma:<br /> <br /> [ 16.992082] ------------[ cut here ]------------<br /> [ 16.996779] DMA-API: macb ff0b0000.ethernet: device driver tries to free DMA memory it has not allocated [device address=0x0000000875e3e244] [size=1536 bytes]<br /> [ 17.011049] WARNING: CPU: 0 PID: 85 at kernel/dma/debug.c:1011 check_unmap+0x6a0/0x900<br /> [ 17.018977] Modules linked in: xxxxx<br /> [ 17.038823] CPU: 0 PID: 85 Comm: irq/55-8000f000 Not tainted 5.4.0 #28<br /> [ 17.045345] Hardware name: xxxxx<br /> [ 17.049528] pstate: 60000005 (nZCv daif -PAN -UAO)<br /> [ 17.054322] pc : check_unmap+0x6a0/0x900<br /> [ 17.058243] lr : check_unmap+0x6a0/0x900<br /> [ 17.062163] sp : ffffffc010003c40<br /> [ 17.065470] x29: ffffffc010003c40 x28: 000000004000c03c<br /> [ 17.070783] x27: ffffffc010da7048 x26: ffffff8878e38800<br /> [ 17.076095] x25: ffffff8879d22810 x24: ffffffc010003cc8<br /> [ 17.081407] x23: 0000000000000000 x22: ffffffc010a08750<br /> [ 17.086719] x21: ffffff8878e3c7c0 x20: ffffffc010acb000<br /> [ 17.092032] x19: 0000000875e3e244 x18: 0000000000000010<br /> [ 17.097343] x17: 0000000000000000 x16: 0000000000000000<br /> [ 17.102647] x15: ffffff8879e4a988 x14: 0720072007200720<br /> [ 17.107959] x13: 0720072007200720 x12: 0720072007200720<br /> [ 17.113261] x11: 0720072007200720 x10: 0720072007200720<br /> [ 17.118565] x9 : 0720072007200720 x8 : 000000000000022d<br /> [ 17.123869] x7 : 0000000000000015 x6 : 0000000000000098<br /> [ 17.129173] x5 : 0000000000000000 x4 : 0000000000000000<br /> [ 17.134475] x3 : 00000000ffffffff x2 : ffffffc010a1d370<br /> [ 17.139778] x1 : b420c9d75d27bb00 x0 : 0000000000000000<br /> [ 17.145082] Call trace:<br /> [ 17.147524] check_unmap+0x6a0/0x900<br /> [ 17.151091] debug_dma_unmap_page+0x88/0x90<br /> [ 17.155266] gem_rx+0x114/0x2f0<br /> [ 17.158396] macb_poll+0x58/0x100<br /> [ 17.161705] net_rx_action+0x118/0x400<br /> [ 17.165445] __do_softirq+0x138/0x36c<br /> [ 17.169100] irq_exit+0x98/0xc0<br /> [ 17.172234] __handle_domain_irq+0x64/0xc0<br /> [ 17.176320] gic_handle_irq+0x5c/0xc0<br /> [ 17.179974] el1_irq+0xb8/0x140<br /> [ 17.183109] xiic_process+0x5c/0xe30<br /> [ 17.186677] irq_thread_fn+0x28/0x90<br /> [ 17.190244] irq_thread+0x208/0x2a0<br /> [ 17.193724] kthread+0x130/0x140<br /> [ 17.196945] ret_from_fork+0x10/0x20<br /> [ 17.200510] ---[ end trace 7240980785f81d6f ]---<br /> <br /> [ 237.021490] ------------[ cut here ]------------<br /> [ 237.026129] DMA-API: exceeded 7 overlapping mappings of cacheline 0x0000000021d79e7b<br /> [ 237.033886] WARNING: CPU: 0 PID: 0 at kernel/dma/debug.c:499 add_dma_entry+0x214/0x240<br /> [ 237.041802] Modules linked in: xxxxx<br /> [ 237.061637] CPU: 0 PID: 0 Comm: swapper/0 Tainted: G W 5.4.0 #28<br /> [ 237.068941] Hardware name: xxxxx<br /> [ 237.073116] pstate: 80000085 (Nzcv daIf -PAN -UAO)<br /> [ 237.077900] pc : add_dma_entry+0x214/0x240<br /> [ 237.081986] lr : add_dma_entry+0x214/0x240<br /> [ 237.086072] sp : ffffffc010003c30<br /> [ 237.089379] x29: ffffffc010003c30 x28: ffffff8878a0be00<br /> [ 237.094683] x27: 0000000000000180 x26: ffffff8878e387c0<br /> [ 237.099987] x25: 0000000000000002 x24: 0000000000000000<br /> [ 237.105290] x23: 000000000000003b x22: ffffffc010a0fa00<br /> [ 237.110594] x21: 0000000021d79e7b x20: ffffffc010abe600<br /> [ 237.115897] x19: 00000000ffffffef x18: 0000000000000010<br /> [ 237.121201] x17: 0000000000000000 x16: 0000000000000000<br /> [ 237.126504] x15: ffffffc010a0fdc8 x14: 0720072007200720<br /> [ 237.131807] x13: 0720072007200720 x12: 0720072007200720<br /> [ 237.137111] x11: 0720072007200720 x10: 0720072007200720<br /> [ 237.142415] x9 : 0720072007200720 x8 : 0000000000000259<br /> [ 237.147718] x7 : 0000000000000001 x6 : 0000000000000000<br /> [ 237.15302<br /> ---truncated---

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> cifs: fix potential oops in cifs_oplock_break<br /> <br /> With deferred close we can have closes that race with lease breaks,<br /> and so with the current checks for whether to send the lease response,<br /> oplock_response(), this can mean that an unmount (kill_sb) can occur<br /> just before we were checking if the tcon-&gt;ses is valid. See below:<br /> <br /> [Fri Aug 4 04:12:50 2023] RIP: 0010:cifs_oplock_break+0x1f7/0x5b0 [cifs]<br /> [Fri Aug 4 04:12:50 2023] Code: 7d a8 48 8b 7d c0 c0 e9 02 48 89 45 b8 41 89 cf e8 3e f5 ff ff 4c 89 f7 41 83 e7 01 e8 82 b3 03 f2 49 8b 45 50 48 85 c0 74 5e 83 78 60 00 74 57 45 84 ff 75 52 48 8b 43 98 48 83 eb 68 48 39<br /> [Fri Aug 4 04:12:50 2023] RSP: 0018:ffffb30607ddbdf8 EFLAGS: 00010206<br /> [Fri Aug 4 04:12:50 2023] RAX: 632d223d32612022 RBX: ffff97136944b1e0 RCX: 0000000080100009<br /> [Fri Aug 4 04:12:50 2023] RDX: 0000000000000001 RSI: 0000000080100009 RDI: ffff97136944b188<br /> [Fri Aug 4 04:12:50 2023] RBP: ffffb30607ddbe58 R08: 0000000000000001 R09: ffffffffc08e0900<br /> [Fri Aug 4 04:12:50 2023] R10: 0000000000000001 R11: 000000000000000f R12: ffff97136944b138<br /> [Fri Aug 4 04:12:50 2023] R13: ffff97149147c000 R14: ffff97136944b188 R15: 0000000000000000<br /> [Fri Aug 4 04:12:50 2023] FS: 0000000000000000(0000) GS:ffff9714f7c00000(0000) knlGS:0000000000000000<br /> [Fri Aug 4 04:12:50 2023] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> [Fri Aug 4 04:12:50 2023] CR2: 00007fd8de9c7590 CR3: 000000011228e000 CR4: 0000000000350ef0<br /> [Fri Aug 4 04:12:50 2023] Call Trace:<br /> [Fri Aug 4 04:12:50 2023] <br /> [Fri Aug 4 04:12:50 2023] process_one_work+0x225/0x3d0<br /> [Fri Aug 4 04:12:50 2023] worker_thread+0x4d/0x3e0<br /> [Fri Aug 4 04:12:50 2023] ? process_one_work+0x3d0/0x3d0<br /> [Fri Aug 4 04:12:50 2023] kthread+0x12a/0x150<br /> [Fri Aug 4 04:12:50 2023] ? set_kthread_struct+0x50/0x50<br /> [Fri Aug 4 04:12:50 2023] ret_from_fork+0x22/0x30<br /> [Fri Aug 4 04:12:50 2023] <br /> <br /> To fix this change the ordering of the checks before sending the oplock_response<br /> to first check if the openFileList is empty.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> soundwire: bus: Fix unbalanced pm_runtime_put() causing usage count underflow<br /> <br /> This reverts commit<br /> 443a98e649b4 ("soundwire: bus: use pm_runtime_resume_and_get()")<br /> <br /> Change calls to pm_runtime_resume_and_get() back to pm_runtime_get_sync().<br /> This fixes a usage count underrun caused by doing a pm_runtime_put() even<br /> though pm_runtime_resume_and_get() returned an error.<br /> <br /> The three affected functions ignore -EACCES error from trying to get<br /> pm_runtime, and carry on, including a put at the end of the function.<br /> But pm_runtime_resume_and_get() does not increment the usage count if it<br /> returns an error. So in the -EACCES case you must not call<br /> pm_runtime_put().<br /> <br /> The documentation for pm_runtime_get_sync() says:<br /> "Consider using pm_runtime_resume_and_get() ... as this is likely to<br /> result in cleaner code."<br /> <br /> In this case I don&amp;#39;t think it results in cleaner code because the<br /> pm_runtime_put() at the end of the function would have to be conditional on<br /> the return value from pm_runtime_resume_and_get() at the top of the<br /> function.<br /> <br /> pm_runtime_get_sync() doesn&amp;#39;t have this problem because it always<br /> increments the count, so always needs a put. The code can just flow through<br /> and do the pm_runtime_put() unconditionally.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> cifs: Fix lost destroy smbd connection when MR allocate failed<br /> <br /> If the MR allocate failed, the smb direct connection info is NULL,<br /> then smbd_destroy() will directly return, then the connection info<br /> will be leaked.<br /> <br /> Let&amp;#39;s set the smb direct connection info to the server before call<br /> smbd_destroy().

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/amdkfd: Add missing gfx11 MQD manager callbacks<br /> <br /> mqd_stride function was introduced in commit 2f77b9a242a2<br /> ("drm/amdkfd: Update MQD management on multi XCC setup")<br /> but not assigned for gfx11. Fixes a NULL dereference in debugfs.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net/mlx5e: Don&amp;#39;t clone flow post action attributes second time<br /> <br /> The code already clones post action attributes in<br /> mlx5e_clone_flow_attr_for_post_act(). Creating another copy in<br /> mlx5e_tc_post_act_add() is a erroneous leftover from original<br /> implementation. Instead, assign handle-&gt;attribute to post_attr provided by<br /> the caller. Note that cloning the attribute second time is not just<br /> wasteful but also causes issues like second copy not being properly updated<br /> in neigh update code which leads to following use-after-free:<br /> <br /> Feb 21 09:02:00 c-237-177-40-045 kernel: BUG: KASAN: use-after-free in mlx5_cmd_set_fte+0x200d/0x24c0 [mlx5_core]<br /> Feb 21 09:02:00 c-237-177-40-045 kernel: kasan_report+0xbb/0x1a0<br /> Feb 21 09:02:00 c-237-177-40-045 kernel: kasan_save_stack+0x1e/0x40<br /> Feb 21 09:02:00 c-237-177-40-045 kernel: kasan_set_track+0x21/0x30<br /> Feb 21 09:02:00 c-237-177-40-045 kernel: __kasan_kmalloc+0x7a/0x90<br /> Feb 21 09:02:00 c-237-177-40-045 kernel: kasan_save_stack+0x1e/0x40<br /> Feb 21 09:02:00 c-237-177-40-045 kernel: kasan_set_track+0x21/0x30<br /> Feb 21 09:02:00 c-237-177-40-045 kernel: kasan_save_free_info+0x2a/0x40<br /> Feb 21 09:02:00 c-237-177-40-045 kernel: ____kasan_slab_free+0x11a/0x1b0<br /> Feb 21 09:02:00 c-237-177-40-045 kernel: page dumped because: kasan: bad access detected<br /> Feb 21 09:02:00 c-237-177-40-045 kernel: mlx5_core 0000:08:00.0: mlx5_cmd_out_err:803:(pid 8833): SET_FLOW_TABLE_ENTRY(0x936) op_mod(0x0) failed, status bad resource state(0x9), syndrome (0xf2ff71), err(-22)<br /> Feb 21 09:02:00 c-237-177-40-045 kernel: mlx5_core 0000:08:00.0 enp8s0f0: Failed to add post action rule<br /> Feb 21 09:02:00 c-237-177-40-045 kernel: mlx5_core 0000:08:00.0: mlx5e_tc_encap_flows_add:190:(pid 8833): Failed to update flow post acts, -22<br /> Feb 21 09:02:00 c-237-177-40-045 kernel: Call Trace:<br /> Feb 21 09:02:00 c-237-177-40-045 kernel: <br /> Feb 21 09:02:00 c-237-177-40-045 kernel: dump_stack_lvl+0x57/0x7d<br /> Feb 21 09:02:00 c-237-177-40-045 kernel: print_report+0x170/0x471<br /> Feb 21 09:02:00 c-237-177-40-045 kernel: ? mlx5_cmd_set_fte+0x200d/0x24c0 [mlx5_core]<br /> Feb 21 09:02:00 c-237-177-40-045 kernel: kasan_report+0xbb/0x1a0<br /> Feb 21 09:02:00 c-237-177-40-045 kernel: ? mlx5_cmd_set_fte+0x200d/0x24c0 [mlx5_core]<br /> Feb 21 09:02:00 c-237-177-40-045 kernel: mlx5_cmd_set_fte+0x200d/0x24c0 [mlx5_core]<br /> Feb 21 09:02:00 c-237-177-40-045 kernel: ? __module_address.part.0+0x62/0x200<br /> Feb 21 09:02:00 c-237-177-40-045 kernel: ? mlx5_cmd_stub_create_flow_table+0xd0/0xd0 [mlx5_core]<br /> Feb 21 09:02:00 c-237-177-40-045 kernel: ? __raw_spin_lock_init+0x3b/0x110<br /> Feb 21 09:02:00 c-237-177-40-045 kernel: mlx5_cmd_create_fte+0x80/0xb0 [mlx5_core]<br /> Feb 21 09:02:00 c-237-177-40-045 kernel: add_rule_fg+0xe80/0x19c0 [mlx5_core]<br /> --<br /> Feb 21 09:02:00 c-237-177-40-045 kernel: Allocated by task 13476:<br /> Feb 21 09:02:00 c-237-177-40-045 kernel: kasan_save_stack+0x1e/0x40<br /> Feb 21 09:02:00 c-237-177-40-045 kernel: kasan_set_track+0x21/0x30<br /> Feb 21 09:02:00 c-237-177-40-045 kernel: __kasan_kmalloc+0x7a/0x90<br /> Feb 21 09:02:00 c-237-177-40-045 kernel: mlx5_packet_reformat_alloc+0x7b/0x230 [mlx5_core]<br /> Feb 21 09:02:00 c-237-177-40-045 kernel: mlx5e_tc_tun_create_header_ipv4+0x977/0xf10 [mlx5_core]<br /> Feb 21 09:02:00 c-237-177-40-045 kernel: mlx5e_attach_encap+0x15b4/0x1e10 [mlx5_core]<br /> Feb 21 09:02:00 c-237-177-40-045 kernel: post_process_attr+0x305/0xa30 [mlx5_core]<br /> Feb 21 09:02:00 c-237-177-40-045 kernel: mlx5e_tc_add_fdb_flow+0x4c0/0xcf0 [mlx5_core]<br /> Feb 21 09:02:00 c-237-177-40-045 kernel: __mlx5e_add_fdb_flow+0x7cf/0xe90 [mlx5_core]<br /> Feb 21 09:02:00 c-237-177-40-045 kernel: mlx5e_configure_flower+0xcaa/0x4b90 [mlx5_core]<br /> Feb 21 09:02:00 c-237-177-40-045 kernel: mlx5e_rep_setup_tc_cls_flower+0x99/0x1b0 [mlx5_core]<br /> Feb 21 09:02:00 c-237-177-40-045 kernel: mlx5e_rep_setup_tc_cb+0x133/0x1e0 [mlx5_core]<br /> --<br /> Feb 21 09:02:00 c-237-177-40-045 kernel: Freed by task 8833:<br /> Feb 21 09:02:00 c-237-177-40-045 kernel: kasan_save_s<br /> ---truncated---

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ASoC: codecs: tx-macro: Fix for KASAN: slab-out-of-bounds<br /> <br /> When we run syzkaller we get below Out of Bound.<br /> "KASAN: slab-out-of-bounds Read in regcache_flat_read"<br /> <br /> Below is the backtrace of the issue:<br /> <br /> dump_backtrace+0x0/0x4c8<br /> show_stack+0x34/0x44<br /> dump_stack_lvl+0xd8/0x118<br /> print_address_description+0x30/0x2d8<br /> kasan_report+0x158/0x198<br /> __asan_report_load4_noabort+0x44/0x50<br /> regcache_flat_read+0x10c/0x110<br /> regcache_read+0xf4/0x180<br /> _regmap_read+0xc4/0x278<br /> _regmap_update_bits+0x130/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_digital_mute+0xec/0x140<br /> <br /> Actually There is no need to have decimator with 32 bits.<br /> By limiting the variable with short type u8 issue is resolved.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> rcuscale: Move rcu_scale_writer() schedule_timeout_uninterruptible() to _idle()<br /> <br /> The rcuscale.holdoff module parameter can be used to delay the start<br /> of rcu_scale_writer() kthread. However, the hung-task timeout will<br /> trigger when the timeout specified by rcuscale.holdoff is greater than<br /> hung_task_timeout_secs:<br /> <br /> runqemu kvm nographic slirp qemuparams="-smp 4 -m 2048M"<br /> bootparams="rcuscale.shutdown=0 rcuscale.holdoff=300"<br /> <br /> [ 247.071753] INFO: task rcu_scale_write:59 blocked for more than 122 seconds.<br /> [ 247.072529] Not tainted 6.4.0-rc1-00134-gb9ed6de8d4ff #7<br /> [ 247.073400] "echo 0 &gt; /proc/sys/kernel/hung_task_timeout_secs" disables this message.<br /> [ 247.074331] task:rcu_scale_write state:D stack:30144 pid:59 ppid:2 flags:0x00004000<br /> [ 247.075346] Call Trace:<br /> [ 247.075660] <br /> [ 247.075965] __schedule+0x635/0x1280<br /> [ 247.076448] ? __pfx___schedule+0x10/0x10<br /> [ 247.076967] ? schedule_timeout+0x2dc/0x4d0<br /> [ 247.077471] ? __pfx_lock_release+0x10/0x10<br /> [ 247.078018] ? enqueue_timer+0xe2/0x220<br /> [ 247.078522] schedule+0x84/0x120<br /> [ 247.078957] schedule_timeout+0x2e1/0x4d0<br /> [ 247.079447] ? __pfx_schedule_timeout+0x10/0x10<br /> [ 247.080032] ? __pfx_rcu_scale_writer+0x10/0x10<br /> [ 247.080591] ? __pfx_process_timeout+0x10/0x10<br /> [ 247.081163] ? __pfx_sched_set_fifo_low+0x10/0x10<br /> [ 247.081760] ? __pfx_rcu_scale_writer+0x10/0x10<br /> [ 247.082287] rcu_scale_writer+0x6b1/0x7f0<br /> [ 247.082773] ? mark_held_locks+0x29/0xa0<br /> [ 247.083252] ? __pfx_rcu_scale_writer+0x10/0x10<br /> [ 247.083865] ? __pfx_rcu_scale_writer+0x10/0x10<br /> [ 247.084412] kthread+0x179/0x1c0<br /> [ 247.084759] ? __pfx_kthread+0x10/0x10<br /> [ 247.085098] ret_from_fork+0x2c/0x50<br /> [ 247.085433] <br /> <br /> This commit therefore replaces schedule_timeout_uninterruptible() with<br /> schedule_timeout_idle().

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> bpf: Silence a warning in btf_type_id_size()<br /> <br /> syzbot reported a warning in [1] with the following stacktrace:<br /> WARNING: CPU: 0 PID: 5005 at kernel/bpf/btf.c:1988 btf_type_id_size+0x2d9/0x9d0 kernel/bpf/btf.c:1988<br /> ...<br /> RIP: 0010:btf_type_id_size+0x2d9/0x9d0 kernel/bpf/btf.c:1988<br /> ...<br /> Call Trace:<br /> <br /> map_check_btf kernel/bpf/syscall.c:1024 [inline]<br /> map_create+0x1157/0x1860 kernel/bpf/syscall.c:1198<br /> __sys_bpf+0x127f/0x5420 kernel/bpf/syscall.c:5040<br /> __do_sys_bpf kernel/bpf/syscall.c:5162 [inline]<br /> __se_sys_bpf kernel/bpf/syscall.c:5160 [inline]<br /> __x64_sys_bpf+0x79/0xc0 kernel/bpf/syscall.c:5160<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 /> With the following btf<br /> [1] DECL_TAG &amp;#39;a&amp;#39; type_id=4 component_idx=-1<br /> [2] PTR &amp;#39;(anon)&amp;#39; type_id=0<br /> [3] TYPE_TAG &amp;#39;a&amp;#39; type_id=2<br /> [4] VAR &amp;#39;a&amp;#39; type_id=3, linkage=static<br /> and when the bpf_attr.btf_key_type_id = 1 (DECL_TAG),<br /> the following WARN_ON_ONCE in btf_type_id_size() is triggered:<br /> if (WARN_ON_ONCE(!btf_type_is_modifier(size_type) &amp;&amp;<br /> !btf_type_is_var(size_type)))<br /> return NULL;<br /> <br /> Note that &amp;#39;return NULL&amp;#39; is the correct behavior as we don&amp;#39;t want<br /> a DECL_TAG type to be used as a btf_{key,value}_type_id even<br /> for the case like &amp;#39;DECL_TAG -&gt; STRUCT&amp;#39;. So there<br /> is no correctness issue here, we just want to silence warning.<br /> <br /> To silence the warning, I added DECL_TAG as one of kinds in<br /> btf_type_nosize() which will cause btf_type_id_size() returning<br /> NULL earlier without the warning.<br /> <br /> [1] https://lore.kernel.org/bpf/000000000000e0df8d05fc75ba86@google.com/