Kushalkhemka/embedding-cve-nvd-dataset huggingface dataset:
CVE ID: CVE-2022-49224 State: PUBLISHED Published: 2025-02-26T01:55:54.755Z Last Updated: 2025-10-01T19:47:04.090Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: power: supply: ab8500: Fix memory leak in ab8500_fg_sysfs_init kobject_init_and_add() takes reference even when it fails. According to the doc of kobject_init_and_add()： If this function returns an error, kobject_put() must be called to properly clean up the memory associated with the object. Fix memory leak by calling kobject_put(). Additional Analyst Notes: - CISA ADP Vulnrichment: References: - https://git.kernel.org/stable/c/31cdf7897dba1f096b74f69d840f0575b8cdb9ae
t Notes: - CISA ADP Vulnrichment: References: - https://git.kernel.org/stable/c/31cdf7897dba1f096b74f69d840f0575b8cdb9ae - https://git.kernel.org/stable/c/19aa3c98ed7b2616e105946cec804f897837ab84 - https://git.kernel.org/stable/c/db3a61ef8e6aef3b888baa6a85926c2230c2cc56 - https://git.kernel.org/stable/c/41ed61364285ff38bbbe9ca8a45c8372ba72921d - https://git.kernel.org/stable/c/879356a6a05559582b0a7895d86d2d4359745c08 - https://git.kernel.org/stable/c/ffb8e92b4cef92bd25563cf3d8b4489eb22bc61f - https://git.kernel.org/stable/c/261041097ab3470f1120b7733cbf472712304d1e - https://git.kernel.org/stable/c/c32f6b6196b6efc1c68990dfeaac36fb8eb3b8e1 - https://git.kernel.org/stable/c/6a4760463dbc6b603690
/git.kernel.org/stable/c/c32f6b6196b6efc1c68990dfeaac36fb8eb3b8e1 - https://git.kernel.org/stable/c/6a4760463dbc6b603690938c468839985189ce0a
CVE ID: CVE-2022-49225 State: PUBLISHED Published: 2025-02-26T01:55:55.244Z Last Updated: 2025-10-01T19:47:03.940Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: mt76: mt7921s: fix a possible memory leak in mt7921_load_patch Always release fw data at the end of mt7921_load_patch routine. Additional Analyst Notes: - CISA ADP Vulnrichment: References: - https://git.kernel.org/stable/c/b301043384c5c2447357952be9a536c2026d8ad0 - https://git.kernel.org/stable/c/11005b18f453aa192d035d410c11d07edcba5a45
CVE ID: CVE-2022-49226 State: PUBLISHED Published: 2025-02-26T01:55:55.716Z Last Updated: 2025-05-04T08:32:51.283Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: net: asix: add proper error handling of usb read errors Syzbot once again hit uninit value in asix driver. The problem still the same -- asix_read_cmd() reads less bytes, than was requested by caller. Since all read requests are performed via asix_read_cmd() let's catch usb related error there and add __must_check notation to be sure all callers actually check return value. So, this patch adds sanity check inside asix_read_cmd(), that simply checks if bytes read are no
lly check return value. So, this patch adds sanity check inside asix_read_cmd(), that simply checks if bytes read are not less, than was requested and adds missing error handling of asix_read_cmd() all across the driver code. References: - https://git.kernel.org/stable/c/b96a7265f763b37ff3138b9ca8122a950f13b00e - https://git.kernel.org/stable/c/9ea8d2fca8fea3b17005b4dc02f8ef15f7a2fb97 - https://git.kernel.org/stable/c/662ff765470ad0d11a1153d6d8e99d69a98e60b4 - https://git.kernel.org/stable/c/920a9fa27e7805499cfe78491b36fed2322c02ec
CVE ID: CVE-2022-49227 State: PUBLISHED Published: 2025-02-26T01:55:56.202Z Last Updated: 2025-05-04T08:32:52.411Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: igc: avoid kernel warning when changing RX ring parameters Calling ethtool changing the RX ring parameters like this: $ ethtool -G eth0 rx 1024 on igc triggers kernel warnings like this: [ 225.198467] ------------[ cut here ]------------ [ 225.198473] Missing unregister, handled but fix driver [ 225.198485] WARNING: CPU: 7 PID: 959 at net/core/xdp.c:168 xdp_rxq_info_reg+0x79/0xd0 [...] [ 225.198601] Call Trace: [ 225.198604] <TASK> [ 225.198609] igc_setup_rx_resources+
68 xdp_rxq_info_reg+0x79/0xd0 [...] [ 225.198601] Call Trace: [ 225.198604] <TASK> [ 225.198609] igc_setup_rx_resources+0x3f/0xe0 [igc] [ 225.198617] igc_ethtool_set_ringparam+0x30e/0x450 [igc] [ 225.198626] ethnl_set_rings+0x18a/0x250 [ 225.198631] genl_family_rcv_msg_doit+0xca/0x110 [ 225.198637] genl_rcv_msg+0xce/0x1c0 [ 225.198640] ? rings_prepare_data+0x60/0x60 [ 225.198644] ? genl_get_cmd+0xd0/0xd0 [ 225.198647] netlink_rcv_skb+0x4e/0xf0 [ 225.198652] genl_rcv+0x24/0x40 [ 225.198655] netlink_unicast+0x20e/0x330 [ 225.198659] netlink_sendmsg+0x23f/0x480 [ 225.198663] sock_sendmsg+0x5b/0x60 [ 225.198667] __sys_sendto+0xf0/0x160 [ 225.198671] ? handle_mm_fault+0xb2/0x280 [ 225.198676] ? d
ock_sendmsg+0x5b/0x60 [ 225.198667] __sys_sendto+0xf0/0x160 [ 225.198671] ? handle_mm_fault+0xb2/0x280 [ 225.198676] ? do_user_addr_fault+0x1eb/0x690 [ 225.198680] __x64_sys_sendto+0x20/0x30 [ 225.198683] do_syscall_64+0x38/0x90 [ 225.198687] entry_SYSCALL_64_after_hwframe+0x44/0xae [ 225.198693] RIP: 0033:0x7f7ae38ac3aa igc_ethtool_set_ringparam() copies the igc_ring structure but neglects to reset the xdp_rxq_info member before calling igc_setup_rx_resources(). This in turn calls xdp_rxq_info_reg() with an already registered xdp_rxq_info. Make sure to unregister the xdp_rxq_info structure first in igc_setup_rx_resources. References: - https://git.kernel.org/stable/c/ab8c107470d12e7ef99030b
xq_info structure first in igc_setup_rx_resources. References: - https://git.kernel.org/stable/c/ab8c107470d12e7ef99030bf0911a10cdef62d16 - https://git.kernel.org/stable/c/3ddb49af08094ebee250b461172ee7b8e27a35d3 - https://git.kernel.org/stable/c/65aebcf1e05bd97d2e7ffcdff36efea1757c9450 - https://git.kernel.org/stable/c/453307b569a0d41bddd07f26bf41b784cd82a4c9
CVE ID: CVE-2022-49228 State: PUBLISHED Published: 2025-02-26T01:55:56.682Z Last Updated: 2025-05-04T08:32:53.680Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: bpf: Fix a btf decl_tag bug when tagging a function syzbot reported a btf decl_tag bug with stack trace below: general protection fault, probably for non-canonical address 0xdffffc0000000000: 0000 [#1] PREEMPT SMP KASAN KASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007] CPU: 0 PID: 3592 Comm: syz-executor914 Not tainted 5.16.0-syzkaller-11424-gb7892f7d5cb2 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 R
aller-11424-gb7892f7d5cb2 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 RIP: 0010:btf_type_vlen include/linux/btf.h:231 [inline] RIP: 0010:btf_decl_tag_resolve+0x83e/0xaa0 kernel/bpf/btf.c:3910 ... Call Trace: <TASK> btf_resolve+0x251/0x1020 kernel/bpf/btf.c:4198 btf_check_all_types kernel/bpf/btf.c:4239 [inline] btf_parse_type_sec kernel/bpf/btf.c:4280 [inline] btf_parse kernel/bpf/btf.c:4513 [inline] btf_new_fd+0x19fe/0x2370 kernel/bpf/btf.c:6047 bpf_btf_load kernel/bpf/syscall.c:4039 [inline] __sys_bpf+0x1cbb/0x5970 kernel/bpf/syscall.c:4679 __do_sys_bpf kernel/bpf/syscall.c:4738 [inline] __se_sys_bpf kernel/bpf/syscall.c:4736 [inline] __x64_
pf/syscall.c:4679 __do_sys_bpf kernel/bpf/syscall.c:4738 [inline] __se_sys_bpf kernel/bpf/syscall.c:4736 [inline] __x64_sys_bpf+0x75/0xb0 kernel/bpf/syscall.c:4736 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x35/0xb0 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x44/0xae The kasan error is triggered with an illegal BTF like below: type 0: void type 1: int type 2: decl_tag to func type 3 type 3: func to func_proto type 8 The total number of types is 4 and the type 3 is illegal since its func_proto type is out of range. Currently, the target type of decl_tag can be struct/union, var or func. Both struct/union and var implemented their own 'resolve' callback f
type of decl_tag can be struct/union, var or func. Both struct/union and var implemented their own 'resolve' callback functions and hence handled properly in kernel. But func type doesn't have 'resolve' callback function. When btf_decl_tag_resolve() tries to check func type, it tries to get vlen of its func_proto type, which triggered the above kasan error. To fix the issue, btf_decl_tag_resolve() needs to do btf_func_check() before trying to accessing func_proto type. In the current implementation, func type is checked with btf_func_check() in the main checking function btf_check_all_types(). To fix the above kasan issue, let us implement 'resolve' callback func type properly. The 'resolve
tf_check_all_types(). To fix the above kasan issue, let us implement 'resolve' callback func type properly. The 'resolve' callback will be also called in btf_check_all_types() for func types. References: - https://git.kernel.org/stable/c/a3bcd2110c087bc62e90fddd4a93237b049d6e68 - https://git.kernel.org/stable/c/796d5666f6422ddadc938fb888044fcc16f2dbe3 - https://git.kernel.org/stable/c/d7e7b42f4f956f2c68ad8cda87d750093dbba737
CVE ID: CVE-2022-49229 State: PUBLISHED Published: 2025-02-26T01:55:57.155Z Last Updated: 2025-05-04T08:32:54.820Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: ptp: unregister virtual clocks when unregistering physical clock. When unregistering a physical clock which has some virtual clocks, unregister the virtual clocks with it. This fixes the following oops, which can be triggered by unloading a driver providing a PTP clock when it has enabled virtual clocks: BUG: unable to handle page fault for address: ffffffffc04fc4d8 Oops: 0000 [#1] PREEMPT SMP NOPTI RIP: 0010:ptp_vclock_read+0x31/0xb0 Call Trace: timecounter_read+0xf/0
fffffffc04fc4d8 Oops: 0000 [#1] PREEMPT SMP NOPTI RIP: 0010:ptp_vclock_read+0x31/0xb0 Call Trace: timecounter_read+0xf/0x50 ptp_vclock_refresh+0x2c/0x50 ? ptp_clock_release+0x40/0x40 ptp_aux_kworker+0x17/0x30 kthread_worker_fn+0x9b/0x240 ? kthread_should_park+0x30/0x30 kthread+0xe2/0x110 ? kthread_complete_and_exit+0x20/0x20 ret_from_fork+0x22/0x30 References: - https://git.kernel.org/stable/c/b2dea2a696d09163da4cd33cb598ce1f73e86597 - https://git.kernel.org/stable/c/9c796a57cbb5daf124a665689f0b2bc9262e0ced - https://git.kernel.org/stable/c/c49eafe6249f844c26f9866886cc6719d81762df - https://git.kernel.org/stable/c/bfcbb76b0f595ea9ede9f7a218086fef85242f10
CVE ID: CVE-2022-49230 State: PUBLISHED Published: 2025-02-26T01:55:57.662Z Last Updated: 2025-10-01T19:47:03.804Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: mt76: mt7915: fix possible memory leak in mt7915_mcu_add_sta Free allocated skb in mt7915_mcu_add_sta routine in case of failures. Additional Analyst Notes: - CISA ADP Vulnrichment: References: - https://git.kernel.org/stable/c/daf02c7e3c3dc82ffa925999597bd455cf799551 - https://git.kernel.org/stable/c/b334a245ff1d76b1e97af8cea648ea6798b9eb87 - https://git.kernel.org/stable/c/a43736cd12d82913102eb49cb56787a5553e028f
CVE ID: CVE-2022-49231 State: PUBLISHED Published: 2025-02-26T01:55:58.139Z Last Updated: 2025-10-01T19:47:03.648Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: rtw88: fix memory overrun and memory leak during hw_scan Previously we allocated less memory than actual required, overwrite to the buffer causes the mm module to complaint and raise access violation faults. Along with potential memory leaks when returned early. Fix these by passing the correct size and proper deinit flow. Additional Analyst Notes: - CISA ADP Vulnrichment: References: - https://git.kernel.org/stable/c/ec5da191bfcd5fd22b95459b623694f66c1cc10b - https://
CISA ADP Vulnrichment: References: - https://git.kernel.org/stable/c/ec5da191bfcd5fd22b95459b623694f66c1cc10b - https://git.kernel.org/stable/c/d95984b5580dcb8b1c0036577c52b609990a1dab
CVE ID: CVE-2022-49232 State: PUBLISHED Published: 2025-02-26T01:55:58.618Z Last Updated: 2025-10-01T19:47:03.506Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Fix a NULL pointer dereference in amdgpu_dm_connector_add_common_modes() In amdgpu_dm_connector_add_common_modes(), amdgpu_dm_create_common_mode() is assigned to mode and is passed to drm_mode_probed_add() directly after that. drm_mode_probed_add() passes &mode->head to list_add_tail(), and there is a dereference of it in list_add_tail() without recoveries, which could lead to NULL pointer dereference on failure of amdgpu_dm_create_common_mode(). Fix t
l() without recoveries, which could lead to NULL pointer dereference on failure of amdgpu_dm_create_common_mode(). Fix this by adding a NULL check of mode. This bug was found by a static analyzer. Builds with 'make allyesconfig' show no new warnings, and our static analyzer no longer warns about this code. Additional Analyst Notes: - CISA ADP Vulnrichment: References: - https://git.kernel.org/stable/c/2c729dec8c1e3e2892fde5ce8181553860914e74 - https://git.kernel.org/stable/c/57f4ad5e286fe4599c8fc63cf89f85f9eec7f9c9 - https://git.kernel.org/stable/c/19a7eba284790cfbba2945deb2363cf03ce41648 - https://git.kernel.org/stable/c/bdc7429708a0772d90c208975694f7c2133b1202 - https://git.kernel.org/stab
2363cf03ce41648 - https://git.kernel.org/stable/c/bdc7429708a0772d90c208975694f7c2133b1202 - https://git.kernel.org/stable/c/f4eaa999fec78dec2a9c2d797438e05cbffb125b - https://git.kernel.org/stable/c/639b3b9def0a6a3f316a195d705d14113236e89c - https://git.kernel.org/stable/c/588a70177df3b1777484267584ef38ab2ca899a2
CVE ID: CVE-2022-49233 State: PUBLISHED Published: 2025-02-26T01:55:59.093Z Last Updated: 2025-10-01T19:47:03.324Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Call dc_stream_release for remove link enc assignment [Why] A porting error resulted in the stream assignment for the link being retained without being released - a memory leak. [How] Fix the porting error by adding back the dc_stream_release() intended as part of the original patch. Additional Analyst Notes: - CISA ADP Vulnrichment: References: - https://git.kernel.org/stable/c/a28b7b6a0c827ce672edcdb5b2b5916b0beebe03 - https://git.kernel.org/stable/c
References: - https://git.kernel.org/stable/c/a28b7b6a0c827ce672edcdb5b2b5916b0beebe03 - https://git.kernel.org/stable/c/f2bde8349c35d01d7c50456ea06a5c7d5e0e5ed0
CVE ID: CVE-2022-49234 State: PUBLISHED Published: 2025-02-26T01:55:59.615Z Last Updated: 2025-05-04T08:33:01.348Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: net: dsa: Avoid cross-chip syncing of VLAN filtering Changes to VLAN filtering are not applicable to cross-chip notifications. On a system like this: .-----. .-----. .-----. | sw1 +---+ sw2 +---+ sw3 | '-1-2-' '-1-2-' '-1-2-' Before this change, upon sw1p1 leaving a bridge, a call to dsa_port_vlan_filtering would also be made to sw2p1 and sw3p1. In this scenario: .---------. .-----. .-----. | sw1 +---+ sw2 +---+ sw3 | '-1-2-3-4-' '-1-2-' '-1-2-' When sw1p4 would leave
is scenario: .---------. .-----. .-----. | sw1 +---+ sw2 +---+ sw3 | '-1-2-3-4-' '-1-2-' '-1-2-' When sw1p4 would leave a bridge, dsa_port_vlan_filtering would be called for sw2 and sw3 with a non-existing port - leading to array out-of-bounds accesses and crashes on mv88e6xxx. References: - https://git.kernel.org/stable/c/e1f2a4dd8d433eec393d09273a78a3d3551339cf - https://git.kernel.org/stable/c/108dc8741c203e9d6ce4e973367f1bac20c7192b
CVE ID: CVE-2022-49235 State: PUBLISHED Published: 2025-02-26T01:56:00.212Z Last Updated: 2025-10-01T19:47:03.159Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: ath9k_htc: fix uninit value bugs Syzbot reported 2 KMSAN bugs in ath9k. All of them are caused by missing field initialization. In htc_connect_service() svc_meta_len and pad are not initialized. Based on code it looks like in current skb there is no service data, so simply initialize svc_meta_len to 0. htc_issue_send() does not initialize htc_frame_hdr::control array. Based on firmware code, it will initialize it by itself, so simply zero whole array to make KMSAN happ
r::control array. Based on firmware code, it will initialize it by itself, so simply zero whole array to make KMSAN happy Fail logs: BUG: KMSAN: kernel-usb-infoleak in usb_submit_urb+0x6c1/0x2aa0 drivers/usb/core/urb.c:430 usb_submit_urb+0x6c1/0x2aa0 drivers/usb/core/urb.c:430 hif_usb_send_regout drivers/net/wireless/ath/ath9k/hif_usb.c:127 [inline] hif_usb_send+0x5f0/0x16f0 drivers/net/wireless/ath/ath9k/hif_usb.c:479 htc_issue_send drivers/net/wireless/ath/ath9k/htc_hst.c:34 [inline] htc_connect_service+0x143e/0x1960 drivers/net/wireless/ath/ath9k/htc_hst.c:275 ... Uninit was created at: slab_post_alloc_hook mm/slab.h:524 [inline] slab_alloc_node mm/slub.c:3251 [inline] __kmalloc_node_trac
was created at: slab_post_alloc_hook mm/slab.h:524 [inline] slab_alloc_node mm/slub.c:3251 [inline] __kmalloc_node_track_caller+0xe0c/0x1510 mm/slub.c:4974 kmalloc_reserve net/core/skbuff.c:354 [inline] __alloc_skb+0x545/0xf90 net/core/skbuff.c:426 alloc_skb include/linux/skbuff.h:1126 [inline] htc_connect_service+0x1029/0x1960 drivers/net/wireless/ath/ath9k/htc_hst.c:258 ... Bytes 4-7 of 18 are uninitialized Memory access of size 18 starts at ffff888027377e00 BUG: KMSAN: kernel-usb-infoleak in usb_submit_urb+0x6c1/0x2aa0 drivers/usb/core/urb.c:430 usb_submit_urb+0x6c1/0x2aa0 drivers/usb/core/urb.c:430 hif_usb_send_regout drivers/net/wireless/ath/ath9k/hif_usb.c:127 [inline] hif_usb_send+0x
aa0 drivers/usb/core/urb.c:430 hif_usb_send_regout drivers/net/wireless/ath/ath9k/hif_usb.c:127 [inline] hif_usb_send+0x5f0/0x16f0 drivers/net/wireless/ath/ath9k/hif_usb.c:479 htc_issue_send drivers/net/wireless/ath/ath9k/htc_hst.c:34 [inline] htc_connect_service+0x143e/0x1960 drivers/net/wireless/ath/ath9k/htc_hst.c:275 ... Uninit was created at: slab_post_alloc_hook mm/slab.h:524 [inline] slab_alloc_node mm/slub.c:3251 [inline] __kmalloc_node_track_caller+0xe0c/0x1510 mm/slub.c:4974 kmalloc_reserve net/core/skbuff.c:354 [inline] __alloc_skb+0x545/0xf90 net/core/skbuff.c:426 alloc_skb include/linux/skbuff.h:1126 [inline] htc_connect_service+0x1029/0x1960 drivers/net/wireless/ath/ath9k/htc_h
26 alloc_skb include/linux/skbuff.h:1126 [inline] htc_connect_service+0x1029/0x1960 drivers/net/wireless/ath/ath9k/htc_hst.c:258 ... Bytes 16-17 of 18 are uninitialized Memory access of size 18 starts at ffff888027377e00 Additional Analyst Notes: - CISA ADP Vulnrichment: References: - https://git.kernel.org/stable/c/5c2a6a8daa17a3f65b38b9a5574bb362c13fa1d9 - https://git.kernel.org/stable/c/e352acdd378e9263cc4c6018e588f2dac7161d07 - https://git.kernel.org/stable/c/ee4222052a76559c20e821bc3519cefb58b6d3e9 - https://git.kernel.org/stable/c/4d244b731188e0b63fc40a9d2dec72e9181fb37c - https://git.kernel.org/stable/c/11f11ac281f0c0b363d2940204f28bae0422ed71 - https://git.kernel.org/stable/c/0b700f7
37c - https://git.kernel.org/stable/c/11f11ac281f0c0b363d2940204f28bae0422ed71 - https://git.kernel.org/stable/c/0b700f7d06492de34964b6f414120043364f8191 - https://git.kernel.org/stable/c/7da6169b6ebb75816b57be3beb829afa74f3b4b6 - https://git.kernel.org/stable/c/5abf2b761b998063f5e2bae93fd4ab10e2a80f10 - https://git.kernel.org/stable/c/d1e0df1c57bd30871dd1c855742a7c346dbca853
CVE ID: CVE-2022-49236 State: PUBLISHED Published: 2025-02-26T01:56:00.689Z Last Updated: 2025-05-04T08:33:04.114Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: bpf: Fix UAF due to race between btf_try_get_module and load_module While working on code to populate kfunc BTF ID sets for module BTF from its initcall, I noticed that by the time the initcall is invoked, the module BTF can already be seen by userspace (and the BPF verifier). The existing btf_try_get_module calls try_module_get which only fails if mod->state == MODULE_STATE_GOING, i.e. it can increment module reference when module initcall is happening in parallel. Cu
d->state == MODULE_STATE_GOING, i.e. it can increment module reference when module initcall is happening in parallel. Currently, BTF parsing happens from MODULE_STATE_COMING notifier callback. At this point, the module initcalls have not been invoked. The notifier callback parses and prepares the module BTF, allocates an ID, which publishes it to userspace, and then adds it to the btf_modules list allowing the kernel to invoke btf_try_get_module for the BTF. However, at this point, the module has not been fully initialized (i.e. its initcalls have not finished). The code in module.c can still fail and free the module, without caring for other users. However, nothing stops btf_try_get_module
module.c can still fail and free the module, without caring for other users. However, nothing stops btf_try_get_module from succeeding between the state transition from MODULE_STATE_COMING to MODULE_STATE_LIVE. This leads to a use-after-free issue when BPF program loads successfully in the state transition, load_module's do_init_module call fails and frees the module, and BPF program fd on close calls module_put for the freed module. Future patch has test case to verify we don't regress in this area in future. There are multiple points after prepare_coming_module (in load_module) where failure can occur and module loading can return error. We illustrate and test for the race using the last
module) where failure can occur and module loading can return error. We illustrate and test for the race using the last point where it can practically occur (in module __init function). An illustration of the race: CPU 0 CPU 1 load_module notifier_call(MODULE_STATE_COMING) btf_parse_module btf_alloc_id // Published to userspace list_add(&btf_mod->list, btf_modules) mod->init(...) ... ^ bpf_check | check_pseudo_btf_id | btf_try_get_module | returns true | ... ... | module __init in progress return prog_fd | ... ... V if (ret < 0) free_module(mod) ... close(prog_fd) ... bpf_prog_free_deferred module_put(used_btf.mod) // use-after-free We fix this issue by setting a flag BTF_MODULE_F_LIVE, from
rog_free_deferred module_put(used_btf.mod) // use-after-free We fix this issue by setting a flag BTF_MODULE_F_LIVE, from the notifier callback when MODULE_STATE_LIVE state is reached for the module, so that we return NULL from btf_try_get_module for modules that are not fully formed. Since try_module_get already checks that module is not in MODULE_STATE_GOING state, and that is the only transition a live module can make before being removed from btf_modules list, this is enough to close the race and prevent the bug. A later selftest patch crafts the race condition artifically to verify that it has been fixed, and that verifier fails to load program (with ENXIO). Lastly, a couple of comments:
ly to verify that it has been fixed, and that verifier fails to load program (with ENXIO). Lastly, a couple of comments: 1. Even if this race didn't exist, it seems more appropriate to only access resources (ksyms and kfuncs) of a fully formed module which has been initialized completely. 2. This patch was born out of need for synchronization against module initcall for the next patch, so it is needed for correctness even without the aforementioned race condition. The BTF resources initialized by module initcall are set up once and then only looked up, so just waiting until the initcall has finished ensures correct behavior. Additional Analyst Notes: - CISA ADP Vulnrichment: References: - ht
the initcall has finished ensures correct behavior. Additional Analyst Notes: - CISA ADP Vulnrichment: References: - https://git.kernel.org/stable/c/51b82141fffa454abf937a8ff0b8af89e4fd0c8f - https://git.kernel.org/stable/c/d7fccf264b1a785525b366a5b7f8113c756187ad - https://git.kernel.org/stable/c/0481baa2318cb1ab13277715da6cdbb657807b3f - https://git.kernel.org/stable/c/18688de203b47e5d8d9d0953385bf30b5949324f