Kushalkhemka/embedding-cve-nvd-dataset huggingface dataset:
CVE ID: CVE-2022-50478 State: PUBLISHED Published: 2025-10-04T15:16:38.346Z Last Updated: 2025-10-04T15:16:38.346Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: nilfs2: fix shift-out-of-bounds/overflow in nilfs_sb2_bad_offset() Patch series "nilfs2: fix UBSAN shift-out-of-bounds warnings on mount time". The first patch fixes a bug reported by syzbot, and the second one fixes the remaining bug of the same kind. Although they are triggered by the same super block data anomaly, I divided it into the above two because the details of the issues and how to fix it are different. Both are required to eliminate the shift-out-of-bounds
cause the details of the issues and how to fix it are different. Both are required to eliminate the shift-out-of-bounds issues at mount time. This patch (of 2): If the block size exponent information written in an on-disk superblock is corrupted, nilfs_sb2_bad_offset helper function can trigger shift-out-of-bounds warning followed by a kernel panic (if panic_on_warn is set): shift exponent 38983 is too large for 64-bit type 'unsigned long long' Call Trace: <TASK> __dump_stack lib/dump_stack.c:88 [inline] dump_stack_lvl+0x1b1/0x28e lib/dump_stack.c:106 ubsan_epilogue lib/ubsan.c:151 [inline] __ubsan_handle_shift_out_of_bounds+0x33d/0x3b0 lib/ubsan.c:322 nilfs_sb2_bad_offset fs/nilfs2/the_nilf
an.c:151 [inline] __ubsan_handle_shift_out_of_bounds+0x33d/0x3b0 lib/ubsan.c:322 nilfs_sb2_bad_offset fs/nilfs2/the_nilfs.c:449 [inline] nilfs_load_super_block+0xdf5/0xe00 fs/nilfs2/the_nilfs.c:523 init_nilfs+0xb7/0x7d0 fs/nilfs2/the_nilfs.c:577 nilfs_fill_super+0xb1/0x5d0 fs/nilfs2/super.c:1047 nilfs_mount+0x613/0x9b0 fs/nilfs2/super.c:1317 ... In addition, since nilfs_sb2_bad_offset() performs multiplication without considering the upper bound, the computation may overflow if the disk layout parameters are not normal. This fixes these issues by inserting preliminary sanity checks for those parameters and by converting the comparison from one involving multiplication and left bit-shifting t
y checks for those parameters and by converting the comparison from one involving multiplication and left bit-shifting to one using division and right bit-shifting. References: - https://git.kernel.org/stable/c/6b0ea3df56cccd53398d0289f399f19d43136b2e - https://git.kernel.org/stable/c/a6f89b10042baca218c8598d6db5a44c7e32625f - https://git.kernel.org/stable/c/9b3ba54025357440d6c4414c670984f628c6f6bf - https://git.kernel.org/stable/c/d706485dffbbbf848e681edda29c7a46ac55698c - https://git.kernel.org/stable/c/d464b035c0613856d012cf1704879d3ff3f057fb - https://git.kernel.org/stable/c/b47f5c579c8186f7f5ab5e4254e0734ea5b7bf7a - https://git.kernel.org/stable/c/1012ff77284e3bec0ec0a35a820b03ec43dec2c
ble/c/b47f5c579c8186f7f5ab5e4254e0734ea5b7bf7a - https://git.kernel.org/stable/c/1012ff77284e3bec0ec0a35a820b03ec43dec2cc - https://git.kernel.org/stable/c/62d11ec205ef14d8acf172cfc9904fdbf200025a - https://git.kernel.org/stable/c/610a2a3d7d8be3537458a378ec69396a76c385b6
CVE ID: CVE-2022-50479 State: PUBLISHED Published: 2025-10-04T15:16:39.021Z Last Updated: 2025-10-06T09:07:15.985Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: drm/amd: fix potential memory leak This patch fix potential memory leak (clk_src) when function run into last return NULL. s/free/kfree/ - Alex References: - https://git.kernel.org/stable/c/a6e6ab9caeac96b277a3fe7da1dfa8f69a591759 - https://git.kernel.org/stable/c/6160216fd2c97107e8a9ab39863b056d677fcd85
CVE ID: CVE-2022-50480 State: PUBLISHED Published: 2025-10-04T15:16:39.704Z Last Updated: 2025-10-04T15:16:39.704Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: memory: pl353-smc: Fix refcount leak bug in pl353_smc_probe() The break of for_each_available_child_of_node() needs a corresponding of_node_put() when the reference 'child' is not used anymore. Here we do not need to call of_node_put() in fail path as '!match' means no break. While the of_platform_device_create() will created a new reference by 'child' but it has considered the refcounting. References: - https://git.kernel.org/stable/c/b37f4a711e5d4bf3608ccbc6de82b52e9
' but it has considered the refcounting. References: - https://git.kernel.org/stable/c/b37f4a711e5d4bf3608ccbc6de82b52e92b441a0 - https://git.kernel.org/stable/c/fde46754d5483bc398018bbec3c8ef5c55219e67 - https://git.kernel.org/stable/c/566b143aa5112a0c2784e20603778518bb799537 - https://git.kernel.org/stable/c/44db35ceb94756ba513dcf6b69bf9e949b28469c - https://git.kernel.org/stable/c/49605dc25e7fb33bf8b671279d4468531da90f89 - https://git.kernel.org/stable/c/61b3c876c1cbdb1efd1f52a1f348580e6e14efb6
CVE ID: CVE-2022-50481 State: PUBLISHED Published: 2025-10-04T15:16:40.374Z Last Updated: 2025-10-04T15:16:40.374Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: cxl: fix possible null-ptr-deref in cxl_guest_init_afu|adapter() If device_register() fails in cxl_register_afu|adapter(), the device is not added, device_unregister() can not be called in the error path, otherwise it will cause a null-ptr-deref because of removing not added device. As comment of device_register() says, it should use put_device() to give up the reference in the error path. So split device_unregister() into device_del() and put_device(), then goes to pu
ive up the reference in the error path. So split device_unregister() into device_del() and put_device(), then goes to put dev when register fails. References: - https://git.kernel.org/stable/c/96fba6fb95bdede80583c262ac185da09661f264 - https://git.kernel.org/stable/c/1ae581696b7a799afa39a664c4b721569643f58a - https://git.kernel.org/stable/c/d775a1da5a52b4f4bb02f2707ba420d1bec48dbb - https://git.kernel.org/stable/c/60b2ed21a65f3f5318666ccd765c3507991370cf - https://git.kernel.org/stable/c/170e8c2d2b61e15e7f7cfeded81bc1e959a15ed8 - https://git.kernel.org/stable/c/e5021bbf11b024cc65ea1e84c377df484183be4b - https://git.kernel.org/stable/c/b32559ee4e6667c5c3daf4ec5454c277d1f255d2 - https://git.ke
24cc65ea1e84c377df484183be4b - https://git.kernel.org/stable/c/b32559ee4e6667c5c3daf4ec5454c277d1f255d2 - https://git.kernel.org/stable/c/ab44c182353be101c3be9465e1d15d42130c53c4 - https://git.kernel.org/stable/c/61c80d1c3833e196256fb060382db94f24d3d9a7
CVE ID: CVE-2022-50482 State: PUBLISHED Published: 2025-10-04T15:16:41.033Z Last Updated: 2025-10-04T15:16:41.033Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: iommu/vt-d: Clean up si_domain in the init_dmars() error path A splat from kmem_cache_destroy() was seen with a kernel prior to commit ee2653bbe89d ("iommu/vt-d: Remove domain and devinfo mempool") when there was a failure in init_dmars(), because the iommu_domain cache still had objects. While the mempool code is now gone, there still is a leak of the si_domain memory if init_dmars() fails. So clean up si_domain in the init_dmars() error path. References: - https://gi
e si_domain memory if init_dmars() fails. So clean up si_domain in the init_dmars() error path. References: - https://git.kernel.org/stable/c/749bea542b67513e99240dc58bbfc099e842d508 - https://git.kernel.org/stable/c/5cecfe151874b835331efe086bbdcaeaf64f6b90 - https://git.kernel.org/stable/c/724483b585a1b1e063d42ac5aa835707ff2ec165 - https://git.kernel.org/stable/c/d74196bb278b8f8af88e16bd595997dfa3d6fdb0 - https://git.kernel.org/stable/c/0365d6af75f9f2696e94a0fef24a2c8464c037c8 - https://git.kernel.org/stable/c/c4ad3ae4c6be9d8b0701761c839771116bca6ea3 - https://git.kernel.org/stable/c/620bf9f981365c18cc2766c53d92bf8131c63f32
CVE ID: CVE-2022-50483 State: PUBLISHED Published: 2025-10-04T15:16:41.703Z Last Updated: 2025-10-04T15:16:41.703Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: net: enetc: avoid buffer leaks on xdp_do_redirect() failure Before enetc_clean_rx_ring_xdp() calls xdp_do_redirect(), each software BD in the RX ring between index orig_i and i can have one of 2 refcount values on its page. We are the owner of the current buffer that is being processed, so the refcount will be at least 1. If the current owner of the buffer at the diametrically opposed index in the RX ring (i.o.w, the other half of this page) has not yet called kfree(),
uffer at the diametrically opposed index in the RX ring (i.o.w, the other half of this page) has not yet called kfree(), this page's refcount could even be 2. enetc_page_reusable() in enetc_flip_rx_buff() tests for the page refcount against 1, and [ if it's 2 ] does not attempt to reuse it. But if enetc_flip_rx_buff() is put after the xdp_do_redirect() call, the page refcount can have one of 3 values. It can also be 0, if there is no owner of the other page half, and xdp_do_redirect() for this buffer ran so far that it triggered a flush of the devmap/cpumap bulk queue, and the consumers of those bulk queues also freed the buffer, all by the time xdp_do_redirect() returns the execution back t
the consumers of those bulk queues also freed the buffer, all by the time xdp_do_redirect() returns the execution back to enetc. This is the reason why enetc_flip_rx_buff() is called before xdp_do_redirect(), but there is a big flaw with that reasoning: enetc_flip_rx_buff() will set rx_swbd->page = NULL on both sides of the enetc_page_reusable() branch, and if xdp_do_redirect() returns an error, we call enetc_xdp_free(), which does not deal gracefully with that. In fact, what happens is quite special. The page refcounts start as 1. enetc_flip_rx_buff() figures they're reusable, transfers these rx_swbd->page pointers to a different rx_swbd in enetc_reuse_page(), and bumps the refcount to 2. W
ble, transfers these rx_swbd->page pointers to a different rx_swbd in enetc_reuse_page(), and bumps the refcount to 2. When xdp_do_redirect() later returns an error, we call the no-op enetc_xdp_free(), but we still haven't lost the reference to that page. A copy of it is still at rx_ring->next_to_alloc, but that has refcount 2 (and there are no concurrent owners of it in flight, to drop the refcount). What really kills the system is when we'll flip the rx_swbd->page the second time around. With an updated refcount of 2, the page will not be reusable and we'll really leak it. Then enetc_new_page() will have to allocate more pages, which will then eventually leak again on further errors from x
. Then enetc_new_page() will have to allocate more pages, which will then eventually leak again on further errors from xdp_do_redirect(). The problem, summarized, is that we zeroize rx_swbd->page before we're completely done with it, and this makes it impossible for the error path to do something with it. Since the packet is potentially multi-buffer and therefore the rx_swbd->page is potentially an array, manual passing of the old pointers between enetc_flip_rx_buff() and enetc_xdp_free() is a bit difficult. For the sake of going with a simple solution, we accept the possibility of racing with xdp_do_redirect(), and we move the flip procedure to execute only on the redirect success path. By
ility of racing with xdp_do_redirect(), and we move the flip procedure to execute only on the redirect success path. By racing, I mean that the page may be deemed as not reusable by enetc (having a refcount of 0), but there will be no leak in that case, either. Once we accept that, we have something better to do with buffers on XDP_REDIRECT failure. Since we haven't performed half-page flipping yet, we won't, either (and this way, we can avoid enetc_xdp_free() completely, which gives the entire page to the slab allocator). Instead, we'll call enetc_xdp_drop(), which will recycle this half of the buffer back to the RX ring. References: - https://git.kernel.org/stable/c/bcf2c1dc5358dcf7e34a68c
cycle this half of the buffer back to the RX ring. References: - https://git.kernel.org/stable/c/bcf2c1dc5358dcf7e34a68cdb6b0bbf967801efa - https://git.kernel.org/stable/c/7fba523b51ccce5f7981f8a43ad84d664da68131 - https://git.kernel.org/stable/c/306526331e7a37e714e11ab7c6d73eb004745224 - https://git.kernel.org/stable/c/628050ec952d2e2e46ec9fb6aa07e41139e030c8
CVE ID: CVE-2022-50484 State: PUBLISHED Published: 2025-10-04T15:16:42.385Z Last Updated: 2025-10-04T15:16:42.385Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: ALSA: usb-audio: Fix potential memory leaks When the driver hits -ENOMEM at allocating a URB or a buffer, it aborts and goes to the error path that releases the all previously allocated resources. However, when -ENOMEM hits at the middle of the sync EP URB allocation loop, the partially allocated URBs might be left without released, because ep->nurbs is still zero at that point. Fix it by setting ep->nurbs at first, so that the error handler loops over the full URB lis
is still zero at that point. Fix it by setting ep->nurbs at first, so that the error handler loops over the full URB list. References: - https://git.kernel.org/stable/c/0604e5e5537af099ea2f6dfd892afe5c92db8a80 - https://git.kernel.org/stable/c/28d8d267af5d73f91d7640cbdb4024703256e36c - https://git.kernel.org/stable/c/46f0aed47673e275d682af60ed26dcc28add8eae - https://git.kernel.org/stable/c/988ec0cd0a2643c25c1658f7c33de2e15a5a2e31 - https://git.kernel.org/stable/c/bc1d16d282bca421c6fc31de4b8fd412010f01bd - https://git.kernel.org/stable/c/0672215994e2347a9b4f145e2bc1709b1e01cee3 - https://git.kernel.org/stable/c/faa8c1ed77d0169955b9b3516b714cc5fb512f27 - https://git.kernel.org/stable/c/e44424
cee3 - https://git.kernel.org/stable/c/faa8c1ed77d0169955b9b3516b714cc5fb512f27 - https://git.kernel.org/stable/c/e4442410f76d66b9f7e854010bce04853f665324 - https://git.kernel.org/stable/c/6382da0828995af87aa8b8bef28cc61aceb4aff3
CVE ID: CVE-2022-50485 State: PUBLISHED Published: 2025-10-04T15:16:43.093Z Last Updated: 2025-10-04T15:16:43.093Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: ext4: add EXT4_IGET_BAD flag to prevent unexpected bad inode There are many places that will get unhappy (and crash) when ext4_iget() returns a bad inode. However, if iget the boot loader inode, allows a bad inode to be returned, because the inode may not be initialized. This mechanism can be used to bypass some checks and cause panic. To solve this problem, we add a special iget flag EXT4_IGET_BAD. Only with this flag we'd be returning bad inode from ext4_iget(), othe
roblem, we add a special iget flag EXT4_IGET_BAD. Only with this flag we'd be returning bad inode from ext4_iget(), otherwise we always return the error code if the inode is bad inode.(suggested by Jan Kara) References: - https://git.kernel.org/stable/c/2142dfa1de61e25b83198af0308ec7689cca25d3 - https://git.kernel.org/stable/c/c0a738875c2e9c8c3366d792f8bf7fe508d5e5a5 - https://git.kernel.org/stable/c/f7e6b5548f915d7aa435d0764d41eacfb49c6e09 - https://git.kernel.org/stable/c/f725b290ed79ad61e4f721fee95a287892d8b1ad - https://git.kernel.org/stable/c/488a5c2bf7543c3cd3f07a025f2e62be91599430 - https://git.kernel.org/stable/c/63b1e9bccb71fe7d7e3ddc9877dbdc85e5d2d023
CVE ID: CVE-2022-50486 State: PUBLISHED Published: 2025-10-04T15:16:43.791Z Last Updated: 2025-10-04T15:16:43.791Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: net: ethernet: ti: Fix return type of netcp_ndo_start_xmit() With clang's kernel control flow integrity (kCFI, CONFIG_CFI_CLANG), indirect call targets are validated against the expected function pointer prototype to make sure the call target is valid to help mitigate ROP attacks. If they are not identical, there is a failure at run time, which manifests as either a kernel panic or thread getting killed. A proposed warning in clang aims to catch these at compile time,
sts as either a kernel panic or thread getting killed. A proposed warning in clang aims to catch these at compile time, which reveals: drivers/net/ethernet/ti/netcp_core.c:1944:21: error: incompatible function pointer types initializing 'netdev_tx_t (*)(struct sk_buff *, struct net_device *)' (aka 'enum netdev_tx (*)(struct sk_buff *, struct net_device *)') with an expression of type 'int (struct sk_buff *, struct net_device *)' [-Werror,-Wincompatible-function-pointer-types-strict] .ndo_start_xmit = netcp_ndo_start_xmit, ^~~~~~~~~~~~~~~~~~~~ 1 error generated. ->ndo_start_xmit() in 'struct net_device_ops' expects a return type of 'netdev_tx_t', not 'int'. Adjust the return type of netcp_ndo
xmit() in 'struct net_device_ops' expects a return type of 'netdev_tx_t', not 'int'. Adjust the return type of netcp_ndo_start_xmit() to match the prototype's to resolve the warning and CFI failure. References: - https://git.kernel.org/stable/c/a447479ea2cf35603b5739ea947885024b901222 - https://git.kernel.org/stable/c/17bb9bdf701f3e811a9f4820b08b9538ade2641c - https://git.kernel.org/stable/c/d837d74eae077cc3ef9e191ba8535b5f602d4673 - https://git.kernel.org/stable/c/dbe1a6b930ae9647e8ce0b684c903ac67d4398eb - https://git.kernel.org/stable/c/5b0b6553bf4ad3a435a57e02c68d6075f384e1be - https://git.kernel.org/stable/c/a413ebb6049edd881c6427cfa25a7efddd6a4f74 - https://git.kernel.org/stable/c/76563
4e1be - https://git.kernel.org/stable/c/a413ebb6049edd881c6427cfa25a7efddd6a4f74 - https://git.kernel.org/stable/c/765636e58ba505cfe4927eda7ee83791b1c6402a - https://git.kernel.org/stable/c/1e4953b826e12b31995564a459dbd4e9e4604a35 - https://git.kernel.org/stable/c/63fe6ff674a96cfcfc0fa8df1051a27aa31c70b4
CVE ID: CVE-2022-50487 State: REJECTED Published: 2025-10-04T15:16:44.462Z Last Updated: 2025-10-10T15:34:42.519Z Description: No description available.
CVE ID: CVE-2022-50488 State: PUBLISHED Published: 2025-10-04T15:43:42.352Z Last Updated: 2025-10-04T15:43:42.352Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: block, bfq: fix possible uaf for 'bfqq->bic' Our test report a uaf for 'bfqq->bic' in 5.10: ================================================================== BUG: KASAN: use-after-free in bfq_select_queue+0x378/0xa30 CPU: 6 PID: 2318352 Comm: fsstress Kdump: loaded Not tainted 5.10.0-60.18.0.50.h602.kasan.eulerosv2r11.x86_64 #1 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.12.1-0-ga5cab58-20220320_160524-szxrtosci10000 04/01/2014 Call Trace: bfq_se
andard PC (i440FX + PIIX, 1996), BIOS rel-1.12.1-0-ga5cab58-20220320_160524-szxrtosci10000 04/01/2014 Call Trace: bfq_select_queue+0x378/0xa30 bfq_dispatch_request+0xe8/0x130 blk_mq_do_dispatch_sched+0x62/0xb0 __blk_mq_sched_dispatch_requests+0x215/0x2a0 blk_mq_sched_dispatch_requests+0x8f/0xd0 __blk_mq_run_hw_queue+0x98/0x180 __blk_mq_delay_run_hw_queue+0x22b/0x240 blk_mq_run_hw_queue+0xe3/0x190 blk_mq_sched_insert_requests+0x107/0x200 blk_mq_flush_plug_list+0x26e/0x3c0 blk_finish_plug+0x63/0x90 __iomap_dio_rw+0x7b5/0x910 iomap_dio_rw+0x36/0x80 ext4_dio_read_iter+0x146/0x190 [ext4] ext4_file_read_iter+0x1e2/0x230 [ext4] new_sync_read+0x29f/0x400 vfs_read+0x24e/0x2d0 ksys_read+0xd5/0x1b0 do_
90 [ext4] ext4_file_read_iter+0x1e2/0x230 [ext4] new_sync_read+0x29f/0x400 vfs_read+0x24e/0x2d0 ksys_read+0xd5/0x1b0 do_syscall_64+0x33/0x40 entry_SYSCALL_64_after_hwframe+0x61/0xc6 Commit 3bc5e683c67d ("bfq: Split shared queues on move between cgroups") changes that move process to a new cgroup will allocate a new bfqq to use, however, the old bfqq and new bfqq can point to the same bic: 1) Initial state, two process with io in the same cgroup. Process 1 Process 2 (BIC1) (BIC2) | Λ | Λ | | | | V | V | bfqq1 bfqq2 2) bfqq1 is merged to bfqq2. Process 1 Process 2 (BIC1) (BIC2) | | \-------------\| V bfqq1 bfqq2(coop) 3) Process 1 exit, then issue new io(denoce IOA) from Process 2. (BIC2) | Λ
2) | | \-------------\| V bfqq1 bfqq2(coop) 3) Process 1 exit, then issue new io(denoce IOA) from Process 2. (BIC2) | Λ | | V | bfqq2(coop) 4) Before IOA is completed, move Process 2 to another cgroup and issue io. Process 2 (BIC2) Λ |\--------------\ | V bfqq2 bfqq3 Now that BIC2 points to bfqq3, while bfqq2 and bfqq3 both point to BIC2. If all the requests are completed, and Process 2 exit, BIC2 will be freed while there is no guarantee that bfqq2 will be freed before BIC2. Fix the problem by clearing bfqq->bic while bfqq is detached from bic. References: - https://git.kernel.org/stable/c/5533742c7cb1bc9b1f0bf401cc397d44a3a9e07a - https://git.kernel.org/stable/c/094f3d9314d67691cb21ba091c1
rnel.org/stable/c/5533742c7cb1bc9b1f0bf401cc397d44a3a9e07a - https://git.kernel.org/stable/c/094f3d9314d67691cb21ba091c1b528f6e3c4893 - https://git.kernel.org/stable/c/b22fd72bfebda3956efc4431b60ddfc0a51e03e0 - https://git.kernel.org/stable/c/761564d93c8265f65543acf0a576b32d66bfa26a - https://git.kernel.org/stable/c/64dc8c732f5c2b406cc752e6aaa1bd5471159cab
CVE ID: CVE-2022-50489 State: PUBLISHED Published: 2025-10-04T15:43:43.124Z Last Updated: 2025-10-04T15:43:43.124Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: drm/mipi-dsi: Detach devices when removing the host Whenever the MIPI-DSI host is unregistered, the code of mipi_dsi_host_unregister() loops over every device currently found on that bus and will unregister it. However, it doesn't detach it from the bus first, which leads to all kind of resource leaks if the host wants to perform some clean up whenever a device is detached. References: - https://git.kernel.org/stable/c/c202cda08cd5693645d4990ad1eb2e8068a884ec - https:/
r a device is detached. References: - https://git.kernel.org/stable/c/c202cda08cd5693645d4990ad1eb2e8068a884ec - https://git.kernel.org/stable/c/262364574b05676d4b9ebde2ddd3588cd2efd8ce - https://git.kernel.org/stable/c/95ae458209f5a556bba98aff872f933694914eb7 - https://git.kernel.org/stable/c/8242167cfc83dd7e4c96f44b45f108db9bb88146 - https://git.kernel.org/stable/c/45120fa5e522d444e3fc1c5a9afc5d53eed91d00 - https://git.kernel.org/stable/c/26c1b4cfe56f040f71a51c92da1f4cac2e3b9455 - https://git.kernel.org/stable/c/353ab1c13fdd6e524edde780235a8ce9b892c81c - https://git.kernel.org/stable/c/6fc2cd40db1969ba372ce9536dcfcdb87271eac4 - https://git.kernel.org/stable/c/668a8f17b5290d04ef7343636a5588
l.org/stable/c/6fc2cd40db1969ba372ce9536dcfcdb87271eac4 - https://git.kernel.org/stable/c/668a8f17b5290d04ef7343636a5588a0692731a1
CVE ID: CVE-2022-50490 State: PUBLISHED Published: 2025-10-04T15:43:43.790Z Last Updated: 2025-10-04T15:43:43.790Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: bpf: Propagate error from htab_lock_bucket() to userspace In __htab_map_lookup_and_delete_batch() if htab_lock_bucket() returns -EBUSY, it will go to next bucket. Going to next bucket may not only skip the elements in current bucket silently, but also incur out-of-bound memory access or expose kernel memory to userspace if current bucket_cnt is greater than bucket_size or zero. Fixing it by stopping batch operation and returning -EBUSY when htab_lock_bucket() fails, an
r than bucket_size or zero. Fixing it by stopping batch operation and returning -EBUSY when htab_lock_bucket() fails, and the application can retry or skip the busy batch as needed. References: - https://git.kernel.org/stable/c/0e13425104903970a5ede853082d3bbb4edec6f3 - https://git.kernel.org/stable/c/6bfee6eb3d6b96ae730a542909dd22b5f9f50d58 - https://git.kernel.org/stable/c/4f1f39a8f1ce1b24fee6852d7dcd704ce7c4334d - https://git.kernel.org/stable/c/66a7a92e4d0d091e79148a4c6ec15d1da65f4280