Kushalkhemka/embedding-cve-nvd-dataset huggingface dataset:
CVE ID: CVE-2021-47273 State: PUBLISHED Published: 2024-05-21T14:20:02.038Z Last Updated: 2025-05-04T07:07:40.249Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: usb: dwc3-meson-g12a: fix usb2 PHY glue init when phy0 is disabled When only PHY1 is used (for example on Odroid-HC4), the regmap init code uses the usb2 ports when doesn't initialize the PHY1 regmap entry. This fixes: Unable to handle kernel NULL pointer dereference at virtual address 0000000000000020 ... pc : regmap_update_bits_base+0x40/0xa0 lr : dwc3_meson_g12a_usb2_init_phy+0x4c/0xf8 ... Call trace: regmap_update_bits_base+0x40/0xa0 dwc3_meson_g12a_usb2_init_phy+0
wc3_meson_g12a_usb2_init_phy+0x4c/0xf8 ... Call trace: regmap_update_bits_base+0x40/0xa0 dwc3_meson_g12a_usb2_init_phy+0x4c/0xf8 dwc3_meson_g12a_usb2_init+0x7c/0xc8 dwc3_meson_g12a_usb_init+0x28/0x48 dwc3_meson_g12a_probe+0x298/0x540 platform_probe+0x70/0xe0 really_probe+0xf0/0x4d8 driver_probe_device+0xfc/0x168 ... Additional Analyst Notes: - CISA ADP Vulnrichment: - CVE Program Container: References: - https://git.kernel.org/stable/c/750a0d75564293be3ed50f13ef7f38ab75106421 - https://git.kernel.org/stable/c/d8dd3754e707104a34f8ec595034d503ea8871a2 - https://git.kernel.org/stable/c/4d2aa178d2ad2fb156711113790dde13e9aa2376
CVE ID: CVE-2021-47274 State: PUBLISHED Published: 2024-05-21T14:20:02.694Z Last Updated: 2025-05-04T07:07:41.320Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: tracing: Correct the length check which causes memory corruption We've suffered from severe kernel crashes due to memory corruption on our production environment, like, Call Trace: [1640542.554277] general protection fault: 0000 [#1] SMP PTI [1640542.554856] CPU: 17 PID: 26996 Comm: python Kdump: loaded Tainted:G [1640542.556629] RIP: 0010:kmem_cache_alloc+0x90/0x190 [1640542.559074] RSP: 0018:ffffb16faa597df8 EFLAGS: 00010286 [1640542.559587] RAX: 0000000000000000 RBX
alloc+0x90/0x190 [1640542.559074] RSP: 0018:ffffb16faa597df8 EFLAGS: 00010286 [1640542.559587] RAX: 0000000000000000 RBX: 0000000000400200 RCX: 0000000006e931bf [1640542.560323] RDX: 0000000006e931be RSI: 0000000000400200 RDI: ffff9a45ff004300 [1640542.560996] RBP: 0000000000400200 R08: 0000000000023420 R09: 0000000000000000 [1640542.561670] R10: 0000000000000000 R11: 0000000000000000 R12: ffffffff9a20608d [1640542.562366] R13: ffff9a45ff004300 R14: ffff9a45ff004300 R15: 696c662f65636976 [1640542.563128] FS: 00007f45d7c6f740(0000) GS:ffff9a45ff840000(0000) knlGS:0000000000000000 [1640542.563937] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [1640542.564557] CR2: 00007f45d71311a0 CR3: 0000
00000 [1640542.563937] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [1640542.564557] CR2: 00007f45d71311a0 CR3: 000000189d63e004 CR4: 00000000003606e0 [1640542.565279] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [1640542.566069] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 [1640542.566742] Call Trace: [1640542.567009] anon_vma_clone+0x5d/0x170 [1640542.567417] __split_vma+0x91/0x1a0 [1640542.567777] do_munmap+0x2c6/0x320 [1640542.568128] vm_munmap+0x54/0x70 [1640542.569990] __x64_sys_munmap+0x22/0x30 [1640542.572005] do_syscall_64+0x5b/0x1b0 [1640542.573724] entry_SYSCALL_64_after_hwframe+0x44/0xa9 [1640542.575642] RIP: 0033:0x7f45d6e61e27 James
_64+0x5b/0x1b0 [1640542.573724] entry_SYSCALL_64_after_hwframe+0x44/0xa9 [1640542.575642] RIP: 0033:0x7f45d6e61e27 James Wang has reproduced it stably on the latest 4.19 LTS. After some debugging, we finally proved that it's due to ftrace buffer out-of-bound access using a debug tool as follows: [ 86.775200] BUG: Out-of-bounds write at addr 0xffff88aefe8b7000 [ 86.780806] no_context+0xdf/0x3c0 [ 86.784327] __do_page_fault+0x252/0x470 [ 86.788367] do_page_fault+0x32/0x140 [ 86.792145] page_fault+0x1e/0x30 [ 86.795576] strncpy_from_unsafe+0x66/0xb0 [ 86.799789] fetch_memory_string+0x25/0x40 [ 86.804002] fetch_deref_string+0x51/0x60 [ 86.808134] kprobe_trace_func+0x32d/0x3a0 [ 86.812347] kprobe
tring+0x25/0x40 [ 86.804002] fetch_deref_string+0x51/0x60 [ 86.808134] kprobe_trace_func+0x32d/0x3a0 [ 86.812347] kprobe_dispatcher+0x45/0x50 [ 86.816385] kprobe_ftrace_handler+0x90/0xf0 [ 86.820779] ftrace_ops_assist_func+0xa1/0x140 [ 86.825340] 0xffffffffc00750bf [ 86.828603] do_sys_open+0x5/0x1f0 [ 86.832124] do_syscall_64+0x5b/0x1b0 [ 86.835900] entry_SYSCALL_64_after_hwframe+0x44/0xa9 commit b220c049d519 ("tracing: Check length before giving out the filter buffer") adds length check to protect trace data overflow introduced in 0fc1b09ff1ff, seems that this fix can't prevent overflow entirely, the length check should also take the sizeof entry->array[0] into account, since this array[0]
event overflow entirely, the length check should also take the sizeof entry->array[0] into account, since this array[0] is filled the length of trace data and occupy addtional space and risk overflow. Additional Analyst Notes: - CISA ADP Vulnrichment: - CVE Program Container: References: - https://git.kernel.org/stable/c/edcce01e0e50840a9aa6a70baed21477bdd2c9f9 - https://git.kernel.org/stable/c/2d598902799886d67947406f26ee8e5fd2ca097f - https://git.kernel.org/stable/c/31ceae385556c37e4d286cb6378696448f566883 - https://git.kernel.org/stable/c/d63f00ec908b3be635ead5d6029cc94246e1f38d - https://git.kernel.org/stable/c/43c32c22254b9328d7abb1c2b0f689dc67838e60 - https://git.kernel.org/stable/c/b1
46e1f38d - https://git.kernel.org/stable/c/43c32c22254b9328d7abb1c2b0f689dc67838e60 - https://git.kernel.org/stable/c/b16a249eca2230c2cd66fa1d4b94743bd9b6ef92 - https://git.kernel.org/stable/c/3e08a9f9760f4a70d633c328a76408e62d6f80a3
CVE ID: CVE-2021-47275 State: PUBLISHED Published: 2024-05-21T14:20:03.357Z Last Updated: 2025-07-11T17:18:59.576Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: bcache: avoid oversized read request in cache missing code path In the cache missing code path of cached device, if a proper location from the internal B+ tree is matched for a cache miss range, function cached_dev_cache_miss() will be called in cache_lookup_fn() in the following code block, [code block 1] 526 unsigned int sectors = KEY_INODE(k) == s->iop.inode 527 ? min_t(uint64_t, INT_MAX, 528 KEY_START(k) - bio->bi_iter.bi_sector) 529 : INT_MAX; 530 int ret = s->d->
>iop.inode 527 ? min_t(uint64_t, INT_MAX, 528 KEY_START(k) - bio->bi_iter.bi_sector) 529 : INT_MAX; 530 int ret = s->d->cache_miss(b, s, bio, sectors); Here s->d->cache_miss() is the call backfunction pointer initialized as cached_dev_cache_miss(), the last parameter 'sectors' is an important hint to calculate the size of read request to backing device of the missing cache data. Current calculation in above code block may generate oversized value of 'sectors', which consequently may trigger 2 different potential kernel panics by BUG() or BUG_ON() as listed below, 1) BUG_ON() inside bch_btree_insert_key(), [code block 2] 886 BUG_ON(b->ops->is_extents && !KEY_SIZE(k)); 2) BUG() inside biovec_s
) inside bch_btree_insert_key(), [code block 2] 886 BUG_ON(b->ops->is_extents && !KEY_SIZE(k)); 2) BUG() inside biovec_slab(), [code block 3] 51 default: 52 BUG(); 53 return NULL; All the above panics are original from cached_dev_cache_miss() by the oversized parameter 'sectors'. Inside cached_dev_cache_miss(), parameter 'sectors' is used to calculate the size of data read from backing device for the cache missing. This size is stored in s->insert_bio_sectors by the following lines of code, [code block 4] 909 s->insert_bio_sectors = min(sectors, bio_sectors(bio) + reada); Then the actual key inserting to the internal B+ tree is generated and stored in s->iop.replace_key by the following line
hen the actual key inserting to the internal B+ tree is generated and stored in s->iop.replace_key by the following lines of code, [code block 5] 911 s->iop.replace_key = KEY(s->iop.inode, 912 bio->bi_iter.bi_sector + s->insert_bio_sectors, 913 s->insert_bio_sectors); The oversized parameter 'sectors' may trigger panic 1) by BUG_ON() from the above code block. And the bio sending to backing device for the missing data is allocated with hint from s->insert_bio_sectors by the following lines of code, [code block 6] 926 cache_bio = bio_alloc_bioset(GFP_NOWAIT, 927 DIV_ROUND_UP(s->insert_bio_sectors, PAGE_SECTORS), 928 &dc->disk.bio_split); The oversized parameter 'sectors' may trigger panic 2)
(s->insert_bio_sectors, PAGE_SECTORS), 928 &dc->disk.bio_split); The oversized parameter 'sectors' may trigger panic 2) by BUG() from the agove code block. Now let me explain how the panics happen with the oversized 'sectors'. In code block 5, replace_key is generated by macro KEY(). From the definition of macro KEY(), [code block 7] 71 #define KEY(inode, offset, size) \ 72 ((struct bkey) { \ 73 .high = (1ULL << 63) | ((__u64) (size) << 20) | (inode), \ 74 .low = (offset) \ 75 }) Here 'size' is 16bits width embedded in 64bits member 'high' of struct bkey. But in code block 1, if "KEY_START(k) - bio->bi_iter.bi_sector" is very probably to be larger than (1<<16) - 1, which makes the bkey size
1, if "KEY_START(k) - bio->bi_iter.bi_sector" is very probably to be larger than (1<<16) - 1, which makes the bkey size calculation in code block 5 is overflowed. In one bug report the value of parameter 'sectors' is 131072 (= 1 << 17), the overflowed 'sectors' results the overflowed s->insert_bio_sectors in code block 4, then makes size field of s->iop.replace_key to be 0 in code block 5. Then the 0- sized s->iop.replace_key is inserted into the internal B+ tree as cache missing check key (a special key to detect and avoid a racing between normal write request and cache missing read request) as, [code block 8] 915 ret = bch_btree_insert_check_key(b, &s->op, &s->iop.replace_key); Then the 0-
ssing read request) as, [code block 8] 915 ret = bch_btree_insert_check_key(b, &s->op, &s->iop.replace_key); Then the 0-sized s->iop.replace_key as 3rd parameter triggers the bkey size check BUG_ON() in code block 2, and causes the kernel panic 1). Another ke ---truncated--- Additional Analyst Notes: - CISA ADP Vulnrichment: - CVE Program Container: References: - https://git.kernel.org/stable/c/555002a840ab88468e252b0eedf0b05e2ce7099c - https://git.kernel.org/stable/c/41fe8d088e96472f63164e213de44ec77be69478
CVE ID: CVE-2021-47276 State: PUBLISHED Published: 2024-05-21T14:20:04.023Z Last Updated: 2025-05-04T07:07:43.402Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: ftrace: Do not blindly read the ip address in ftrace_bug() It was reported that a bug on arm64 caused a bad ip address to be used for updating into a nop in ftrace_init(), but the error path (rightfully) returned -EINVAL and not -EFAULT, as the bug caused more than one error to occur. But because -EINVAL was returned, the ftrace_bug() tried to report what was at the location of the ip address, and read it directly. This caused the machine to panic, as the ip was not po
what was at the location of the ip address, and read it directly. This caused the machine to panic, as the ip was not pointing to a valid memory address. Instead, read the ip address with copy_from_kernel_nofault() to safely access the memory, and if it faults, report that the address faulted, otherwise report what was in that location. Additional Analyst Notes: - CISA ADP Vulnrichment: - CVE Program Container: References: - https://git.kernel.org/stable/c/0bc62e398bbd9e600959e610def5109957437b28 - https://git.kernel.org/stable/c/4aedc2bc2b32c93555f47c95610efb89cc1ec09b - https://git.kernel.org/stable/c/acf671ba79c1feccc3ec7cfdcffead4efcec49e7 - https://git.kernel.org/stable/c/862dcc14f2803c
ttps://git.kernel.org/stable/c/acf671ba79c1feccc3ec7cfdcffead4efcec49e7 - https://git.kernel.org/stable/c/862dcc14f2803c556bdd73b43c27b023fafce2fb - https://git.kernel.org/stable/c/7e4e824b109f1d41ccf223fbb0565d877d6223a2 - https://git.kernel.org/stable/c/97524384762c1fb9b3ded931498dd2047bd0de81 - https://git.kernel.org/stable/c/3e4ddeb68751fb4fb657199aed9cfd5d02796875 - https://git.kernel.org/stable/c/6c14133d2d3f768e0a35128faac8aa6ed4815051
CVE ID: CVE-2021-47277 State: PUBLISHED Published: 2024-05-21T14:20:04.660Z Last Updated: 2025-05-04T07:07:44.480Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: kvm: avoid speculation-based attacks from out-of-range memslot accesses KVM's mechanism for accessing guest memory translates a guest physical address (gpa) to a host virtual address using the right-shifted gpa (also known as gfn) and a struct kvm_memory_slot. The translation is performed in __gfn_to_hva_memslot using the following formula: hva = slot->userspace_addr + (gfn - slot->base_gfn) * PAGE_SIZE It is expected that gfn falls within the boundaries of the guest's
->userspace_addr + (gfn - slot->base_gfn) * PAGE_SIZE It is expected that gfn falls within the boundaries of the guest's physical memory. However, a guest can access invalid physical addresses in such a way that the gfn is invalid. __gfn_to_hva_memslot is called from kvm_vcpu_gfn_to_hva_prot, which first retrieves a memslot through __gfn_to_memslot. While __gfn_to_memslot does check that the gfn falls within the boundaries of the guest's physical memory or not, a CPU can speculate the result of the check and continue execution speculatively using an illegal gfn. The speculation can result in calculating an out-of-bounds hva. If the resulting host virtual address is used to load another guest
tion can result in calculating an out-of-bounds hva. If the resulting host virtual address is used to load another guest physical address, this is effectively a Spectre gadget consisting of two consecutive reads, the second of which is data dependent on the first. Right now it's not clear if there are any cases in which this is exploitable. One interesting case was reported by the original author of this patch, and involves visiting guest page tables on x86. Right now these are not vulnerable because the hva read goes through get_user(), which contains an LFENCE speculation barrier. However, there are patches in progress for x86 uaccess.h to mask kernel addresses instead of using LFENCE; onc
barrier. However, there are patches in progress for x86 uaccess.h to mask kernel addresses instead of using LFENCE; once these land, a guest could use speculation to read from the VMM's ring 3 address space. Other architectures such as ARM already use the address masking method, and would be susceptible to this same kind of data-dependent access gadgets. Therefore, this patch proactively protects from these attacks by masking out-of-bounds gfns in __gfn_to_hva_memslot, which blocks speculation of invalid hvas. Sean Christopherson noted that this patch does not cover kvm_read_guest_offset_cached. This however is limited to a few bytes past the end of the cache, and therefore it is unlikely t
ad_guest_offset_cached. This however is limited to a few bytes past the end of the cache, and therefore it is unlikely to be useful in the context of building a chain of data dependent accesses. Additional Analyst Notes: - CISA ADP Vulnrichment: - CVE Program Container: References: - https://git.kernel.org/stable/c/3098b86390a6b9ea52657689f08410baf130ceff - https://git.kernel.org/stable/c/740621309b25bbf619b8a0ba5fd50a8e58989441 - https://git.kernel.org/stable/c/361ce3b917aff93123e9e966d8608655c967f438 - https://git.kernel.org/stable/c/22b87fb17a28d37331bb9c1110737627b17f6781 - https://git.kernel.org/stable/c/bff1fbf0cf0712686f1df59a83fba6e31d2746a0 - https://git.kernel.org/stable/c/7af299b9
81 - https://git.kernel.org/stable/c/bff1fbf0cf0712686f1df59a83fba6e31d2746a0 - https://git.kernel.org/stable/c/7af299b97734c7e7f465b42a2139ce4d77246975 - https://git.kernel.org/stable/c/ed0e2a893092c7fcb4ff7ba74e5efce53a6f5940 - https://git.kernel.org/stable/c/da27a83fd6cc7780fea190e1f5c19e87019da65c
CVE ID: CVE-2021-47278 State: PUBLISHED Published: 2024-05-21T14:20:05.394Z Last Updated: 2025-05-04T07:07:45.671Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: bus: mhi: pci_generic: Fix possible use-after-free in mhi_pci_remove() This driver's remove path calls del_timer(). However, that function does not wait until the timer handler finishes. This means that the timer handler may still be running after the driver's remove function has finished, which would result in a use-after-free. Fix by calling del_timer_sync(), which makes sure the timer handler has finished, and unable to re-schedule itself. Additional Analyst Notes:
er_sync(), which makes sure the timer handler has finished, and unable to re-schedule itself. Additional Analyst Notes: - CVE Program Container: - CISA ADP Vulnrichment: References: - https://git.kernel.org/stable/c/c597d5c59c7a6417dba06590f59b922e01188e8d - https://git.kernel.org/stable/c/0b67808ade8893a1b3608ddd74fac7854786c919
CVE ID: CVE-2021-47279 State: PUBLISHED Published: 2024-05-21T14:20:06.124Z Last Updated: 2025-05-04T07:07:46.743Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: usb: misc: brcmstb-usb-pinmap: check return value after calling platform_get_resource() It will cause null-ptr-deref if platform_get_resource() returns NULL, we need check the return value. Additional Analyst Notes: - CVE Program Container: - CISA ADP Vulnrichment: References: - https://git.kernel.org/stable/c/2147684be1ebdaf845783139b9bc4eba3fecd9e4 - https://git.kernel.org/stable/c/fbf649cd6d64d40c03c5397ecd6b1ae922ba7afc
CVE ID: CVE-2021-47280 State: PUBLISHED Published: 2024-05-21T14:20:06.852Z Last Updated: 2025-05-04T07:07:47.801Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: drm: Fix use-after-free read in drm_getunique() There is a time-of-check-to-time-of-use error in drm_getunique() due to retrieving file_priv->master prior to locking the device's master mutex. An example can be seen in the crash report of the use-after-free error found by Syzbot: https://syzkaller.appspot.com/bug?id=148d2f1dfac64af52ffd27b661981a540724f803 In the report, the master pointer was used after being freed. This is because another process had acquired the dev
4f803 In the report, the master pointer was used after being freed. This is because another process had acquired the device's master mutex in drm_setmaster_ioctl(), then overwrote fpriv->master in drm_new_set_master(). The old value of fpriv->master was subsequently freed before the mutex was unlocked. To fix this, we lock the device's master mutex before retrieving the pointer from from fpriv->master. This patch passes the Syzbot reproducer test. Additional Analyst Notes: - CVE Program Container: - CISA ADP Vulnrichment: References: - https://git.kernel.org/stable/c/17dab9326ff263c62dab1dbac4492e2938a049e4 - https://git.kernel.org/stable/c/7d233ba700ceb593905ea82b42dadb4ec8ef85e9 - https://
326ff263c62dab1dbac4492e2938a049e4 - https://git.kernel.org/stable/c/7d233ba700ceb593905ea82b42dadb4ec8ef85e9 - https://git.kernel.org/stable/c/b246b4c70c1250e7814f409b243000f9c0bf79a3 - https://git.kernel.org/stable/c/491d52e0078860b33b6c14f0a7ac74ca1b603bd6 - https://git.kernel.org/stable/c/f773f8cccac13c7e7bbd9182e7996c727742488e - https://git.kernel.org/stable/c/b436acd1cf7fac0ba987abd22955d98025c80c2b
CVE ID: CVE-2021-47281 State: PUBLISHED Published: 2024-05-21T14:20:07.499Z Last Updated: 2025-05-04T07:07:49.241Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: ALSA: seq: Fix race of snd_seq_timer_open() The timer instance per queue is exclusive, and snd_seq_timer_open() should have managed the concurrent accesses. It looks as if it's checking the already existing timer instance at the beginning, but it's not right, because there is no protection, hence any later concurrent call of snd_seq_timer_open() may override the timer instance easily. This may result in UAF, as the leftover timer instance can keep running while the que
verride the timer instance easily. This may result in UAF, as the leftover timer instance can keep running while the queue itself gets closed, as spotted by syzkaller recently. For avoiding the race, add a proper check at the assignment of tmr->timeri again, and return -EBUSY if it's been already registered. Additional Analyst Notes: - CISA ADP Vulnrichment: - CVE Program Container: References: - https://git.kernel.org/stable/c/bd7d88b0874f82f7b29d1a53e574cedaf23166ba - https://git.kernel.org/stable/c/536a7646c00a0f14fee49e5e313109e5da2f6031 - https://git.kernel.org/stable/c/83e197a8414c0ba545e7e3916ce05f836f349273
CVE ID: CVE-2021-47282 State: PUBLISHED Published: 2024-05-21T14:20:08.155Z Last Updated: 2025-05-04T07:07:50.557Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: spi: bcm2835: Fix out-of-bounds access with more than 4 slaves Commit 571e31fa60b3 ("spi: bcm2835: Cache CS register value for ->prepare_message()") limited the number of slaves to 3 at compile-time. The limitation was necessitated by a statically-sized array prepare_cs[] in the driver private data which contains a per-slave register value. The commit sought to enforce the limitation at run-time by setting the controller's num_chipselect to 3: Slaves with a higher chip
sought to enforce the limitation at run-time by setting the controller's num_chipselect to 3: Slaves with a higher chipselect are rejected by spi_add_device(). However the commit neglected that num_chipselect only limits the number of *native* chipselects. If GPIO chipselects are specified in the device tree for more than 3 slaves, num_chipselect is silently raised by of_spi_get_gpio_numbers() and the result are out-of-bounds accesses to the statically-sized array prepare_cs[]. As a bandaid fix which is backportable to stable, raise the number of allowed slaves to 24 (which "ought to be enough for anybody"), enforce the limitation on slave ->setup and revert num_chipselect to 3 (which is th
h "ought to be enough for anybody"), enforce the limitation on slave ->setup and revert num_chipselect to 3 (which is the number of native chipselects supported by the controller). An upcoming for-next commit will allow an arbitrary number of slaves. Additional Analyst Notes: - CISA ADP Vulnrichment: - CVE Program Container: References: - https://git.kernel.org/stable/c/b5502580cf958b094f3b69dfe4eece90eae01fbc - https://git.kernel.org/stable/c/82a8ffba54d31e97582051cb56ba1f988018681e - https://git.kernel.org/stable/c/01415ff85a24308059e06ca3e97fd7bf75648690 - https://git.kernel.org/stable/c/13817d466eb8713a1ffd254f537402f091d48444
CVE ID: CVE-2021-47283 State: PUBLISHED Published: 2024-05-21T14:20:08.828Z Last Updated: 2025-05-04T07:07:51.815Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: net:sfc: fix non-freed irq in legacy irq mode SFC driver can be configured via modparam to work using MSI-X, MSI or legacy IRQ interrupts. In the last one, the interrupt was not properly released on module remove. It was not freed because the flag irqs_hooked was not set during initialization in the case of using legacy IRQ. Example of (trimmed) trace during module remove without this fix: remove_proc_entry: removing non-empty directory 'irq/125', leaking at least '000
during module remove without this fix: remove_proc_entry: removing non-empty directory 'irq/125', leaking at least '0000:3b:00.1' WARNING: CPU: 39 PID: 3658 at fs/proc/generic.c:715 remove_proc_entry+0x15c/0x170 ...trimmed... Call Trace: unregister_irq_proc+0xe3/0x100 free_desc+0x29/0x70 irq_free_descs+0x47/0x70 mp_unmap_irq+0x58/0x60 acpi_unregister_gsi_ioapic+0x2a/0x40 acpi_pci_irq_disable+0x78/0xb0 pci_disable_device+0xd1/0x100 efx_pci_remove+0xa1/0x1e0 [sfc] pci_device_remove+0x38/0xa0 __device_release_driver+0x177/0x230 driver_detach+0xcb/0x110 bus_remove_driver+0x58/0xd0 pci_unregister_driver+0x2a/0xb0 efx_exit_module+0x24/0xf40 [sfc] __do_sys_delete_module.constprop.0+0x171/0x280 ? e