Kushalkhemka/embedding-cve-nvd-dataset huggingface dataset:
BIOS d55cb5a 04/01/2014 [ 25.687991][ T228] Call Trace: [ 25.688223][ T228] <TASK> [ 25.688429][ T228] dump_stack_lvl+0x73/0x9e [ 25.688747][ T228] print_report+0xea/0x200 [ 25.689061][ T228] ? copy_from_bpfptr+0x21/0x30 [ 25.689401][ T228] ? _printk+0x54/0x6e [ 25.689693][ T228] ? _raw_spin_lock_irqsave+0x70/0xd0 [ 25.690071][ T228] ? copy_from_bpfptr+0x21/0x30 [ 25.690412][ T228] kasan_report+0xb5/0xe0 [ 25.690716][ T228] ? copy_from_bpfptr+0x21/0x30 [ 25.691059][ T228] kasan_check_range+0x2bd/0x2e0 [ 25.691405][ T228] ? copy_from_bpfptr+0x21/0x30 [ 25.691734][ T228] memcpy+0x25/0x60 [ 25.692000][ T228] copy_from_bpfptr+0x21/0x30 [ 25.692328][ T228] bpf_prog_load+0x604/0x9e0 [ 25.692653][
py+0x25/0x60 [ 25.692000][ T228] copy_from_bpfptr+0x21/0x30 [ 25.692328][ T228] bpf_prog_load+0x604/0x9e0 [ 25.692653][ T228] ? cap_capable+0xb4/0xe0 [ 25.692956][ T228] ? security_capable+0x4f/0x70 [ 25.693324][ T228] __sys_bpf+0x3af/0x580 [ 25.693635][ T228] bpf_sys_bpf+0x45/0x240 [ 25.693937][ T228] bpf_prog_f0ec79a5a3caca46_bpf_func1+0xa2/0xbd [ 25.694394][ T228] bpf_prog_run_pin_on_cpu+0x2f/0xb0 [ 25.694756][ T228] bpf_prog_test_run_syscall+0x146/0x1c0 [ 25.695144][ T228] bpf_prog_test_run+0x172/0x190 [ 25.695487][ T228] __sys_bpf+0x2c5/0x580 [ 25.695776][ T228] __x64_sys_bpf+0x3a/0x50 [ 25.696084][ T228] do_syscall_64+0x60/0x90 [ 25.696393][ T228] ? fpregs_assert_state_consistent+0x50/
sys_bpf+0x3a/0x50 [ 25.696084][ T228] do_syscall_64+0x60/0x90 [ 25.696393][ T228] ? fpregs_assert_state_consistent+0x50/0x60 [ 25.696815][ T228] ? exit_to_user_mode_prepare+0x36/0xa0 [ 25.697202][ T228] ? syscall_exit_to_user_mode+0x20/0x40 [ 25.697586][ T228] ? do_syscall_64+0x6e/0x90 [ 25.697899][ T228] entry_SYSCALL_64_after_hwframe+0x63/0xcd [ 25.698312][ T228] RIP: 0033:0x7f6d543fb759 [ 25.698624][ T228] Code: 08 5b 89 e8 5d c3 66 2e 0f 1f 84 00 00 00 00 00 90 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d ---truncated--- References: - https://git.kernel.org/stable/c/41fd6cc88aaf7058b9dfc9c7a09cc80f99c8c830 - https://git.kernel.org/stable/c/1f6db7148ed7382b336c5827af33b5d9e992630e - https://git
aaf7058b9dfc9c7a09cc80f99c8c830 - https://git.kernel.org/stable/c/1f6db7148ed7382b336c5827af33b5d9e992630e - https://git.kernel.org/stable/c/e2dcac2f58f5a95ab092d1da237ffdc0da1832cf
CVE ID: CVE-2022-50070 State: PUBLISHED Published: 2025-06-18T11:02:15.240Z Last Updated: 2025-08-28T14:42:38.203Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: mptcp: do not queue data on closed subflows Dipanjan reported a syzbot splat at close time: WARNING: CPU: 1 PID: 10818 at net/ipv4/af_inet.c:153 inet_sock_destruct+0x6d0/0x8e0 net/ipv4/af_inet.c:153 Modules linked in: uio_ivshmem(OE) uio(E) CPU: 1 PID: 10818 Comm: kworker/1:16 Tainted: G OE 5.19.0-rc6-g2eae0556bb9d #2 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.13.0-1ubuntu1.1 04/01/2014 Workqueue: events mptcp_worker RIP: 0010:inet_sock_destruct+0x6d
i440FX + PIIX, 1996), BIOS 1.13.0-1ubuntu1.1 04/01/2014 Workqueue: events mptcp_worker RIP: 0010:inet_sock_destruct+0x6d0/0x8e0 net/ipv4/af_inet.c:153 Code: 21 02 00 00 41 8b 9c 24 28 02 00 00 e9 07 ff ff ff e8 34 4d 91 f9 89 ee 4c 89 e7 e8 4a 47 60 ff e9 a6 fc ff ff e8 20 4d 91 f9 <0f> 0b e9 84 fe ff ff e8 14 4d 91 f9 0f 0b e9 d4 fd ff ff e8 08 4d RSP: 0018:ffffc9001b35fa78 EFLAGS: 00010246 RAX: 0000000000000000 RBX: 00000000002879d0 RCX: ffff8881326f3b00 RDX: 0000000000000000 RSI: ffff8881326f3b00 RDI: 0000000000000002 RBP: ffff888179662674 R08: ffffffff87e983a0 R09: 0000000000000000 R10: 0000000000000005 R11: 00000000000004ea R12: ffff888179662400 R13: ffff888179662428 R14: 00000000000000
000000000000 R10: 0000000000000005 R11: 00000000000004ea R12: ffff888179662400 R13: ffff888179662428 R14: 0000000000000001 R15: ffff88817e38e258 FS: 0000000000000000(0000) GS:ffff8881f5f00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000020007bc0 CR3: 0000000179592000 CR4: 0000000000150ee0 Call Trace: <TASK> __sk_destruct+0x4f/0x8e0 net/core/sock.c:2067 sk_destruct+0xbd/0xe0 net/core/sock.c:2112 __sk_free+0xef/0x3d0 net/core/sock.c:2123 sk_free+0x78/0xa0 net/core/sock.c:2134 sock_put include/net/sock.h:1927 [inline] __mptcp_close_ssk+0x50f/0x780 net/mptcp/protocol.c:2351 __mptcp_destroy_sock+0x332/0x760 net/mptcp/protocol.c:2828 mptcp_worker+0x5d2
_ssk+0x50f/0x780 net/mptcp/protocol.c:2351 __mptcp_destroy_sock+0x332/0x760 net/mptcp/protocol.c:2828 mptcp_worker+0x5d2/0xc90 net/mptcp/protocol.c:2586 process_one_work+0x9cc/0x1650 kernel/workqueue.c:2289 worker_thread+0x623/0x1070 kernel/workqueue.c:2436 kthread+0x2e9/0x3a0 kernel/kthread.c:376 ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:302 </TASK> The root cause of the problem is that an mptcp-level (re)transmit can race with mptcp_close() and the packet scheduler checks the subflow state before acquiring the socket lock: we can try to (re)transmit on an already closed ssk. Fix the issue checking again the subflow socket status under the subflow socket lock protection. Additionall
closed ssk. Fix the issue checking again the subflow socket status under the subflow socket lock protection. Additionally add the missing check for the fallback-to-tcp case. References: - https://git.kernel.org/stable/c/fb9c73ef2ac2ec816efdc8b9267bc04e1369c20b - https://git.kernel.org/stable/c/8caf5c15b5288d52d9c89374d6c10fa32ee84ec5 - https://git.kernel.org/stable/c/c886d70286bf3ad411eb3d689328a67f7102c6ae
CVE ID: CVE-2022-50071 State: PUBLISHED Published: 2025-06-18T11:02:15.896Z Last Updated: 2025-06-18T11:02:15.896Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: mptcp: move subflow cleanup in mptcp_destroy_common() If the mptcp socket creation fails due to a CGROUP_INET_SOCK_CREATE eBPF program, the MPTCP protocol ends-up leaking all the subflows: the related cleanup happens in __mptcp_destroy_sock() that is not invoked in such code path. Address the issue moving the subflow sockets cleanup in the mptcp_destroy_common() helper, which is invoked in every msk cleanup path. Additionally get rid of the intermediate list_splice_ini
oy_common() helper, which is invoked in every msk cleanup path. Additionally get rid of the intermediate list_splice_init step, which is an unneeded relic from the past. The issue is present since before the reported root cause commit, but any attempt to backport the fix before that hash will require a complete rewrite. References: - https://git.kernel.org/stable/c/6139039c8fc5c9dbcdc3ad389b9a6d0cacb4d693 - https://git.kernel.org/stable/c/c0bf3c6aa444a5ef44acc57ef6cfa53fd4fc1c9b
CVE ID: CVE-2022-50072 State: PUBLISHED Published: 2025-06-18T11:02:16.658Z Last Updated: 2025-06-18T11:02:16.658Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: NFSv4/pnfs: Fix a use-after-free bug in open If someone cancels the open RPC call, then we must not try to free either the open slot or the layoutget operation arguments, since they are likely still in use by the hung RPC call. References: - https://git.kernel.org/stable/c/0fffb46ff3d5ed4668aca96441ec7a25b793bd6f - https://git.kernel.org/stable/c/f7ee3b772d9de87387a725caa04bc041ac7fe5ec - https://git.kernel.org/stable/c/76ffd2042438769298f34b76102b40dea89de616 - https:
3b772d9de87387a725caa04bc041ac7fe5ec - https://git.kernel.org/stable/c/76ffd2042438769298f34b76102b40dea89de616 - https://git.kernel.org/stable/c/a4cf3dadd1fa43609f7c6570c9116b0e0a9923d1 - https://git.kernel.org/stable/c/b03d1117e9be7c7da60e466eaf9beed85c5916c8 - https://git.kernel.org/stable/c/2135e5d56278ffdb1c2e6d325dc6b87f669b9dac
CVE ID: CVE-2022-50073 State: PUBLISHED Published: 2025-06-18T11:02:17.468Z Last Updated: 2025-06-18T11:02:17.468Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: net: tap: NULL pointer derefence in dev_parse_header_protocol when skb->dev is null Fixes a NULL pointer derefence bug triggered from tap driver. When tap_get_user calls virtio_net_hdr_to_skb the skb->dev is null (in tap.c skb->dev is set after the call to virtio_net_hdr_to_skb) virtio_net_hdr_to_skb calls dev_parse_header_protocol which needs skb->dev field to be valid. The line that trigers the bug is in dev_parse_header_protocol (dev is at offset 0x10 from skb and i
v field to be valid. The line that trigers the bug is in dev_parse_header_protocol (dev is at offset 0x10 from skb and is stored in RAX register) if (!dev->header_ops || !dev->header_ops->parse_protocol) 22e1: mov 0x10(%rbx),%rax 22e5: mov 0x230(%rax),%rax Setting skb->dev before the call in tap.c fixes the issue. BUG: kernel NULL pointer dereference, address: 0000000000000230 RIP: 0010:virtio_net_hdr_to_skb.constprop.0+0x335/0x410 [tap] Code: c0 0f 85 b7 fd ff ff eb d4 41 39 c6 77 cf 29 c6 48 89 df 44 01 f6 e8 7a 79 83 c1 48 85 c0 0f 85 d9 fd ff ff eb b7 48 8b 43 10 <48> 8b 80 30 02 00 00 48 85 c0 74 55 48 8b 40 28 48 85 c0 74 4c 48 RSP: 0018:ffffc90005c27c38 EFLAGS: 00010246 RAX: 000000000
b 80 30 02 00 00 48 85 c0 74 55 48 8b 40 28 48 85 c0 74 4c 48 RSP: 0018:ffffc90005c27c38 EFLAGS: 00010246 RAX: 0000000000000000 RBX: ffff888298f25300 RCX: 0000000000000010 RDX: 0000000000000005 RSI: ffffc90005c27cb6 RDI: ffff888298f25300 RBP: ffffc90005c27c80 R08: 00000000ffffffea R09: 00000000000007e8 R10: ffff88858ec77458 R11: 0000000000000000 R12: 0000000000000001 R13: 0000000000000014 R14: ffffc90005c27e08 R15: ffffc90005c27cb6 FS: 0000000000000000(0000) GS:ffff88858ec40000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000230 CR3: 0000000281408006 CR4: 00000000003706e0 Call Trace: tap_get_user+0x3f1/0x540 [tap] tap_sendmsg+0x56/0x362 [tap] ?
30 CR3: 0000000281408006 CR4: 00000000003706e0 Call Trace: tap_get_user+0x3f1/0x540 [tap] tap_sendmsg+0x56/0x362 [tap] ? get_tx_bufs+0xc2/0x1e0 [vhost_net] handle_tx_copy+0x114/0x670 [vhost_net] handle_tx+0xb0/0xe0 [vhost_net] handle_tx_kick+0x15/0x20 [vhost_net] vhost_worker+0x7b/0xc0 [vhost] ? vhost_vring_call_reset+0x40/0x40 [vhost] kthread+0xfa/0x120 ? kthread_complete_and_exit+0x20/0x20 ret_from_fork+0x1f/0x30 References: - https://git.kernel.org/stable/c/dd29648fcf69339713f2d25f7014ae905dcdfc18 - https://git.kernel.org/stable/c/4f61f133f354853bc394ec7d6028adb9b02dd701
CVE ID: CVE-2022-50074 State: PUBLISHED Published: 2025-06-18T11:02:18.140Z Last Updated: 2025-06-18T11:02:18.140Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: apparmor: Fix memleak in aa_simple_write_to_buffer() When copy_from_user failed, the memory is freed by kvfree. however the management struct and data blob are allocated independently, so only kvfree(data) cause a memleak issue here. Use aa_put_loaddata(data) to fix this issue. References: - https://git.kernel.org/stable/c/6500eb3a48ac221051b1791818a1ac74744ef617 - https://git.kernel.org/stable/c/7db182a2ebeefded86fea542fcc5d6a68bb77f58 - https://git.kernel.org/stable/
ac74744ef617 - https://git.kernel.org/stable/c/7db182a2ebeefded86fea542fcc5d6a68bb77f58 - https://git.kernel.org/stable/c/8aab4295582eb397a125d2788b829fa62b88dbf7 - https://git.kernel.org/stable/c/bf7ebebce2c25071c719fd8a2f1307e0c243c2d7 - https://git.kernel.org/stable/c/6583edbf459de2e06b9759f264c0ae27e452b97a - https://git.kernel.org/stable/c/417ea9fe972d2654a268ad66e89c8fcae67017c3
CVE ID: CVE-2022-50075 State: PUBLISHED Published: 2025-06-18T11:02:18.851Z Last Updated: 2025-06-18T11:02:18.851Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: tracing/eprobes: Have event probes be consistent with kprobes and uprobes Currently, if a symbol "@" is attempted to be used with an event probe (eprobes), it will cause a NULL pointer dereference crash. Both kprobes and uprobes can reference data other than the main registers. Such as immediate address, symbols and the current task name. Have eprobes do the same thing. For "comm", if "comm" is used and the event being attached to does not have the "comm" field, then m
do the same thing. For "comm", if "comm" is used and the event being attached to does not have the "comm" field, then make it the "$comm" that kprobes has. This is consistent to the way histograms and filters work. References: - https://git.kernel.org/stable/c/b489aca082a23033a3d8355cfb0032f0e2523440 - https://git.kernel.org/stable/c/47cc883f21fa3bcf24891b4b455f4cd461ce2d6e - https://git.kernel.org/stable/c/6a832ec3d680b3a4f4fad5752672827d71bae501
CVE ID: CVE-2022-50076 State: PUBLISHED Published: 2025-06-18T11:02:19.514Z Last Updated: 2025-06-18T11:02:19.514Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: cifs: Fix memory leak on the deferred close xfstests on smb21 report kmemleak as below: unreferenced object 0xffff8881767d6200 (size 64): comm "xfs_io", pid 1284, jiffies 4294777434 (age 20.789s) hex dump (first 32 bytes): 80 5a d0 11 81 88 ff ff 78 8a aa 63 81 88 ff ff .Z......x..c.... 00 71 99 76 81 88 ff ff 00 00 00 00 00 00 00 00 .q.v............ backtrace: [<00000000ad04e6ea>] cifs_close+0x92/0x2c0 [<0000000028b93c82>] __fput+0xff/0x3f0 [<00000000d8116851>] task_w
backtrace: [<00000000ad04e6ea>] cifs_close+0x92/0x2c0 [<0000000028b93c82>] __fput+0xff/0x3f0 [<00000000d8116851>] task_work_run+0x85/0xc0 [<0000000027e14f9e>] do_exit+0x5e5/0x1240 [<00000000fb492b95>] do_group_exit+0x58/0xe0 [<00000000129a32d9>] __x64_sys_exit_group+0x28/0x30 [<00000000e3f7d8e9>] do_syscall_64+0x35/0x80 [<00000000102e8a0b>] entry_SYSCALL_64_after_hwframe+0x46/0xb0 When cancel the deferred close work, we should also cleanup the struct cifs_deferred_close. References: - https://git.kernel.org/stable/c/860efae127888ae535bc4eda1b7f27642727c69e - https://git.kernel.org/stable/c/60b6d38add7b9c17d6e5d49ee8e930ea1a5650c5 - https://git.kernel.org/stable/c/ca08d0eac020d48a3141dbec0a3c
nel.org/stable/c/60b6d38add7b9c17d6e5d49ee8e930ea1a5650c5 - https://git.kernel.org/stable/c/ca08d0eac020d48a3141dbec0a3cf64fbdb17cde
CVE ID: CVE-2022-50077 State: PUBLISHED Published: 2025-06-18T11:02:20.318Z Last Updated: 2025-06-18T11:02:20.318Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: apparmor: fix reference count leak in aa_pivotroot() The aa_pivotroot() function has a reference counting bug in a specific path. When aa_replace_current_label() returns on success, the function forgets to decrement the reference count of “target”, which is increased earlier by build_pivotroot(), causing a reference leak. Fix it by decreasing the refcount of “target” in that path. References: - https://git.kernel.org/stable/c/d53194707d2a1851be027cd74266b96ceff799d3 -
ount of “target” in that path. References: - https://git.kernel.org/stable/c/d53194707d2a1851be027cd74266b96ceff799d3 - https://git.kernel.org/stable/c/f4d5c7796571624e3f380b447ada52834270a287 - https://git.kernel.org/stable/c/ef6fb6f0d0d8440595b45a7e53c6162c737177f4 - https://git.kernel.org/stable/c/2ceeb3296e9dde1d5772348046affcefdea605e2 - https://git.kernel.org/stable/c/64103ea357734b82384c925cba4758fdb909be0c - https://git.kernel.org/stable/c/3ca40ad7afae144169a43988ef1a3f16182faf0a - https://git.kernel.org/stable/c/11c3627ec6b56c1525013f336f41b79a983b4d46
CVE ID: CVE-2022-50078 State: PUBLISHED Published: 2025-06-18T11:02:21.119Z Last Updated: 2025-06-18T11:02:21.119Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: tracing/eprobes: Do not allow eprobes to use $stack, or % for regs While playing with event probes (eprobes), I tried to see what would happen if I attempted to retrieve the instruction pointer (%rip) knowing that event probes do not use pt_regs. The result was: BUG: kernel NULL pointer dereference, address: 0000000000000024 #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page PGD 0 P4D 0 Oops: 0000 [#1] PREEMPT SMP PTI CPU: 1 PID: 1847
s in kernel mode #PF: error_code(0x0000) - not-present page PGD 0 P4D 0 Oops: 0000 [#1] PREEMPT SMP PTI CPU: 1 PID: 1847 Comm: trace-cmd Not tainted 5.19.0-rc5-test+ #309 Hardware name: Hewlett-Packard HP Compaq Pro 6300 SFF/339A, BIOS K01 v03.03 07/14/2016 RIP: 0010:get_event_field.isra.0+0x0/0x50 Code: ff 48 c7 c7 c0 8f 74 a1 e8 3d 8b f5 ff e8 88 09 f6 ff 4c 89 e7 e8 50 6a 13 00 48 89 ef 5b 5d 41 5c 41 5d e9 42 6a 13 00 66 90 <48> 63 47 24 8b 57 2c 48 01 c6 8b 47 28 83 f8 02 74 0e 83 f8 04 74 RSP: 0018:ffff916c394bbaf0 EFLAGS: 00010086 RAX: ffff916c854041d8 RBX: ffff916c8d9fbf50 RCX: ffff916c255d2000 RDX: 0000000000000000 RSI: ffff916c255d2008 RDI: 0000000000000000 RBP: 0000000000000000 R0
d9fbf50 RCX: ffff916c255d2000 RDX: 0000000000000000 RSI: ffff916c255d2008 RDI: 0000000000000000 RBP: 0000000000000000 R08: ffff916c3a2a0c08 R09: ffff916c394bbda8 R10: 0000000000000000 R11: 0000000000000000 R12: ffff916c854041d8 R13: ffff916c854041b0 R14: 0000000000000000 R15: 0000000000000000 FS: 0000000000000000(0000) GS:ffff916c9ea40000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000024 CR3: 000000011b60a002 CR4: 00000000001706e0 Call Trace: <TASK> get_eprobe_size+0xb4/0x640 ? __mod_node_page_state+0x72/0xc0 __eprobe_trace_func+0x59/0x1a0 ? __mod_lruvec_page_state+0xaa/0x1b0 ? page_remove_file_rmap+0x14/0x230 ? page_remove_rmap+0xda/0x170 ev
func+0x59/0x1a0 ? __mod_lruvec_page_state+0xaa/0x1b0 ? page_remove_file_rmap+0x14/0x230 ? page_remove_rmap+0xda/0x170 event_triggers_call+0x52/0xe0 trace_event_buffer_commit+0x18f/0x240 trace_event_raw_event_sched_wakeup_template+0x7a/0xb0 try_to_wake_up+0x260/0x4c0 __wake_up_common+0x80/0x180 __wake_up_common_lock+0x7c/0xc0 do_notify_parent+0x1c9/0x2a0 exit_notify+0x1a9/0x220 do_exit+0x2ba/0x450 do_group_exit+0x2d/0x90 __x64_sys_exit_group+0x14/0x20 do_syscall_64+0x3b/0x90 entry_SYSCALL_64_after_hwframe+0x46/0xb0 Obviously this is not the desired result. Move the testing for TPARG_FL_TPOINT which is only used for event probes to the top of the "$" variable check, as all the other variables
or TPARG_FL_TPOINT which is only used for event probes to the top of the "$" variable check, as all the other variables are not used for event probes. Also add a check in the register parsing "%" to fail if an event probe is used. References: - https://git.kernel.org/stable/c/ba53c21ce9773743b8e0a8ada048c96ff2d55c67 - https://git.kernel.org/stable/c/7c262114a576d94c0ced80e232bbb17391a55908 - https://git.kernel.org/stable/c/2673c60ee67e71f2ebe34386e62d348f71edee47
CVE ID: CVE-2022-50079 State: PUBLISHED Published: 2025-06-18T11:02:22.235Z Last Updated: 2025-06-18T11:02:22.235Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Check correct bounds for stream encoder instances for DCN303 [Why & How] eng_id for DCN303 cannot be more than 1, since we have only two instances of stream encoders. Check the correct boundary condition for engine ID for DCN303 prevent the potential out of bounds access. References: - https://git.kernel.org/stable/c/82a27c1855445d48aacc67b0c0640f3dadebe52f - https://git.kernel.org/stable/c/4c31dca1799612eb3b6413e3e574f90c3fb8f865 - https://git.kernel.
acc67b0c0640f3dadebe52f - https://git.kernel.org/stable/c/4c31dca1799612eb3b6413e3e574f90c3fb8f865 - https://git.kernel.org/stable/c/89b008222c2bf21e50219725caed31590edfd9d1
CVE ID: CVE-2022-50080 State: PUBLISHED Published: 2025-06-18T11:02:23.003Z Last Updated: 2025-06-18T11:02:23.003Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: tee: add overflow check in register_shm_helper() With special lengths supplied by user space, register_shm_helper() has an integer overflow when calculating the number of pages covered by a supplied user space memory region. This causes internal_get_user_pages_fast() a helper function of pin_user_pages_fast() to do a NULL pointer dereference: Unable to handle kernel NULL pointer dereference at virtual address 0000000000000010 Modules linked in: CPU: 1 PID: 173 Comm: op
o handle kernel NULL pointer dereference at virtual address 0000000000000010 Modules linked in: CPU: 1 PID: 173 Comm: optee_example_a Not tainted 5.19.0 #11 Hardware name: QEMU QEMU Virtual Machine, BIOS 0.0.0 02/06/2015 pc : internal_get_user_pages_fast+0x474/0xa80 Call trace: internal_get_user_pages_fast+0x474/0xa80 pin_user_pages_fast+0x24/0x4c register_shm_helper+0x194/0x330 tee_shm_register_user_buf+0x78/0x120 tee_ioctl+0xd0/0x11a0 __arm64_sys_ioctl+0xa8/0xec invoke_syscall+0x48/0x114 Fix this by adding an an explicit call to access_ok() in tee_shm_register_user_buf() to catch an invalid user space address early. References: - https://git.kernel.org/stable/c/b37e0f17653c00b586cdbcdf0dbc
to catch an invalid user space address early. References: - https://git.kernel.org/stable/c/b37e0f17653c00b586cdbcdf0dbca475358ecffd - https://git.kernel.org/stable/c/965333345fe952cc7eebc8e3a565ffc709441af2 - https://git.kernel.org/stable/c/578c349570d2a912401963783b36e0ec7a25c053 - https://git.kernel.org/stable/c/c12f0e6126ad223806a365084e86370511654bf1 - https://git.kernel.org/stable/c/2f8e79a1a6128214cb9b205a9869341af5dfb16b - https://git.kernel.org/stable/c/58c008d4d398f792ca67f35650610864725518fd - https://git.kernel.org/stable/c/573ae4f13f630d6660008f1974c0a8a29c30e18a
CVE ID: CVE-2022-50081 State: REJECTED Published: 2025-06-18T11:02:23.818Z Last Updated: 2025-06-18T14:08:40.619Z Description: No description available.
CVE ID: CVE-2022-50082 State: PUBLISHED Published: 2025-06-18T11:02:24.530Z Last Updated: 2025-06-18T11:02:24.530Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: ext4: fix warning in ext4_iomap_begin as race between bmap and write We got issue as follows: ------------[ cut here ]------------ WARNING: CPU: 3 PID: 9310 at fs/ext4/inode.c:3441 ext4_iomap_begin+0x182/0x5d0 RIP: 0010:ext4_iomap_begin+0x182/0x5d0 RSP: 0018:ffff88812460fa08 EFLAGS: 00010293 RAX: ffff88811f168000 RBX: 0000000000000000 RCX: ffffffff97793c12 RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000003 RBP: ffff88812c669160 R08: ffff88811f168000 R09:
93c12 RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000003 RBP: ffff88812c669160 R08: ffff88811f168000 R09: ffffed10258cd20f R10: ffff88812c669077 R11: ffffed10258cd20e R12: 0000000000000001 R13: 00000000000000a4 R14: 000000000000000c R15: ffff88812c6691ee FS: 00007fd0d6ff3740(0000) GS:ffff8883af180000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007fd0d6dda290 CR3: 0000000104a62000 CR4: 00000000000006e0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: iomap_apply+0x119/0x570 iomap_bmap+0x124/0x150 ext4_bmap+0x14f/0x250 bmap+0x55/0x80 do_vfs_ioct
000000000400 Call Trace: iomap_apply+0x119/0x570 iomap_bmap+0x124/0x150 ext4_bmap+0x14f/0x250 bmap+0x55/0x80 do_vfs_ioctl+0x952/0xbd0 __x64_sys_ioctl+0xc6/0x170 do_syscall_64+0x33/0x40 entry_SYSCALL_64_after_hwframe+0x44/0xa9 Above issue may happen as follows: bmap write bmap ext4_bmap iomap_bmap ext4_iomap_begin ext4_file_write_iter ext4_buffered_write_iter generic_perform_write ext4_da_write_begin ext4_da_write_inline_data_begin ext4_prepare_inline_data ext4_create_inline_data ext4_set_inode_flag(inode, EXT4_INODE_INLINE_DATA); if (WARN_ON_ONCE(ext4_has_inline_data(inode))) ->trigger bug_on To solved above issue hold inode lock in ext4_bamp. References: - https://git.kernel.org/stable/c/e1
)) ->trigger bug_on To solved above issue hold inode lock in ext4_bamp. References: - https://git.kernel.org/stable/c/e1682c7171a6c0ff576fe8116b8cba5b8f538b94 - https://git.kernel.org/stable/c/30dfb75e1f8645404a536c74d468d498adcd4e74 - https://git.kernel.org/stable/c/a9fe6d1e3d343d7309f501b1f48020ce7127221f - https://git.kernel.org/stable/c/fa6482f374fda29a71ad44d76d35b4842d43cda4 - https://git.kernel.org/stable/c/51ae846cff568c8c29921b1b28eb2dfbcd4ac12d
CVE ID: CVE-2022-50083 State: REJECTED Published: 2025-06-18T11:02:25.260Z Last Updated: 2025-08-20T14:31:54.137Z Description: No description available.