Kushalkhemka/embedding-cve-nvd-dataset huggingface dataset:
ne: https://git.linuxtv.org/media_stage.git/commit/?id=2b064d91440b33fba5b452f2d1b31f13ae911d71. We believe the bug can be also dynamically triggered from user side. Similarly, we fix this by checking the return value of cx23885_risc_buffer() and the value of risc->cpu before buffer free. References: - https://git.kernel.org/stable/c/f0a06203f2fe63f04311467200c99c4ee1926578 - https://git.kernel.org/stable/c/6738841f6fcf23e9fc30e2449f32fc84ee19c6f1 - https://git.kernel.org/stable/c/5b8e5e28e85a546dfccc3895befe0e823fdd7c89 - https://git.kernel.org/stable/c/47e8b73bc35d7c54642f78e498697692f6358996
CVE ID: CVE-2023-53459 State: PUBLISHED Published: 2025-10-01T11:42:30.648Z Last Updated: 2025-10-01T11:42:30.648Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: HID: mcp-2221: prevent UAF in delayed work If the device is plugged/unplugged without giving time for mcp_init_work() to complete, we might kick in the devm free code path and thus have unavailable struct mcp_2221 while in delayed work. Canceling the delayed_work item is enough to solve the issue, because cancel_delayed_work_sync will prevent the work item to requeue itself. References: - https://git.kernel.org/stable/c/5dc297652dbc557eba7ca7d6a4c5f1940dffffb1 - https:
item to requeue itself. References: - https://git.kernel.org/stable/c/5dc297652dbc557eba7ca7d6a4c5f1940dffffb1 - https://git.kernel.org/stable/c/47e91fdfa511139f2549687edb0d8649b123227b
CVE ID: CVE-2023-53460 State: PUBLISHED Published: 2025-10-01T11:42:31.620Z Last Updated: 2025-10-02T07:04:21.343Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: wifi: rtw88: fix memory leak in rtw_usb_probe() drivers/net/wireless/realtek/rtw88/usb.c:876 rtw_usb_probe() warn: 'hw' from ieee80211_alloc_hw() not released on lines: 811 Fix this by modifying return to a goto statement. References: - https://git.kernel.org/stable/c/6cc92379b80af005e1f49ef6ef790cddc58cf0da - https://git.kernel.org/stable/c/48181d285623198c33bb9698992502687b258efa
CVE ID: CVE-2023-53461 State: PUBLISHED Published: 2025-10-01T11:42:32.525Z Last Updated: 2025-10-02T07:04:22.533Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: io_uring: wait interruptibly for request completions on exit WHen the ring exits, cleanup is done and the final cancelation and waiting on completions is done by io_ring_exit_work. That function is invoked by kworker, which doesn't take any signals. Because of that, it doesn't really matter if we wait for completions in TASK_INTERRUPTIBLE or TASK_UNINTERRUPTIBLE state. However, it does matter to the hung task detection checker! Normally we expect cancelations and compl
TERRUPTIBLE state. However, it does matter to the hung task detection checker! Normally we expect cancelations and completions to happen rather quickly. Some test cases, however, will exit the ring and park the owning task stopped (eg via SIGSTOP). If the owning task needs to run task_work to complete requests, then io_ring_exit_work won't make any progress until the task is runnable again. Hence io_ring_exit_work can trigger the hung task detection, which is particularly problematic if panic-on-hung-task is enabled. As the ring exit doesn't take signals to begin with, have it wait interruptibly rather than uninterruptibly. io_uring has a separate stuck-exit warning that triggers independent
it wait interruptibly rather than uninterruptibly. io_uring has a separate stuck-exit warning that triggers independently anyway, so we're not really missing anything by making this switch. References: - https://git.kernel.org/stable/c/28e649dc9947e6525c95e32aa9a8e147925e3f56 - https://git.kernel.org/stable/c/8e29835366138389bfad3b31ea06960d0a77bf77 - https://git.kernel.org/stable/c/b50d6e06cca7b67a3d73ca660dda27662b76e6ea - https://git.kernel.org/stable/c/58e80cb68b057e974768792c34708c6957810486 - https://git.kernel.org/stable/c/4826c59453b3b4677d6bf72814e7ababdea86949
CVE ID: CVE-2023-53462 State: PUBLISHED Published: 2025-10-01T11:42:33.434Z Last Updated: 2025-10-01T11:42:33.434Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: hsr: Fix uninit-value access in fill_frame_info() Syzbot reports the following uninit-value access problem. ===================================================== BUG: KMSAN: uninit-value in fill_frame_info net/hsr/hsr_forward.c:601 [inline] BUG: KMSAN: uninit-value in hsr_forward_skb+0x9bd/0x30f0 net/hsr/hsr_forward.c:616 fill_frame_info net/hsr/hsr_forward.c:601 [inline] hsr_forward_skb+0x9bd/0x30f0 net/hsr/hsr_forward.c:616 hsr_dev_xmit+0x192/0x330 net/hsr/hsr_device
orward.c:601 [inline] hsr_forward_skb+0x9bd/0x30f0 net/hsr/hsr_forward.c:616 hsr_dev_xmit+0x192/0x330 net/hsr/hsr_device.c:223 __netdev_start_xmit include/linux/netdevice.h:4889 [inline] netdev_start_xmit include/linux/netdevice.h:4903 [inline] xmit_one net/core/dev.c:3544 [inline] dev_hard_start_xmit+0x247/0xa10 net/core/dev.c:3560 __dev_queue_xmit+0x34d0/0x52a0 net/core/dev.c:4340 dev_queue_xmit include/linux/netdevice.h:3082 [inline] packet_xmit+0x9c/0x6b0 net/packet/af_packet.c:276 packet_snd net/packet/af_packet.c:3087 [inline] packet_sendmsg+0x8b1d/0x9f30 net/packet/af_packet.c:3119 sock_sendmsg_nosec net/socket.c:730 [inline] sock_sendmsg net/socket.c:753 [inline] __sys_sendto+0x781/0
f_packet.c:3119 sock_sendmsg_nosec net/socket.c:730 [inline] sock_sendmsg net/socket.c:753 [inline] __sys_sendto+0x781/0xa30 net/socket.c:2176 __do_sys_sendto net/socket.c:2188 [inline] __se_sys_sendto net/socket.c:2184 [inline] __ia32_sys_sendto+0x11f/0x1c0 net/socket.c:2184 do_syscall_32_irqs_on arch/x86/entry/common.c:112 [inline] __do_fast_syscall_32+0xa2/0x100 arch/x86/entry/common.c:178 do_fast_syscall_32+0x37/0x80 arch/x86/entry/common.c:203 do_SYSENTER_32+0x1f/0x30 arch/x86/entry/common.c:246 entry_SYSENTER_compat_after_hwframe+0x70/0x82 Uninit was created at: slab_post_alloc_hook+0x12f/0xb70 mm/slab.h:767 slab_alloc_node mm/slub.c:3478 [inline] kmem_cache_alloc_node+0x577/0xa80 mm/s
post_alloc_hook+0x12f/0xb70 mm/slab.h:767 slab_alloc_node mm/slub.c:3478 [inline] kmem_cache_alloc_node+0x577/0xa80 mm/slub.c:3523 kmalloc_reserve+0x148/0x470 net/core/skbuff.c:559 __alloc_skb+0x318/0x740 net/core/skbuff.c:644 alloc_skb include/linux/skbuff.h:1286 [inline] alloc_skb_with_frags+0xc8/0xbd0 net/core/skbuff.c:6299 sock_alloc_send_pskb+0xa80/0xbf0 net/core/sock.c:2794 packet_alloc_skb net/packet/af_packet.c:2936 [inline] packet_snd net/packet/af_packet.c:3030 [inline] packet_sendmsg+0x70e8/0x9f30 net/packet/af_packet.c:3119 sock_sendmsg_nosec net/socket.c:730 [inline] sock_sendmsg net/socket.c:753 [inline] __sys_sendto+0x781/0xa30 net/socket.c:2176 __do_sys_sendto net/socket.c:21
nline] sock_sendmsg net/socket.c:753 [inline] __sys_sendto+0x781/0xa30 net/socket.c:2176 __do_sys_sendto net/socket.c:2188 [inline] __se_sys_sendto net/socket.c:2184 [inline] __ia32_sys_sendto+0x11f/0x1c0 net/socket.c:2184 do_syscall_32_irqs_on arch/x86/entry/common.c:112 [inline] __do_fast_syscall_32+0xa2/0x100 arch/x86/entry/common.c:178 do_fast_syscall_32+0x37/0x80 arch/x86/entry/common.c:203 do_SYSENTER_32+0x1f/0x30 arch/x86/entry/common.c:246 entry_SYSENTER_compat_after_hwframe+0x70/0x82 It is because VLAN not yet supported in hsr driver. Return error when protocol is ETH_P_8021Q in fill_frame_info() now to fix it. References: - https://git.kernel.org/stable/c/1e90a93ac4845c31724ec5dc96
ETH_P_8021Q in fill_frame_info() now to fix it. References: - https://git.kernel.org/stable/c/1e90a93ac4845c31724ec5dc96fb51e608435a9d - https://git.kernel.org/stable/c/6a4480c5e6ebaf9f797ac300e2a97a02d4e70cfd - https://git.kernel.org/stable/c/61866f7d814e5792bf47410d7d3ff32e49bd292a - https://git.kernel.org/stable/c/ed7a0ba7e840dc5d54cdbd8466be27e6aedce1e5 - https://git.kernel.org/stable/c/484b4833c604c0adcf19eac1ca14b60b757355b5
CVE ID: CVE-2023-53463 State: PUBLISHED Published: 2025-10-01T11:42:34.308Z Last Updated: 2025-10-01T11:42:34.308Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: ibmvnic: Do not reset dql stats on NON_FATAL err All ibmvnic resets, make a call to netdev_tx_reset_queue() when re-opening the device. netdev_tx_reset_queue() resets the num_queued and num_completed byte counters. These stats are used in Byte Queue Limit (BQL) algorithms. The difference between these two stats tracks the number of bytes currently sitting on the physical NIC. ibmvnic increases the number of queued bytes though calls to netdev_tx_sent_queue() in the dri
ting on the physical NIC. ibmvnic increases the number of queued bytes though calls to netdev_tx_sent_queue() in the drivers xmit function. When, VIOS reports that it is done transmitting bytes, the ibmvnic device increases the number of completed bytes through calls to netdev_tx_completed_queue(). It is important to note that the driver batches its transmit calls and num_queued is increased every time that an skb is added to the next batch, not necessarily when the batch is sent to VIOS for transmission. Unlike other reset types, a NON FATAL reset will not flush the sub crq tx buffers. Therefore, it is possible for the batched skb array to be partially full. So if there is call to netdev_tx
q tx buffers. Therefore, it is possible for the batched skb array to be partially full. So if there is call to netdev_tx_reset_queue() when re-opening the device, the value of num_queued (0) would not account for the skb's that are currently batched. Eventually, when the batch is sent to VIOS, the call to netdev_tx_completed_queue() would increase num_completed to a value greater than the num_queued. This causes a BUG_ON crash: ibmvnic 30000002: Firmware reports error, cause: adapter problem. Starting recovery... ibmvnic 30000002: tx error 600 ibmvnic 30000002: tx error 600 ibmvnic 30000002: tx error 600 ibmvnic 30000002: tx error 600 ------------[ cut here ]------------ kernel BUG at lib/dy
ibmvnic 30000002: tx error 600 ibmvnic 30000002: tx error 600 ------------[ cut here ]------------ kernel BUG at lib/dynamic_queue_limits.c:27! Oops: Exception in kernel mode, sig: 5 [....] NIP dql_completed+0x28/0x1c0 LR ibmvnic_complete_tx.isra.0+0x23c/0x420 [ibmvnic] Call Trace: ibmvnic_complete_tx.isra.0+0x3f8/0x420 [ibmvnic] (unreliable) ibmvnic_interrupt_tx+0x40/0x70 [ibmvnic] __handle_irq_event_percpu+0x98/0x270 ---[ end trace ]--- Therefore, do not reset the dql stats when performing a NON_FATAL reset. References: - https://git.kernel.org/stable/c/b8aedf29db1280c83191fc9579ae605791faf97f - https://git.kernel.org/stable/c/f67ef8f9f6776e2b2073cad7c5cf29de850f83d7 - https://git.kernel.
191fc9579ae605791faf97f - https://git.kernel.org/stable/c/f67ef8f9f6776e2b2073cad7c5cf29de850f83d7 - https://git.kernel.org/stable/c/91a0632e73070928aafeb36b3cc676843c716931 - https://git.kernel.org/stable/c/48538ccb825b05544ec308a509e2cc9c013402db
CVE ID: CVE-2023-53464 State: PUBLISHED Published: 2025-10-01T11:42:35.186Z Last Updated: 2025-10-01T11:42:35.186Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: scsi: iscsi_tcp: Check that sock is valid before iscsi_set_param() The validity of sock should be checked before assignment to avoid incorrect values. Commit 57569c37f0ad ("scsi: iscsi: iscsi_tcp: Fix null-ptr-deref while calling getpeername()") introduced this change which may lead to inconsistent values of tcp_sw_conn->sendpage and conn->datadgst_en. Fix the issue by moving the position of the assignment. References: - https://git.kernel.org/stable/c/499757ad3332e252
. Fix the issue by moving the position of the assignment. References: - https://git.kernel.org/stable/c/499757ad3332e2527254f9ab68dec1da087b1d96 - https://git.kernel.org/stable/c/5e5c5f472972c4bc9430adc08b36763a0fa5b9f7 - https://git.kernel.org/stable/c/6e06a68fbbfcd8576eee8f7139fa2b13c9b72e91 - https://git.kernel.org/stable/c/b287e21e73ec23f3788fbe40037c42dbe6e9a9a9 - https://git.kernel.org/stable/c/48b19b79cfa37b1e50da3b5a8af529f994c08901
CVE ID: CVE-2023-53465 State: PUBLISHED Published: 2025-10-01T11:42:36.007Z Last Updated: 2025-10-01T11:42:36.007Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: soundwire: qcom: fix storing port config out-of-bounds The 'qcom_swrm_ctrl->pconfig' has size of QCOM_SDW_MAX_PORTS (14), however we index it starting from 1, not 0, to match real port numbers. This can lead to writing port config past 'pconfig' bounds and overwriting next member of 'qcom_swrm_ctrl' struct. Reported also by smatch: drivers/soundwire/qcom.c:1269 qcom_swrm_get_port_config() error: buffer overflow 'ctrl->pconfig' 14 <= 14 References: - https://git.kernel.
com.c:1269 qcom_swrm_get_port_config() error: buffer overflow 'ctrl->pconfig' 14 <= 14 References: - https://git.kernel.org/stable/c/20f7c4d51c94abb1a1a7c21900db4fb5afe5c8ff - https://git.kernel.org/stable/c/801daff0078087b5df9145c9f5e643c28129734b - https://git.kernel.org/stable/c/32eb67d7360d48c15883e0d21b29c0aab9da022e - https://git.kernel.org/stable/c/490937d479abe5f6584e69b96df066bc87be92e9
CVE ID: CVE-2023-53466 State: PUBLISHED Published: 2025-10-01T11:42:36.809Z Last Updated: 2025-10-01T11:42:36.809Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: wifi: mt76: mt7915: fix memory leak in mt7915_mcu_exit Always purge mcu skb queues in mt7915_mcu_exit routine even if mt7915_firmware_state fails. References: - https://git.kernel.org/stable/c/4cbb876153b63fe248200f734069c6881cf97722 - https://git.kernel.org/stable/c/3095fe1e1d3198e62a3c7116c4cf7c734871475f - https://git.kernel.org/stable/c/49bd78282e79ad177d14f37f4049f0605bf92dad
CVE ID: CVE-2023-53467 State: PUBLISHED Published: 2025-10-01T11:42:37.757Z Last Updated: 2025-10-01T11:42:37.757Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: wifi: rtw89: fix potential leak in rtw89_append_probe_req_ie() Do `kfree_skb(new)` before `goto out` to prevent potential leak. References: - https://git.kernel.org/stable/c/1e336d6bab68973084a18c1e4bd78cd0bbbdcacd - https://git.kernel.org/stable/c/a10b6d73123bd480751d916575835abb615072fd - https://git.kernel.org/stable/c/4a0e218cc9c42d1903ade8b5a371dcf48cf918c5
CVE ID: CVE-2023-53468 State: PUBLISHED Published: 2025-10-01T11:42:38.673Z Last Updated: 2025-10-01T11:42:38.673Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: ubifs: Fix memory leak in alloc_wbufs() kmemleak reported a sequence of memory leaks, and show them as following: unreferenced object 0xffff8881575f8400 (size 1024): comm "mount", pid 19625, jiffies 4297119604 (age 20.383s) hex dump (first 32 bytes): 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ backtrace: [<ffffffff8176cecd>] __kmalloc+0x4d/0x150 [<ffffffffa0406b2b>] ubifs_mount+0x307b
0 00 00 00 ................ backtrace: [<ffffffff8176cecd>] __kmalloc+0x4d/0x150 [<ffffffffa0406b2b>] ubifs_mount+0x307b/0x7170 [ubifs] [<ffffffff819fa8fd>] legacy_get_tree+0xed/0x1d0 [<ffffffff81936f2d>] vfs_get_tree+0x7d/0x230 [<ffffffff819b2bd4>] path_mount+0xdd4/0x17b0 [<ffffffff819b37aa>] __x64_sys_mount+0x1fa/0x270 [<ffffffff83c14295>] do_syscall_64+0x35/0x80 [<ffffffff83e0006a>] entry_SYSCALL_64_after_hwframe+0x46/0xb0 unreferenced object 0xffff8881798a6e00 (size 512): comm "mount", pid 19677, jiffies 4297121912 (age 37.816s) hex dump (first 32 bytes): 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk back
6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk backtrace: [<ffffffff8176cecd>] __kmalloc+0x4d/0x150 [<ffffffffa0418342>] ubifs_wbuf_init+0x52/0x480 [ubifs] [<ffffffffa0406ca5>] ubifs_mount+0x31f5/0x7170 [ubifs] [<ffffffff819fa8fd>] legacy_get_tree+0xed/0x1d0 [<ffffffff81936f2d>] vfs_get_tree+0x7d/0x230 [<ffffffff819b2bd4>] path_mount+0xdd4/0x17b0 [<ffffffff819b37aa>] __x64_sys_mount+0x1fa/0x270 [<ffffffff83c14295>] do_syscall_64+0x35/0x80 [<ffffffff83e0006a>] entry_SYSCALL_64_after_hwframe+0x46/0xb0 The problem is that the ubifs_wbuf_init() returns an error in the loop which in the alloc_wbufs(), then the wbuf->buf and wbuf
oblem is that the ubifs_wbuf_init() returns an error in the loop which in the alloc_wbufs(), then the wbuf->buf and wbuf->inodes that were successfully alloced before are not freed. Fix it by adding error hanging path in alloc_wbufs() which frees the memory alloced before when ubifs_wbuf_init() returns an error. References: - https://git.kernel.org/stable/c/1f206002c6bc302bface871ef3f72c0bbcaa931c - https://git.kernel.org/stable/c/bf50229494f0443b3f08427d7df63e5a7e2a796a - https://git.kernel.org/stable/c/3e29634eb56e6547272fe4e568f63421f8b3b9fa - https://git.kernel.org/stable/c/26ec45f1c504e15268383019df139d7983f1e67f - https://git.kernel.org/stable/c/e11f36d3bc4d23f620754a948fe7b82b63dcb185
le/c/26ec45f1c504e15268383019df139d7983f1e67f - https://git.kernel.org/stable/c/e11f36d3bc4d23f620754a948fe7b82b63dcb185 - https://git.kernel.org/stable/c/4a1ff3c5d04b9079b4f768d9a71b51c4af578dd2
CVE ID: CVE-2023-53469 State: PUBLISHED Published: 2025-10-01T11:42:39.467Z Last Updated: 2025-10-10T16:08:37.029Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: af_unix: Fix null-ptr-deref in unix_stream_sendpage(). Bing-Jhong Billy Jheng reported null-ptr-deref in unix_stream_sendpage() with detailed analysis and a nice repro. unix_stream_sendpage() tries to add data to the last skb in the peer's recv queue without locking the queue. If the peer's FD is passed to another socket and the socket's FD is passed to the peer, there is a loop between them. If we close both sockets without receiving FD, the sockets will be cleaned up
to the peer, there is a loop between them. If we close both sockets without receiving FD, the sockets will be cleaned up by garbage collection. The garbage collection iterates such sockets and unlinks skb with FD from the socket's receive queue under the queue's lock. So, there is a race where unix_stream_sendpage() could access an skb locklessly that is being released by garbage collection, resulting in use-after-free. To avoid the issue, unix_stream_sendpage() must lock the peer's recv queue. Note the issue does not exist in 6.5+ thanks to the recent sendpage() refactoring. This patch is originally written by Linus Torvalds. BUG: unable to handle page fault for address: ffff988004dd6870 PF
g. This patch is originally written by Linus Torvalds. BUG: unable to handle page fault for address: ffff988004dd6870 PF: supervisor read access in kernel mode PF: error_code(0x0000) - not-present page PGD 0 P4D 0 PREEMPT SMP PTI CPU: 4 PID: 297 Comm: garbage_uaf Not tainted 6.1.46 #1 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.0-0-gd239552ce722-prebuilt.qemu.org 04/01/2014 RIP: 0010:kmem_cache_alloc_node+0xa2/0x1e0 Code: c0 0f 84 32 01 00 00 41 83 fd ff 74 10 48 8b 00 48 c1 e8 3a 41 39 c5 0f 85 1c 01 00 00 41 8b 44 24 28 49 8b 3c 24 48 8d 4a 40 <49> 8b 1c 06 4c 89 f0 65 48 0f c7 0f 0f 94 c0 84 c0 74 a1 41 8b 44 RSP: 0018:ffffc9000079fac0 EFLAGS: 00000246 RAX: 000000
> 8b 1c 06 4c 89 f0 65 48 0f c7 0f 0f 94 c0 84 c0 74 a1 41 8b 44 RSP: 0018:ffffc9000079fac0 EFLAGS: 00000246 RAX: 0000000000000070 RBX: 0000000000000005 RCX: 000000000001a284 RDX: 000000000001a244 RSI: 0000000000400cc0 RDI: 000000000002eee0 RBP: 0000000000400cc0 R08: 0000000000400cc0 R09: 0000000000000003 R10: 0000000000000001 R11: 0000000000000000 R12: ffff888003970f00 R13: 00000000ffffffff R14: ffff988004dd6800 R15: 00000000000000e8 FS: 00007f174d6f3600(0000) GS:ffff88807db00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: ffff988004dd6870 CR3: 00000000092be000 CR4: 00000000007506e0 PKRU: 55555554 Call Trace: <TASK> ? __die_body.cold+0x1a/0x1f ? page_f
d6870 CR3: 00000000092be000 CR4: 00000000007506e0 PKRU: 55555554 Call Trace: <TASK> ? __die_body.cold+0x1a/0x1f ? page_fault_oops+0xa9/0x1e0 ? fixup_exception+0x1d/0x310 ? exc_page_fault+0xa8/0x150 ? asm_exc_page_fault+0x22/0x30 ? kmem_cache_alloc_node+0xa2/0x1e0 ? __alloc_skb+0x16c/0x1e0 __alloc_skb+0x16c/0x1e0 alloc_skb_with_frags+0x48/0x1e0 sock_alloc_send_pskb+0x234/0x270 unix_stream_sendmsg+0x1f5/0x690 sock_sendmsg+0x5d/0x60 ____sys_sendmsg+0x210/0x260 ___sys_sendmsg+0x83/0xd0 ? kmem_cache_alloc+0xc6/0x1c0 ? avc_disable+0x20/0x20 ? percpu_counter_add_batch+0x53/0xc0 ? alloc_empty_file+0x5d/0xb0 ? alloc_file+0x91/0x170 ? alloc_file_pseudo+0x94/0x100 ? __fget_light+0x9f/0x120 __sys_sendms
alloc_empty_file+0x5d/0xb0 ? alloc_file+0x91/0x170 ? alloc_file_pseudo+0x94/0x100 ? __fget_light+0x9f/0x120 __sys_sendmsg+0x54/0xa0 do_syscall_64+0x3b/0x90 entry_SYSCALL_64_after_hwframe+0x69/0xd3 RIP: 0033:0x7f174d639a7d Code: 28 89 54 24 1c 48 89 74 24 10 89 7c 24 08 e8 8a c1 f4 ff 8b 54 24 1c 48 8b 74 24 10 41 89 c0 8b 7c 24 08 b8 2e 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 33 44 89 c7 48 89 44 24 08 e8 de c1 f4 ff 48 RSP: 002b:00007ffcb563ea50 EFLAGS: 00000293 ORIG_RAX: 000000000000002e RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007f174d639a7d RDX: 0000000000000000 RSI: 00007ffcb563eab0 RDI: 0000000000000007 RBP: 00007ffcb563eb10 R08: 0000000000000000 R09: 00000000ffffffff R10: 0000
RSI: 00007ffcb563eab0 RDI: 0000000000000007 RBP: 00007ffcb563eb10 R08: 0000000000000000 R09: 00000000ffffffff R10: 00000000004040a0 R11: 0000000000000293 R12: 00007ffcb563ec28 R13: 0000000000401398 R14: 0000000000403e00 R15: 00007f174d72c000 </TASK> References: - https://git.kernel.org/stable/c/4a3fcfc3b51796e5e6974041c9a7cf7808d16f9e - https://git.kernel.org/stable/c/2dde18cd1d8fac735875f2e4987f11817cc0bc2c
CVE ID: CVE-2023-53470 State: PUBLISHED Published: 2025-10-01T11:42:40.221Z Last Updated: 2025-10-01T11:42:40.221Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: ionic: catch failure from devlink_alloc Add a check for NULL on the alloc return. If devlink_alloc() fails and we try to use devlink_priv() on the NULL return, the kernel gets very unhappy and panics. With this fix, the driver load will still fail, but at least it won't panic the kernel. References: - https://git.kernel.org/stable/c/c177dd465f5c1e5f242cdb9258826c591c257e9a - https://git.kernel.org/stable/c/0d02efe7f25158c93146e3bb827bc7bb3cd5e71a - https://git.kernel.o
2cdb9258826c591c257e9a - https://git.kernel.org/stable/c/0d02efe7f25158c93146e3bb827bc7bb3cd5e71a - https://git.kernel.org/stable/c/5325f50de5b1433b27dda7ccff5cb7283722a3f1 - https://git.kernel.org/stable/c/0020c16c8af7f4bc9503a2088fb30793b6771fac - https://git.kernel.org/stable/c/4a54903ff68ddb33b6463c94b4eb37fc584ef760
CVE ID: CVE-2023-53471 State: PUBLISHED Published: 2025-10-01T11:42:41.046Z Last Updated: 2025-10-01T11:42:41.046Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu/gfx: disable gfx9 cp_ecc_error_irq only when enabling legacy gfx ras gfx9 cp_ecc_error_irq is only enabled when legacy gfx ras is assert. So in gfx_v9_0_hw_fini, interrupt disablement for cp_ecc_error_irq should be executed under such condition, otherwise, an amdgpu_irq_put calltrace will occur. [ 7283.170322] RIP: 0010:amdgpu_irq_put+0x45/0x70 [amdgpu] [ 7283.170964] RSP: 0018:ffff9a5fc3967d00 EFLAGS: 00010246 [ 7283.170967] RAX: ffff98d88afd3040 RBX: ffff9