Kushalkhemka/embedding-cve-nvd-dataset huggingface dataset:
rg/stable/c/aa64464c8f4d2ab92f6d0b959a1e0767b829d787 - https://git.kernel.org/stable/c/098d54934814dd876963abfe751c3b1cf7fbe56a - https://git.kernel.org/stable/c/3f8d5e802d4cedd445f9a89be8c3fd2d0e99024b - https://git.kernel.org/stable/c/cd2538e5af495b3c747e503db346470fc1ffc447 - https://git.kernel.org/stable/c/e332a12f65d8fed8cf63bedb4e9317bb872b9ac7 - https://git.kernel.org/stable/c/151f66bb618d1fd0eeb84acb61b4a9fa5d8bb0fa
CVE ID: CVE-2024-39477 State: PUBLISHED Published: 2024-07-05T06:55:07.268Z Last Updated: 2025-05-04T09:16:37.647Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: mm/hugetlb: do not call vma_add_reservation upon ENOMEM sysbot reported a splat [1] on __unmap_hugepage_range(). This is because vma_needs_reservation() can return -ENOMEM if allocate_file_region_entries() fails to allocate the file_region struct for the reservation. Check for that and do not call vma_add_reservation() if that is the case, otherwise region_abort() and region_del() will see that we do not have any file_regions. If we detect that vma_needs_reservation()
egion_abort() and region_del() will see that we do not have any file_regions. If we detect that vma_needs_reservation() returned -ENOMEM, we clear the hugetlb_restore_reserve flag as if this reservation was still consumed, so free_huge_folio() will not increment the resv count. [1] https://lore.kernel.org/linux-mm/0000000000004096100617c58d54@google.com/T/#ma5983bc1ab18a54910da83416b3f89f3c7ee43aa Additional Analyst Notes: - CVE Program Container: - CISA ADP Vulnrichment: References: - https://git.kernel.org/stable/c/aa998f9dcb34c28448f86e8f5490f20d5eb0eac7 - https://git.kernel.org/stable/c/8daf9c702ee7f825f0de8600abff764acfedea13
CVE ID: CVE-2024-39478 State: PUBLISHED Published: 2024-07-05T06:55:07.936Z Last Updated: 2025-05-04T09:16:38.956Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: crypto: starfive - Do not free stack buffer RSA text data uses variable length buffer allocated in software stack. Calling kfree on it causes undefined behaviour in subsequent operations. Additional Analyst Notes: - CISA ADP Vulnrichment: - CVE Program Container: References: - https://git.kernel.org/stable/c/5944de192663f272033501dcd322b008fca72006 - https://git.kernel.org/stable/c/d7f01649f4eaf1878472d3d3f480ae1e50d98f6c
CVE ID: CVE-2024-39479 State: PUBLISHED Published: 2024-07-05T06:55:08.597Z Last Updated: 2025-05-04T09:16:40.172Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: drm/i915/hwmon: Get rid of devm When both hwmon and hwmon drvdata (on which hwmon depends) are device managed resources, the expectation, on device unbind, is that hwmon will be released before drvdata. However, in i915 there are two separate code paths, which both release either drvdata or hwmon and either can be released before the other. These code paths (for device unbind) are as follows (see also the bug referenced below): Call Trace: release_nodes+0x11/0x70 devre
paths (for device unbind) are as follows (see also the bug referenced below): Call Trace: release_nodes+0x11/0x70 devres_release_group+0xb2/0x110 component_unbind_all+0x8d/0xa0 component_del+0xa5/0x140 intel_pxp_tee_component_fini+0x29/0x40 [i915] intel_pxp_fini+0x33/0x80 [i915] i915_driver_remove+0x4c/0x120 [i915] i915_pci_remove+0x19/0x30 [i915] pci_device_remove+0x32/0xa0 device_release_driver_internal+0x19c/0x200 unbind_store+0x9c/0xb0 and Call Trace: release_nodes+0x11/0x70 devres_release_all+0x8a/0xc0 device_unbind_cleanup+0x9/0x70 device_release_driver_internal+0x1c1/0x200 unbind_store+0x9c/0xb0 This means that in i915, if use devm, we cannot gurantee that hwmon will always be releas
1/0x200 unbind_store+0x9c/0xb0 This means that in i915, if use devm, we cannot gurantee that hwmon will always be released before drvdata. Which means that we have a uaf if hwmon sysfs is accessed when drvdata has been released but hwmon hasn't. The only way out of this seems to be do get rid of devm_ and release/free everything explicitly during device unbind. v2: Change commit message and other minor code changes v3: Cleanup from i915_hwmon_register on error (Armin Wolf) v4: Eliminate potential static analyzer warning (Rodrigo) Eliminate fetch_and_zero (Jani) v5: Restore previous logic for ddat_gt->hwmon_dev error return (Andi) Additional Analyst Notes: - CISA ADP Vulnrichment: - CVE Progr
previous logic for ddat_gt->hwmon_dev error return (Andi) Additional Analyst Notes: - CISA ADP Vulnrichment: - CVE Program Container: References: - https://git.kernel.org/stable/c/cfa73607eb21a4ce1d6294a2c5733628897b48a2 - https://git.kernel.org/stable/c/ce5a22d22db691d14516c3b8fdbf69139eb2ea8f - https://git.kernel.org/stable/c/5bc9de065b8bb9b8dd8799ecb4592d0403b54281
CVE ID: CVE-2024-39480 State: PUBLISHED Published: 2024-07-05T06:55:09.241Z Last Updated: 2025-05-04T09:16:41.644Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: kdb: Fix buffer overflow during tab-complete Currently, when the user attempts symbol completion with the Tab key, kdb will use strncpy() to insert the completed symbol into the command buffer. Unfortunately it passes the size of the source buffer rather than the destination to strncpy() with predictably horrible results. Most obviously if the command buffer is already full but cp, the cursor position, is in the middle of the buffer, then we will write past the end of
buffer is already full but cp, the cursor position, is in the middle of the buffer, then we will write past the end of the supplied buffer. Fix this by replacing the dubious strncpy() calls with memmove()/memcpy() calls plus explicit boundary checks to make sure we have enough space before we start moving characters around. Additional Analyst Notes: - CVE Program Container: - CISA ADP Vulnrichment: References: - https://git.kernel.org/stable/c/fb824a99e148ff272a53d71d84122728b5f00992 - https://git.kernel.org/stable/c/ddd2972d8e2dee3b33e8121669d55def59f0be8a - https://git.kernel.org/stable/c/cfdc2fa4db57503bc6d3817240547c8ddc55fa96 - https://git.kernel.org/stable/c/f636a40834d22e5e3fc748f060
ernel.org/stable/c/cfdc2fa4db57503bc6d3817240547c8ddc55fa96 - https://git.kernel.org/stable/c/f636a40834d22e5e3fc748f060211879c056cd33 - https://git.kernel.org/stable/c/33d9c814652b971461d1e30bead6792851c209e7 - https://git.kernel.org/stable/c/107e825cc448b7834b31e8b1b3cf0f57426d46d5 - https://git.kernel.org/stable/c/f694da720dcf795dc3eb97bf76d220213f76aaa7 - https://git.kernel.org/stable/c/e9730744bf3af04cda23799029342aa3cddbc454
CVE ID: CVE-2024-39481 State: PUBLISHED Published: 2024-07-05T06:55:09.916Z Last Updated: 2025-05-04T09:16:42.838Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: media: mc: Fix graph walk in media_pipeline_start The graph walk tries to follow all links, even if they are not between pads. This causes a crash with, e.g. a MEDIA_LNK_FL_ANCILLARY_LINK link. Fix this by allowing the walk to proceed only for MEDIA_LNK_FL_DATA_LINK links. Additional Analyst Notes: - CISA ADP Vulnrichment: - CVE Program Container: References: - https://git.kernel.org/stable/c/788fd0f11e45ae8d3a8ebbd3452a6e83f92db376 - https://git.kernel.org/stable/c/e8
erences: - https://git.kernel.org/stable/c/788fd0f11e45ae8d3a8ebbd3452a6e83f92db376 - https://git.kernel.org/stable/c/e80d9db99b7b6c697d8d952dfd25c3425cf61499 - https://git.kernel.org/stable/c/bee9440bc0b6b3b7432f7bfde28656262a3484a2 - https://git.kernel.org/stable/c/8a9d420149c477e7c97fbd6453704e4612bdd3fa
CVE ID: CVE-2024-39482 State: PUBLISHED Published: 2024-07-05T06:55:10.599Z Last Updated: 2025-07-11T17:19:50.338Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: bcache: fix variable length array abuse in btree_iter btree_iter is used in two ways: either allocated on the stack with a fixed size MAX_BSETS, or from a mempool with a dynamic size based on the specific cache set. Previously, the struct had a fixed-length array of size MAX_BSETS which was indexed out-of-bounds for the dynamically-sized iterators, which causes UBSAN to complain. This patch uses the same approach as in bcachefs's sort_iter and splits the iterator into
ich causes UBSAN to complain. This patch uses the same approach as in bcachefs's sort_iter and splits the iterator into a btree_iter with a flexible array member and a btree_iter_stack which embeds a btree_iter as well as a fixed-length data array. Additional Analyst Notes: - CISA ADP Vulnrichment: - CVE Program Container: References: - https://git.kernel.org/stable/c/2c3d7b03b658dc8bfa6112b194b67b92a87e081b - https://git.kernel.org/stable/c/5a1922adc5798b7ec894cd3f197afb6f9591b023 - https://git.kernel.org/stable/c/934e1e4331859183a861f396d7dfaf33cb5afb02 - https://git.kernel.org/stable/c/6479b9f41583b013041943c4602e1ad61cec8148 - https://git.kernel.org/stable/c/0c31344e22dd8d6b1394c6e4c41d6
el.org/stable/c/6479b9f41583b013041943c4602e1ad61cec8148 - https://git.kernel.org/stable/c/0c31344e22dd8d6b1394c6e4c41d639015bdc671 - https://git.kernel.org/stable/c/3a861560ccb35f2a4f0a4b8207fa7c2a35fc7f31
CVE ID: CVE-2024-39483 State: PUBLISHED Published: 2024-07-05T06:55:11.270Z Last Updated: 2025-05-04T09:16:45.307Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: KVM: SVM: WARN on vNMI + NMI window iff NMIs are outright masked When requesting an NMI window, WARN on vNMI support being enabled if and only if NMIs are actually masked, i.e. if the vCPU is already handling an NMI. KVM's ABI for NMIs that arrive simultanesouly (from KVM's point of view) is to inject one NMI and pend the other. When using vNMI, KVM pends the second NMI simply by setting V_NMI_PENDING, and lets the CPU do the rest (hardware automatically sets V_NMI_BLO
ends the second NMI simply by setting V_NMI_PENDING, and lets the CPU do the rest (hardware automatically sets V_NMI_BLOCKING when an NMI is injected). However, if KVM can't immediately inject an NMI, e.g. because the vCPU is in an STI shadow or is running with GIF=0, then KVM will request an NMI window and trigger the WARN (but still function correctly). Whether or not the GIF=0 case makes sense is debatable, as the intent of KVM's behavior is to provide functionality that is as close to real hardware as possible. E.g. if two NMIs are sent in quick succession, the probability of both NMIs arriving in an STI shadow is infinitesimally low on real hardware, but significantly larger in a virtua
ity of both NMIs arriving in an STI shadow is infinitesimally low on real hardware, but significantly larger in a virtual environment, e.g. if the vCPU is preempted in the STI shadow. For GIF=0, the argument isn't as clear cut, because the window where two NMIs can collide is much larger in bare metal (though still small). That said, KVM should not have divergent behavior for the GIF=0 case based on whether or not vNMI support is enabled. And KVM has allowed simultaneous NMIs with GIF=0 for over a decade, since commit 7460fb4a3400 ("KVM: Fix simultaneous NMIs"). I.e. KVM's GIF=0 handling shouldn't be modified without a *really* good reason to do so, and if KVM's behavior were to be modified,
GIF=0 handling shouldn't be modified without a *really* good reason to do so, and if KVM's behavior were to be modified, it should be done irrespective of vNMI support. Additional Analyst Notes: - CVE Program Container: - CISA ADP Vulnrichment: References: - https://git.kernel.org/stable/c/f79edaf7370986d73d204b36c50cc563a4c0f356 - https://git.kernel.org/stable/c/1d87cf2eba46deaff6142366127f2323de9f84d1 - https://git.kernel.org/stable/c/b4bd556467477420ee3a91fbcba73c579669edc6
CVE ID: CVE-2024-39484 State: PUBLISHED Published: 2024-07-05T06:55:11.970Z Last Updated: 2025-11-03T21:56:08.194Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: mmc: davinci: Don't strip remove function when driver is builtin Using __exit for the remove function results in the remove callback being discarded with CONFIG_MMC_DAVINCI=y. When such a device gets unbound (e.g. using sysfs or hotplug), the driver is just removed without the cleanup being performed. This results in resource leaks. Fix it by compiling in the remove callback unconditionally. This also fixes a W=1 modpost warning: WARNING: modpost: drivers/mmc/host/davi
g in the remove callback unconditionally. This also fixes a W=1 modpost warning: WARNING: modpost: drivers/mmc/host/davinci_mmc: section mismatch in reference: davinci_mmcsd_driver+0x10 (section: .data) -> davinci_mmcsd_remove (section: .exit.text) Additional Analyst Notes: - CISA ADP Vulnrichment: - CVE Program Container: References: - https://git.kernel.org/stable/c/6ff7cfa02baabec907f6f29ea76634e6256d2ec4 - https://git.kernel.org/stable/c/aea35157bb9b825faa0432bd0f7fbea37ff39aa1 - https://git.kernel.org/stable/c/5ee241f72edc6dce5051a5f100eab6cc019d873e - https://git.kernel.org/stable/c/7590da4c04dd4aa9c262da0231e978263861c6eb - https://git.kernel.org/stable/c/1d5ed0efe51d36b9ae9b64f133bf4
el.org/stable/c/7590da4c04dd4aa9c262da0231e978263861c6eb - https://git.kernel.org/stable/c/1d5ed0efe51d36b9ae9b64f133bf41cdbf56f584 - https://git.kernel.org/stable/c/55c421b364482b61c4c45313a535e61ed5ae4ea3
CVE ID: CVE-2024-39485 State: PUBLISHED Published: 2024-07-05T06:55:12.633Z Last Updated: 2025-05-04T09:16:47.790Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: media: v4l: async: Properly re-initialise notifier entry in unregister The notifier_entry of a notifier is not re-initialised after unregistering the notifier. This leads to dangling pointers being left there so use list_del_init() to return the notifier_entry an empty list. Additional Analyst Notes: - CISA ADP Vulnrichment: - CVE Program Container: References: - https://git.kernel.org/stable/c/87100b09246202a91fce4a1562955c32229173bb - https://git.kernel.org/stable/c/
eferences: - https://git.kernel.org/stable/c/87100b09246202a91fce4a1562955c32229173bb - https://git.kernel.org/stable/c/1aa6cd4adfc0380fa1ccc2f146848940ff882a66 - https://git.kernel.org/stable/c/9537a8425a7a0222999d5839a0b394b1e8834b4a
CVE ID: CVE-2024-39486 State: PUBLISHED Published: 2024-07-06T09:25:21.514Z Last Updated: 2025-05-04T09:16:48.922Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: drm/drm_file: Fix pid refcounting race <maarten.lankhorst@linux.intel.com>, Maxime Ripard <mripard@kernel.org>, Thomas Zimmermann <tzimmermann@suse.de> filp->pid is supposed to be a refcounted pointer; however, before this patch, drm_file_update_pid() only increments the refcount of a struct pid after storing a pointer to it in filp->pid and dropping the dev->filelist_mutex, making the following race possible: process A process B ========= ========= begin drm_file_upda
the dev->filelist_mutex, making the following race possible: process A process B ========= ========= begin drm_file_update_pid mutex_lock(&dev->filelist_mutex) rcu_replace_pointer(filp->pid, <pid B>, 1) mutex_unlock(&dev->filelist_mutex) begin drm_file_update_pid mutex_lock(&dev->filelist_mutex) rcu_replace_pointer(filp->pid, <pid A>, 1) mutex_unlock(&dev->filelist_mutex) get_pid(<pid A>) synchronize_rcu() put_pid(<pid B>) *** pid B reaches refcount 0 and is freed here *** get_pid(<pid B>) *** UAF *** synchronize_rcu() put_pid(<pid A>) As far as I know, this race can only occur with CONFIG_PREEMPT_RCU=y because it requires RCU to detect a quiescent state in code that is not explicitly callin
ccur with CONFIG_PREEMPT_RCU=y because it requires RCU to detect a quiescent state in code that is not explicitly calling into the scheduler. This race leads to use-after-free of a "struct pid". It is probably somewhat hard to hit because process A has to pass through a synchronize_rcu() operation while process B is between mutex_unlock() and get_pid(). Fix it by ensuring that by the time a pointer to the current task's pid is stored in the file, an extra reference to the pid has been taken. This fix also removes the condition for synchronize_rcu(); I think that optimization is unnecessary complexity, since in that case we would usually have bailed out on the lockless check above. Additional
n is unnecessary complexity, since in that case we would usually have bailed out on the lockless check above. Additional Analyst Notes: - CISA ADP Vulnrichment: - CVE Program Container: References: - https://git.kernel.org/stable/c/16682588ead4a593cf1aebb33b36df4d1e9e4ffa - https://git.kernel.org/stable/c/0acce2a5c619ef1abdee783d7fea5eac78ce4844 - https://git.kernel.org/stable/c/4f2a129b33a2054e62273edd5a051c34c08d96e9
CVE ID: CVE-2024-39487 State: PUBLISHED Published: 2024-07-09T09:52:07.664Z Last Updated: 2025-11-03T21:56:09.674Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: bonding: Fix out-of-bounds read in bond_option_arp_ip_targets_set() In function bond_option_arp_ip_targets_set(), if newval->string is an empty string, newval->string+1 will point to the byte after the string, causing an out-of-bound read. BUG: KASAN: slab-out-of-bounds in strlen+0x7d/0xa0 lib/string.c:418 Read of size 1 at addr ffff8881119c4781 by task syz-executor665/8107 CPU: 1 PID: 8107 Comm: syz-executor665 Not tainted 6.7.0-rc7 #1 Hardware name: QEMU Standard PC
sk syz-executor665/8107 CPU: 1 PID: 8107 Comm: syz-executor665 Not tainted 6.7.0-rc7 #1 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014 Call Trace: <TASK> __dump_stack lib/dump_stack.c:88 [inline] dump_stack_lvl+0xd9/0x150 lib/dump_stack.c:106 print_address_description mm/kasan/report.c:364 [inline] print_report+0xc1/0x5e0 mm/kasan/report.c:475 kasan_report+0xbe/0xf0 mm/kasan/report.c:588 strlen+0x7d/0xa0 lib/string.c:418 __fortify_strlen include/linux/fortify-string.h:210 [inline] in4_pton+0xa3/0x3f0 net/core/utils.c:130 bond_option_arp_ip_targets_set+0xc2/0x910 drivers/net/bonding/bond_options.c:1201 __bond_opt_set+0x2a4/0x1030 drivers/net/bonding/bond_optio
argets_set+0xc2/0x910 drivers/net/bonding/bond_options.c:1201 __bond_opt_set+0x2a4/0x1030 drivers/net/bonding/bond_options.c:767 __bond_opt_set_notify+0x48/0x150 drivers/net/bonding/bond_options.c:792 bond_opt_tryset_rtnl+0xda/0x160 drivers/net/bonding/bond_options.c:817 bonding_sysfs_store_option+0xa1/0x120 drivers/net/bonding/bond_sysfs.c:156 dev_attr_store+0x54/0x80 drivers/base/core.c:2366 sysfs_kf_write+0x114/0x170 fs/sysfs/file.c:136 kernfs_fop_write_iter+0x337/0x500 fs/kernfs/file.c:334 call_write_iter include/linux/fs.h:2020 [inline] new_sync_write fs/read_write.c:491 [inline] vfs_write+0x96a/0xd80 fs/read_write.c:584 ksys_write+0x122/0x250 fs/read_write.c:637 do_syscall_x64 arch/x86
91 [inline] vfs_write+0x96a/0xd80 fs/read_write.c:584 ksys_write+0x122/0x250 fs/read_write.c:637 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0x40/0x110 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x63/0x6b ---[ end trace ]--- Fix it by adding a check of string length before using it. Additional Analyst Notes: - CISA ADP Vulnrichment: - CVE Program Container: References: - https://git.kernel.org/stable/c/6a8a4fd082c439e19fede027e80c79bc4c84bb8e - https://git.kernel.org/stable/c/6b21346b399fd1336fe59233a17eb5ce73041ee1 - https://git.kernel.org/stable/c/707c85ba3527ad6aa25552033576b0f1ff835d7b - https://git.kernel.org/stable/c/bfd14e5915c2669f292a31d028e75dcd8
rg/stable/c/707c85ba3527ad6aa25552033576b0f1ff835d7b - https://git.kernel.org/stable/c/bfd14e5915c2669f292a31d028e75dcd82f1e7e9 - https://git.kernel.org/stable/c/c8eb8ab9a44ff0e73492d0a12a643c449f641a9f - https://git.kernel.org/stable/c/b75e33eae8667084bd4a63e67657c6a5a0f8d1e8 - https://git.kernel.org/stable/c/9f835e48bd4c75fdf6a9cff3f0b806a7abde78da - https://git.kernel.org/stable/c/e271ff53807e8f2c628758290f0e499dbe51cb3d
CVE ID: CVE-2024-39488 State: PUBLISHED Published: 2024-07-10T07:14:08.319Z Last Updated: 2025-05-04T09:16:51.608Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: arm64: asm-bug: Add .align 2 to the end of __BUG_ENTRY When CONFIG_DEBUG_BUGVERBOSE=n, we fail to add necessary padding bytes to bug_table entries, and as a result the last entry in a bug table will be ignored, potentially leading to an unexpected panic(). All prior entries in the table will be handled correctly. The arm64 ABI requires that struct fields of up to 8 bytes are naturally-aligned, with padding added within a struct such that struct are suitably aligned wit
lds of up to 8 bytes are naturally-aligned, with padding added within a struct such that struct are suitably aligned within arrays. When CONFIG_DEBUG_BUGVERPOSE=y, the layout of a bug_entry is: struct bug_entry { signed int bug_addr_disp; // 4 bytes signed int file_disp; // 4 bytes unsigned short line; // 2 bytes unsigned short flags; // 2 bytes } ... with 12 bytes total, requiring 4-byte alignment. When CONFIG_DEBUG_BUGVERBOSE=n, the layout of a bug_entry is: struct bug_entry { signed int bug_addr_disp; // 4 bytes unsigned short flags; // 2 bytes < implicit padding > // 2 bytes } ... with 8 bytes total, with 6 bytes of data and 2 bytes of trailing padding, requiring 4-byte alginment. When w
bytes } ... with 8 bytes total, with 6 bytes of data and 2 bytes of trailing padding, requiring 4-byte alginment. When we create a bug_entry in assembly, we align the start of the entry to 4 bytes, which implicitly handles padding for any prior entries. However, we do not align the end of the entry, and so when CONFIG_DEBUG_BUGVERBOSE=n, the final entry lacks the trailing padding bytes. For the main kernel image this is not a problem as find_bug() doesn't depend on the trailing padding bytes when searching for entries: for (bug = __start___bug_table; bug < __stop___bug_table; ++bug) if (bugaddr == bug_addr(bug)) return bug; However for modules, module_bug_finalize() depends on the trailing b
e; ++bug) if (bugaddr == bug_addr(bug)) return bug; However for modules, module_bug_finalize() depends on the trailing bytes when calculating the number of entries: mod->num_bugs = sechdrs[i].sh_size / sizeof(struct bug_entry); ... and as the last bug_entry lacks the necessary padding bytes, this entry will not be counted, e.g. in the case of a single entry: sechdrs[i].sh_size == 6 sizeof(struct bug_entry) == 8; sechdrs[i].sh_size / sizeof(struct bug_entry) == 0; Consequently module_find_bug() will miss the last bug_entry when it does: for (i = 0; i < mod->num_bugs; ++i, ++bug) if (bugaddr == bug_addr(bug)) goto out; ... which can lead to a kenrel panic due to an unhandled bug. This can be d
bug) if (bugaddr == bug_addr(bug)) goto out; ... which can lead to a kenrel panic due to an unhandled bug. This can be demonstrated with the following module: static int __init buginit(void) { WARN(1, "hello\n"); return 0; } static void __exit bugexit(void) { } module_init(buginit); module_exit(bugexit); MODULE_LICENSE("GPL"); ... which will trigger a kernel panic when loaded: ------------[ cut here ]------------ hello Unexpected kernel BRK exception at EL1 Internal error: BRK handler: 00000000f2000800 [#1] PREEMPT SMP Modules linked in: hello(O+) CPU: 0 PID: 50 Comm: insmod Tainted: G O 6.9.1 #8 Hardware name: linux,dummy-virt (DT) pstate: 60400005 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE
d Tainted: G O 6.9.1 #8 Hardware name: linux,dummy-virt (DT) pstate: 60400005 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : buginit+0x18/0x1000 [hello] lr : buginit+0x18/0x1000 [hello] sp : ffff800080533ae0 x29: ffff800080533ae0 x28: 0000000000000000 x27: 0000000000000000 x26: ffffaba8c4e70510 x25: ffff800080533c30 x24: ffffaba8c4a28a58 x23: 0000000000000000 x22: 0000000000000000 x21: ffff3947c0eab3c0 x20: ffffaba8c4e3f000 x19: ffffaba846464000 x18: 0000000000000006 x17: 0000000000000000 x16: ffffaba8c2492834 x15: 0720072007200720 x14: 0720072007200720 x13: ffffaba8c49b27c8 x12: 0000000000000312 x11: 0000000000000106 x10: ffffaba8c4a0a7c8 x9 : ffffaba8c49b27c8 x8 : 00000000ffffefff x7