Kushalkhemka/embedding-cve-nvd-dataset huggingface dataset:
CVE ID: CVE-2022-50567 State: PUBLISHED Published: 2025-10-22T13:23:24.508Z Last Updated: 2025-10-22T13:23:24.508Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: fs: jfs: fix shift-out-of-bounds in dbAllocAG Syzbot found a crash : UBSAN: shift-out-of-bounds in dbAllocAG. The underlying bug is the missing check of bmp->db_agl2size. The field can be greater than 64 and trigger the shift-out-of-bounds. Fix this bug by adding a check of bmp->db_agl2size in dbMount since this field is used in many following functions. The upper bound for this field is L2MAXL2SIZE - L2MAXAG, thanks for the help of Dave Kleikamp. Note that, for mainte
ns. The upper bound for this field is L2MAXL2SIZE - L2MAXAG, thanks for the help of Dave Kleikamp. Note that, for maintenance, I reorganized error handling code of dbMount. References: - https://git.kernel.org/stable/c/d3b486946a4e62c7ef6023f7d9c1d049051384ba - https://git.kernel.org/stable/c/3115313cf03113e87c87adee18ee49a20bbdb9ba - https://git.kernel.org/stable/c/eea87acb6027be3dd4d3c57186bb22800d57fdda - https://git.kernel.org/stable/c/359616ce587e524107730504891afa4b1a8be58c - https://git.kernel.org/stable/c/3e997e4ce8ae7ab89d72334120f6aee49c5bbdbd - https://git.kernel.org/stable/c/0536f76a2bca83d1a3740517ba22cc93a44b3099 - https://git.kernel.org/stable/c/2c575c8905f7a8b32d5611b91856b69
.org/stable/c/0536f76a2bca83d1a3740517ba22cc93a44b3099 - https://git.kernel.org/stable/c/2c575c8905f7a8b32d5611b91856b69bac2a5bf1 - https://git.kernel.org/stable/c/67973caae78e21ee46a7281aaa8ca364eb9c444f - https://git.kernel.org/stable/c/898f706695682b9954f280d95e49fa86ffa55d08
CVE ID: CVE-2022-50568 State: PUBLISHED Published: 2025-10-22T13:23:25.136Z Last Updated: 2025-10-22T13:23:25.136Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: usb: gadget: f_hid: fix f_hidg lifetime vs cdev The embedded struct cdev does not have its lifetime correctly tied to the enclosing struct f_hidg, so there is a use-after-free if /dev/hidgN is held open while the gadget is deleted. This can readily be replicated with libusbgx's example programs (for conciseness - operating directly via configfs is equivalent): gadget-hid exec 3<> /dev/hidg0 gadget-vid-pid-remove exec 3<&- Pull the existing device up in to struct f_hidg
ivalent): gadget-hid exec 3<> /dev/hidg0 gadget-vid-pid-remove exec 3<&- Pull the existing device up in to struct f_hidg and make use of the cdev_device_{add,del}() helpers. This changes the lifetime of the device object to match struct f_hidg, but note that it is still added and deleted at the same time. References: - https://git.kernel.org/stable/c/1cd7f156f6389918f760687fbbf133c86da93162 - https://git.kernel.org/stable/c/c78c87c4e389b62f8892af7f59857447aa6d9797 - https://git.kernel.org/stable/c/1b6a53e447ec3d81623610c8c7ec5082b47dfdce - https://git.kernel.org/stable/c/d3136b79705c2e3bba9c76adc5628af0215d798e - https://git.kernel.org/stable/c/9e4b85d815b14bd4db2deea2a54264a23de8b896 - http
136b79705c2e3bba9c76adc5628af0215d798e - https://git.kernel.org/stable/c/9e4b85d815b14bd4db2deea2a54264a23de8b896 - https://git.kernel.org/stable/c/9e08b7f5fa00e9d550851352bd0d1ba74ccffef2 - https://git.kernel.org/stable/c/89ff3dfac604614287ad5aad9370c3f984ea3f4b
CVE ID: CVE-2022-50569 State: PUBLISHED Published: 2025-10-22T13:23:25.810Z Last Updated: 2025-10-22T13:23:25.810Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: xfrm: Update ipcomp_scratches with NULL when freed Currently if ipcomp_alloc_scratches() fails to allocate memory ipcomp_scratches holds obsolete address. So when we try to free the percpu scratches using ipcomp_free_scratches() it tries to vfree non existent vm area. Described below: static void * __percpu *ipcomp_alloc_scratches(void) { ... scratches = alloc_percpu(void *); if (!scratches) return NULL; ipcomp_scratches does not know about this allocation failure. The
s = alloc_percpu(void *); if (!scratches) return NULL; ipcomp_scratches does not know about this allocation failure. Therefore holding the old obsolete address. ... } So when we free, static void ipcomp_free_scratches(void) { ... scratches = ipcomp_scratches; Assigning obsolete address from ipcomp_scratches if (!scratches) return; for_each_possible_cpu(i) vfree(*per_cpu_ptr(scratches, i)); Trying to free non existent page, causing warning: trying to vfree existent vm area. ... } Fix this breakage by updating ipcomp_scrtches with NULL when scratches is freed References: - https://git.kernel.org/stable/c/debca61df6bc2f65e020656c9c5b878d6b38d30f - https://git.kernel.org/stable/c/a39f456d62810c0
tps://git.kernel.org/stable/c/debca61df6bc2f65e020656c9c5b878d6b38d30f - https://git.kernel.org/stable/c/a39f456d62810c0efb43cead22f98d95b53e4b1a - https://git.kernel.org/stable/c/1e8abde895b3ac6a368cbdb372e8800c49e73a28 - https://git.kernel.org/stable/c/18373ed500f7cd53e24d9b0bd0f1c09d78dba87e - https://git.kernel.org/stable/c/be81c44242b20fc3bdcc73480ef8aaee56f5d0b6 - https://git.kernel.org/stable/c/03155680191ef0f004b1d6a5714c5b8cd271ab61 - https://git.kernel.org/stable/c/f3bdba4440d82e0da2b1bfc35d3836c8a8e00677 - https://git.kernel.org/stable/c/2c19945ce8095d065df550e7fe350cd5cc40c6e6 - https://git.kernel.org/stable/c/8a04d2fc700f717104bfb95b0f6694e448a4537f
CVE ID: CVE-2022-50570 State: PUBLISHED Published: 2025-10-22T13:23:26.495Z Last Updated: 2025-10-22T13:23:26.495Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: platform/chrome: fix memory corruption in ioctl If "s_mem.bytes" is larger than the buffer size it leads to memory corruption. References: - https://git.kernel.org/stable/c/e548f9503c4b3292a60a63fe77dccea62999a35a - https://git.kernel.org/stable/c/868fc93b615b9f6c2b0b1894536618fa6cd66acc - https://git.kernel.org/stable/c/fd1d3b265784a2243fcaef06aebfb2f8ee733cec - https://git.kernel.org/stable/c/f143f1d9a8e5c6c9db3de81ca270191226fcce36 - https://git.kernel.org/stable/c/
f8ee733cec - https://git.kernel.org/stable/c/f143f1d9a8e5c6c9db3de81ca270191226fcce36 - https://git.kernel.org/stable/c/0c2e18924504208644d18415667895a4ac54cf2a - https://git.kernel.org/stable/c/8a07b45fd3c2dda24fad43639be5335a4595196a
CVE ID: CVE-2022-50571 State: PUBLISHED Published: 2025-10-22T13:23:27.187Z Last Updated: 2025-10-22T13:23:27.187Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: btrfs: call __btrfs_remove_free_space_cache_locked on cache load failure Now that lockdep is staying enabled through our entire CI runs I started seeing the following stack in generic/475 ------------[ cut here ]------------ WARNING: CPU: 1 PID: 2171864 at fs/btrfs/discard.c:604 btrfs_discard_update_discardable+0x98/0xb0 CPU: 1 PID: 2171864 Comm: kworker/u4:0 Not tainted 5.19.0-rc8+ #789 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.13.0-2.fc32 04/01/2014
ker/u4:0 Not tainted 5.19.0-rc8+ #789 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.13.0-2.fc32 04/01/2014 Workqueue: btrfs-cache btrfs_work_helper RIP: 0010:btrfs_discard_update_discardable+0x98/0xb0 RSP: 0018:ffffb857c2f7bad0 EFLAGS: 00010246 RAX: 0000000000000000 RBX: ffff8c85c605c200 RCX: 0000000000000001 RDX: 0000000000000000 RSI: ffffffff86807c5b RDI: ffffffff868a831e RBP: ffff8c85c4c54000 R08: 0000000000000000 R09: 0000000000000000 R10: ffff8c85c66932f0 R11: 0000000000000001 R12: ffff8c85c3899010 R13: ffff8c85d5be4f40 R14: ffff8c85c4c54000 R15: ffff8c86114bfa80 FS: 0000000000000000(0000) GS:ffff8c863bd00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000
14bfa80 FS: 0000000000000000(0000) GS:ffff8c863bd00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f2e7f168160 CR3: 000000010289a004 CR4: 0000000000370ee0 Call Trace: __btrfs_remove_free_space_cache+0x27/0x30 load_free_space_cache+0xad2/0xaf0 caching_thread+0x40b/0x650 ? lock_release+0x137/0x2d0 btrfs_work_helper+0xf2/0x3e0 ? lock_is_held_type+0xe2/0x140 process_one_work+0x271/0x590 ? process_one_work+0x590/0x590 worker_thread+0x52/0x3b0 ? process_one_work+0x590/0x590 kthread+0xf0/0x120 ? kthread_complete_and_exit+0x20/0x20 ret_from_fork+0x1f/0x30 This is the code ctl = block_group->free_space_ctl; discard_ctl = &block_group->fs_info->discard_ctl;
om_fork+0x1f/0x30 This is the code ctl = block_group->free_space_ctl; discard_ctl = &block_group->fs_info->discard_ctl; lockdep_assert_held(&ctl->tree_lock); We have a temporary free space ctl for loading the free space cache in order to avoid having allocations happening while we're loading the cache. When we hit an error we free it all up, however this also calls btrfs_discard_update_discardable, which requires block_group->free_space_ctl->tree_lock to be held. However this is our temporary ctl so this lock isn't held. Fix this by calling __btrfs_remove_free_space_cache_locked instead so that we only clean up the entries and do not mess with the discardable stats. References: - https://git
ocked instead so that we only clean up the entries and do not mess with the discardable stats. References: - https://git.kernel.org/stable/c/819a61301275dcc573e3f520be3dc2c8531bee2d - https://git.kernel.org/stable/c/8a1ae2781dee9fc21ca82db682d37bea4bd074ad
CVE ID: CVE-2022-50572 State: PUBLISHED Published: 2025-10-22T13:23:27.813Z Last Updated: 2025-10-22T13:23:27.813Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: ASoC: audio-graph-card: fix refcount leak of cpu_ep in __graph_for_each_link() The of_get_next_child() returns a node with refcount incremented, and decrements the refcount of prev. So in the error path of the while loop, of_node_put() needs be called for cpu_ep. References: - https://git.kernel.org/stable/c/ed1376f771404917c2ec3ebc617431ec01146134 - https://git.kernel.org/stable/c/06c9d468c06806dab752eb8e72addbf3792c1023 - https://git.kernel.org/stable/c/85eb5c952b7fe
https://git.kernel.org/stable/c/06c9d468c06806dab752eb8e72addbf3792c1023 - https://git.kernel.org/stable/c/85eb5c952b7fe2d2059beaa4a4dd26688b25547b - https://git.kernel.org/stable/c/49dad92af6892f46851af989ef3aa7cd7316c389 - https://git.kernel.org/stable/c/4cc8431ec77a43ea106d8bde0860c61cfdda1cd0 - https://git.kernel.org/stable/c/8ab2d12c726f0fde0692fa5d81d8019b3dcd62d0
CVE ID: CVE-2022-50573 State: PUBLISHED Published: 2025-10-22T13:23:28.437Z Last Updated: 2025-10-22T13:23:28.437Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: wifi: mt76: mt7915: fix mt7915_rate_txpower_get() resource leaks Coverity message: variable "buf" going out of scope leaks the storage. Addresses-Coverity-ID: 1527799 ("Resource leaks") References: - https://git.kernel.org/stable/c/ecff00802f60fa5d08c133d209ed984a455a41f8 - https://git.kernel.org/stable/c/8b25301af01566f4b5a301fc1ad7c5d2b1788d7f
CVE ID: CVE-2022-50574 State: PUBLISHED Published: 2025-10-22T13:23:29.027Z Last Updated: 2025-10-22T13:23:29.027Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: drm/omap: dss: Fix refcount leak bugs In dss_init_ports() and __dss_uninit_ports(), we should call of_node_put() for the reference returned by of_graph_get_port_by_id() in fail path or when it is not used anymore. References: - https://git.kernel.org/stable/c/9d7af9b1624dd70b67354972d7297429e6372091 - https://git.kernel.org/stable/c/1f340e1c1c74d11c45a6e32663829b26acd4f47b - https://git.kernel.org/stable/c/a5ce83e85d795ec98697039ecc518b21d5810adc - https://git.kernel.o
a6e32663829b26acd4f47b - https://git.kernel.org/stable/c/a5ce83e85d795ec98697039ecc518b21d5810adc - https://git.kernel.org/stable/c/e55261beb86a15c190b2ff9090cb47bc06765353 - https://git.kernel.org/stable/c/8f7c4114db841497e1148598e22548dd1f700b22 - https://git.kernel.org/stable/c/8b42057e62120813ebe9274f508fa785b7cab33a
CVE ID: CVE-2022-50575 State: PUBLISHED Published: 2025-10-22T13:23:29.595Z Last Updated: 2025-10-22T13:23:29.595Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: xen/privcmd: Fix a possible warning in privcmd_ioctl_mmap_resource() As 'kdata.num' is user-controlled data, if user tries to allocate memory larger than(>=) MAX_ORDER, then kcalloc() will fail, it creates a stack trace and messes up dmesg with a warning. Call trace: -> privcmd_ioctl --> privcmd_ioctl_mmap_resource Add __GFP_NOWARN in order to avoid too large allocation warning. This is detected by static analysis using smatch. References: - https://git.kernel.org/stab
oo large allocation warning. This is detected by static analysis using smatch. References: - https://git.kernel.org/stable/c/5d68ae32d132ea2af73bc223fd64c46f85302a8b - https://git.kernel.org/stable/c/4f983ee5e5de924d93a7bbb4e6f68f38c6256cd5 - https://git.kernel.org/stable/c/46026bb057c35f5bb111bf95e00cd8366d2e34d4 - https://git.kernel.org/stable/c/0bf874183b32eae2cc20e3c5be38ec3d33e7e564 - https://git.kernel.org/stable/c/e0c5f1058ed96f2b7487560c4c4cbd768d13d065 - https://git.kernel.org/stable/c/4da411086f5ab32f811a89ef804980ec106ebb65 - https://git.kernel.org/stable/c/8b997b2bb2c53b76a6db6c195930e9ab8e4b0c79
CVE ID: CVE-2022-50576 State: PUBLISHED Published: 2025-10-22T13:23:30.250Z Last Updated: 2025-10-22T13:23:30.250Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: serial: pch: Fix PCI device refcount leak in pch_request_dma() As comment of pci_get_slot() says, it returns a pci_device with its refcount increased. The caller must decrement the reference count by calling pci_dev_put(). Since 'dma_dev' is only used to filter the channel in filter(), we can call pci_dev_put() before exiting from pch_request_dma(). Add the missing pci_dev_put() for the normal and error path. References: - https://git.kernel.org/stable/c/90ff030ca10b69
dd the missing pci_dev_put() for the normal and error path. References: - https://git.kernel.org/stable/c/90ff030ca10b69feeebda1427550ebf9ed2ad868 - https://git.kernel.org/stable/c/56e5a7c5ee3f0dc8978b5df2b1a98a1b060c5e2a - https://git.kernel.org/stable/c/dfd15c5550b9190d5b0f9bcacb3e6436322f3854 - https://git.kernel.org/stable/c/d165388227aa7e46a9751b90bae6337b5335cdbb - https://git.kernel.org/stable/c/07f4ca68b0f6bf84b6b391c14b59fd179fcde9c5 - https://git.kernel.org/stable/c/6f7d82380fbeaed3a940efc33c23f0c4bbd0fc02 - https://git.kernel.org/stable/c/4f5d28865c665c9064de631a518f9bc8099d9ce4 - https://git.kernel.org/stable/c/516614a371c26e3334625b4bca19a5362bf658d6 - https://git.kernel.org/sta
518f9bc8099d9ce4 - https://git.kernel.org/stable/c/516614a371c26e3334625b4bca19a5362bf658d6 - https://git.kernel.org/stable/c/8be3a7bf773700534a6e8f87f6ed2ed111254be5
CVE ID: CVE-2022-50577 State: PUBLISHED Published: 2025-10-22T13:23:30.910Z Last Updated: 2025-10-22T13:23:30.910Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: ima: Fix memory leak in __ima_inode_hash() Commit f3cc6b25dcc5 ("ima: always measure and audit files in policy") lets measurement or audit happen even if the file digest cannot be calculated. As a result, iint->ima_hash could have been allocated despite ima_collect_measurement() returning an error. Since ima_hash belongs to a temporary inode metadata structure, declared at the beginning of __ima_inode_hash(), just add a kfree() call if ima_collect_measurement() returns
structure, declared at the beginning of __ima_inode_hash(), just add a kfree() call if ima_collect_measurement() returns an error different from -ENOMEM (in that case, ima_hash should not have been allocated). References: - https://git.kernel.org/stable/c/c4df8cb38f139ed9f4296868c0a6f15a26e8c491 - https://git.kernel.org/stable/c/f375bcf69f58fd0744c9dfd1b6b891a27301d67b - https://git.kernel.org/stable/c/8c1d6a050a0f16e0a9d32eaf53b965c77279c6f8
CVE ID: CVE-2022-50578 State: PUBLISHED Published: 2025-10-22T13:23:31.565Z Last Updated: 2025-10-22T13:23:31.565Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: class: fix possible memory leak in __class_register() If class_add_groups() returns error, the 'cp->subsys' need be unregister, and the 'cp' need be freed. We can not call kset_unregister() here, because the 'cls' will be freed in callback function class_release() and it's also freed in caller's error path, it will cause double free. So fix this by calling kobject_del() and kfree_const(name) to cleanup kobject. Besides, call kfree() to free the 'cp'. Fault injection te
lling kobject_del() and kfree_const(name) to cleanup kobject. Besides, call kfree() to free the 'cp'. Fault injection test can trigger this: unreferenced object 0xffff888102fa8190 (size 8): comm "modprobe", pid 502, jiffies 4294906074 (age 49.296s) hex dump (first 8 bytes): 70 6b 74 63 64 76 64 00 pktcdvd. backtrace: [<00000000e7c7703d>] __kmalloc_track_caller+0x1ae/0x320 [<000000005e4d70bc>] kstrdup+0x3a/0x70 [<00000000c2e5e85a>] kstrdup_const+0x68/0x80 [<000000000049a8c7>] kvasprintf_const+0x10b/0x190 [<0000000029123163>] kobject_set_name_vargs+0x56/0x150 [<00000000747219c9>] kobject_set_name+0xab/0xe0 [<0000000005f1ea4e>] __class_register+0x15c/0x49a unreferenced object 0xffff888037274000
c9>] kobject_set_name+0xab/0xe0 [<0000000005f1ea4e>] __class_register+0x15c/0x49a unreferenced object 0xffff888037274000 (size 1024): comm "modprobe", pid 502, jiffies 4294906074 (age 49.296s) hex dump (first 32 bytes): 00 40 27 37 80 88 ff ff 00 40 27 37 80 88 ff ff .@'7.....@'7.... 00 00 00 00 ad 4e ad de ff ff ff ff 00 00 00 00 .....N.......... backtrace: [<00000000151f9600>] kmem_cache_alloc_trace+0x17c/0x2f0 [<00000000ecf3dd95>] __class_register+0x86/0x49a References: - https://git.kernel.org/stable/c/4efa5443817c1b6de22d401aeca5b2481e835f8c - https://git.kernel.org/stable/c/3bb9c92c27624ad076419a70f2b1a30cd1f8bbbd - https://git.kernel.org/stable/c/3e0efc3f3f5e5c73996782f8db69963e501bb8
able/c/3bb9c92c27624ad076419a70f2b1a30cd1f8bbbd - https://git.kernel.org/stable/c/3e0efc3f3f5e5c73996782f8db69963e501bb878 - https://git.kernel.org/stable/c/18a7200646958cf8e1b8a933de08122fc50676cd - https://git.kernel.org/stable/c/417ef049e3fd3b0d2593c1d5ffa3d0d5d0a018a7 - https://git.kernel.org/stable/c/e764ad5918a099ebeb909ccff83893a714e497e1 - https://git.kernel.org/stable/c/abaedb68a769e6bf36836b55a2f49b531c5f3f7b - https://git.kernel.org/stable/c/8c3e8a6bdb5253b97ad532570f8b5db5f7a06407
CVE ID: CVE-2022-50579 State: PUBLISHED Published: 2025-10-22T13:23:32.242Z Last Updated: 2025-10-22T13:23:32.242Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: arm64: ftrace: fix module PLTs with mcount Li Huafei reports that mcount-based ftrace with module PLTs was broken by commit: a6253579977e4c6f ("arm64: ftrace: consistently handle PLTs.") When a module PLTs are used and a module is loaded sufficiently far away from the kernel, we'll create PLTs for any branches which are out-of-range. These are separate from the special ftrace trampoline PLTs, which the module PLT code doesn't directly manipulate. When mcount is in use
e from the special ftrace trampoline PLTs, which the module PLT code doesn't directly manipulate. When mcount is in use this is a problem, as each mcount callsite in a module will be initialized to point to a module PLT, but since commit a6253579977e4c6f ftrace_make_nop() will assume that the callsite has been initialized to point to the special ftrace trampoline PLT, and ftrace_find_callable_addr() rejects other cases. This means that when ftrace tries to initialize a callsite via ftrace_make_nop(), the call to ftrace_find_callable_addr() will find that the `_mcount` stub is out-of-range and is not handled by the ftrace PLT, resulting in a splat: | ftrace_test: loading out-of-tree module ta
is out-of-range and is not handled by the ftrace PLT, resulting in a splat: | ftrace_test: loading out-of-tree module taints kernel. | ftrace: no module PLT for _mcount | ------------[ ftrace bug ]------------ | ftrace failed to modify | [<ffff800029180014>] 0xffff800029180014 | actual: 44:00:00:94 | Initializing ftrace call sites | ftrace record flags: 2000000 | (0) | expected tramp: ffff80000802eb3c | ------------[ cut here ]------------ | WARNING: CPU: 3 PID: 157 at kernel/trace/ftrace.c:2120 ftrace_bug+0x94/0x270 | Modules linked in: | CPU: 3 PID: 157 Comm: insmod Tainted: G O 6.0.0-rc6-00151-gcd722513a189-dirty #22 | Hardware name: linux,dummy-virt (DT) | pstate: 60000005 (nZCv daif -PA
ed: G O 6.0.0-rc6-00151-gcd722513a189-dirty #22 | Hardware name: linux,dummy-virt (DT) | pstate: 60000005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) | pc : ftrace_bug+0x94/0x270 | lr : ftrace_bug+0x21c/0x270 | sp : ffff80000b2bbaf0 | x29: ffff80000b2bbaf0 x28: 0000000000000000 x27: ffff0000c4d38000 | x26: 0000000000000001 x25: ffff800009d7e000 x24: ffff0000c4d86e00 | x23: 0000000002000000 x22: ffff80000a62b000 x21: ffff8000098ebea8 | x20: ffff0000c4d38000 x19: ffff80000aa24158 x18: ffffffffffffffff | x17: 0000000000000000 x16: 0a0d2d2d2d2d2d2d x15: ffff800009aa9118 | x14: 0000000000000000 x13: 6333626532303830 x12: 3030303866666666 | x11: 203a706d61727420 x10: 6465746365707865 x9 : 33626
4: 0000000000000000 x13: 6333626532303830 x12: 3030303866666666 | x11: 203a706d61727420 x10: 6465746365707865 x9 : 3362653230383030 | x8 : c0000000ffffefff x7 : 0000000000017fe8 x6 : 000000000000bff4 | x5 : 0000000000057fa8 x4 : 0000000000000000 x3 : 0000000000000001 | x2 : ad2cb14bb5438900 x1 : 0000000000000000 x0 : 0000000000000022 | Call trace: | ftrace_bug+0x94/0x270 | ftrace_process_locs+0x308/0x430 | ftrace_module_init+0x44/0x60 | load_module+0x15b4/0x1ce8 | __do_sys_init_module+0x1ec/0x238 | __arm64_sys_init_module+0x24/0x30 | invoke_syscall+0x54/0x118 | el0_svc_common.constprop.4+0x84/0x100 | do_el0_svc+0x3c/0xd0 | el0_svc+0x1c/0x50 | el0t_64_sync_handler+0x90/0xb8 | el0t_64_sync+0x1
on.constprop.4+0x84/0x100 | do_el0_svc+0x3c/0xd0 | el0_svc+0x1c/0x50 | el0t_64_sync_handler+0x90/0xb8 | el0t_64_sync+0x15c/0x160 | ---[ end trace 0000000000000000 ]--- | ---------test_init----------- Fix this by reverting to the old behaviour of ignoring the old instruction when initialising an mcount callsite in a module, which was the behaviour prior to commit a6253579977e4c6f. References: - https://git.kernel.org/stable/c/657de36c72f57fa172a66b06f826b3f5bc56f42e - https://git.kernel.org/stable/c/6c93b683cedaef745884cb9d554d02ed6266b897 - https://git.kernel.org/stable/c/0f77b6b2ba70d7c9d69ef39694e283ded9f8b5f2 - https://git.kernel.org/stable/c/985432303cf7d4804fb2c2fdfbf0466a796d68c3 - htt
f77b6b2ba70d7c9d69ef39694e283ded9f8b5f2 - https://git.kernel.org/stable/c/985432303cf7d4804fb2c2fdfbf0466a796d68c3 - https://git.kernel.org/stable/c/8cfb08575c6d4585f1ce0deeb189e5c824776b04
CVE ID: CVE-2022-50580 State: PUBLISHED Published: 2025-10-22T13:23:32.808Z Last Updated: 2025-10-22T13:23:32.808Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: blk-throttle: prevent overflow while calculating wait time There is a problem found by code review in tg_with_in_bps_limit() that 'bps_limit * jiffy_elapsed_rnd' might overflow. Fix the problem by calling mul_u64_u64_div_u64() instead. References: - https://git.kernel.org/stable/c/19c010ae44f0ce52b5436080492a61a092ee0cf4 - https://git.kernel.org/stable/c/70b2adb1d698fbc63d3b3848c452524dc15872c5 - https://git.kernel.org/stable/c/cc6f0855bf8d9b729df28ff443ced7350c380dbd
e/c/70b2adb1d698fbc63d3b3848c452524dc15872c5 - https://git.kernel.org/stable/c/cc6f0855bf8d9b729df28ff443ced7350c380dbd - https://git.kernel.org/stable/c/ca67b0563b39e79290c23e509319c178b9ca9104 - https://git.kernel.org/stable/c/8d6bbaada2e0a65f9012ac4c2506460160e7237a