Kushalkhemka/embedding-cve-nvd-dataset huggingface dataset:
o() will call ext4_error and return NULL. We also add fallback code in all of the callers of ext4_get_group_info() that it might NULL. Also, since ext4_get_group_info() was already borderline to be an inline function, un-inline it. The results in a next reduction of the compiled text size of ext4 by roughly 2k. References: - https://git.kernel.org/stable/c/100c0ad6c04597fefeaaba2bb1827cc015d95067 - https://git.kernel.org/stable/c/620a3c28221bb219b81bc0bffd065cc187494302 - https://git.kernel.org/stable/c/b4319e457d6e3fb33e443efeaf4634fc36e8a9ed - https://git.kernel.org/stable/c/31668cebf45adfb6283e465e641c4f5a21b07afa - https://git.kernel.org/stable/c/5354b2af34064a4579be8bc0e2f15a7b70f14b5f
CVE ID: CVE-2023-53504 State: PUBLISHED Published: 2025-10-01T11:45:54.977Z Last Updated: 2025-10-01T11:45:54.977Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: RDMA/bnxt_re: Properly order ib_device_unalloc() to avoid UAF ib_dealloc_device() should be called only after device cleanup. Fix the dealloc sequence. References: - https://git.kernel.org/stable/c/c95863f6d970ef968e7c1f3c481f72a4b0734654 - https://git.kernel.org/stable/c/5363fc488da579923edf6a2fdca3d3b651dd800b
CVE ID: CVE-2023-53505 State: PUBLISHED Published: 2025-10-01T11:45:55.859Z Last Updated: 2025-10-01T11:45:55.859Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: clk: tegra: tegra124-emc: Fix potential memory leak The tegra and tegra needs to be freed in the error handling path, otherwise it will be leaked. References: - https://git.kernel.org/stable/c/801c8341f7aff07c494b53e627970b72635af5d3 - https://git.kernel.org/stable/c/404e9f741acfb188212f7142d91e247630dd77cc - https://git.kernel.org/stable/c/fd1c117bb5d7e033bf1aa25ac97ff421f81a1199 - https://git.kernel.org/stable/c/96bafece6ff380138896f009141fd7337070e680 - https://git.
d7e033bf1aa25ac97ff421f81a1199 - https://git.kernel.org/stable/c/96bafece6ff380138896f009141fd7337070e680 - https://git.kernel.org/stable/c/e969c144d908ea9387442659f103d374c8ff682d - https://git.kernel.org/stable/c/4e59e355f9fcccd9edf65d09f769bb4c163a1c36 - https://git.kernel.org/stable/c/53a06e5924c0d43c11379a08c5a78529c3e61595
CVE ID: CVE-2023-53506 State: PUBLISHED Published: 2025-10-01T11:45:56.616Z Last Updated: 2025-10-01T11:45:56.616Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: udf: Do not bother merging very long extents When merging very long extents we try to push as much length as possible to the first extent. However this is unnecessarily complicated and not really worth the trouble. Furthermore there was a bug in the logic resulting in corrupting extents in the file as syzbot reproducer shows. So just don't bother with the merging of extents that are too long together. References: - https://git.kernel.org/stable/c/d52252a1de4cf96a34f722
the merging of extents that are too long together. References: - https://git.kernel.org/stable/c/d52252a1de4cf96a34f722b0cd8902d8ff78eb57 - https://git.kernel.org/stable/c/5d029799d381a9ee06209a222cae75f04c5d5304 - https://git.kernel.org/stable/c/3d20e3b768aff32112bdce8d3219d923ae75f9f1 - https://git.kernel.org/stable/c/965982feb333aefa9256c0fe188b5f1b958aef63 - https://git.kernel.org/stable/c/9a8d602f0723586e668bae7e65c832ceb9bcc8bc - https://git.kernel.org/stable/c/adac9ac6d2e04ea0782b91a00ba10706002f3ec4 - https://git.kernel.org/stable/c/7a965da79f2d22601f329cbfce588386b0847544 - https://git.kernel.org/stable/c/53cafe1d6d8ef9f93318e5bfccc0d24f27d41ced
CVE ID: CVE-2023-53507 State: PUBLISHED Published: 2025-10-01T11:45:57.310Z Last Updated: 2025-10-01T11:45:57.310Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: net/mlx5: Unregister devlink params in case interface is down Currently, in case an interface is down, mlx5 driver doesn't unregister its devlink params, which leads to this WARN[1]. Fix it by unregistering devlink params in that case as well. [1] [ 295.244769 ] WARNING: CPU: 15 PID: 1 at net/core/devlink.c:9042 devlink_free+0x174/0x1fc [ 295.488379 ] CPU: 15 PID: 1 Comm: shutdown Tainted: G S OE 5.15.0-1017.19.3.g0677e61-bluefield #g0677e61 [ 295.509330 ] Hardware nam
CPU: 15 PID: 1 Comm: shutdown Tainted: G S OE 5.15.0-1017.19.3.g0677e61-bluefield #g0677e61 [ 295.509330 ] Hardware name: https://www.mellanox.com BlueField SoC/BlueField SoC, BIOS 4.2.0.12761 Jun 6 2023 [ 295.543096 ] pc : devlink_free+0x174/0x1fc [ 295.551104 ] lr : mlx5_devlink_free+0x18/0x2c [mlx5_core] [ 295.561816 ] sp : ffff80000809b850 [ 295.711155 ] Call trace: [ 295.716030 ] devlink_free+0x174/0x1fc [ 295.723346 ] mlx5_devlink_free+0x18/0x2c [mlx5_core] [ 295.733351 ] mlx5_sf_dev_remove+0x98/0xb0 [mlx5_core] [ 295.743534 ] auxiliary_bus_remove+0x2c/0x50 [ 295.751893 ] __device_release_driver+0x19c/0x280 [ 295.761120 ] device_release_driver+0x34/0x50 [ 295.769649 ] bus_remove_devic
893 ] __device_release_driver+0x19c/0x280 [ 295.761120 ] device_release_driver+0x34/0x50 [ 295.769649 ] bus_remove_device+0xdc/0x170 [ 295.777656 ] device_del+0x17c/0x3a4 [ 295.784620 ] mlx5_sf_dev_remove+0x28/0xf0 [mlx5_core] [ 295.794800 ] mlx5_sf_dev_table_destroy+0x98/0x110 [mlx5_core] [ 295.806375 ] mlx5_unload+0x34/0xd0 [mlx5_core] [ 295.815339 ] mlx5_unload_one+0x70/0xe4 [mlx5_core] [ 295.824998 ] shutdown+0xb0/0xd8 [mlx5_core] [ 295.833439 ] pci_device_shutdown+0x3c/0xa0 [ 295.841651 ] device_shutdown+0x170/0x340 [ 295.849486 ] __do_sys_reboot+0x1f4/0x2a0 [ 295.857322 ] __arm64_sys_reboot+0x2c/0x40 [ 295.865329 ] invoke_syscall+0x78/0x100 [ 295.872817 ] el0_svc_common.constprop.0+0x5
22 ] __arm64_sys_reboot+0x2c/0x40 [ 295.865329 ] invoke_syscall+0x78/0x100 [ 295.872817 ] el0_svc_common.constprop.0+0x54/0x184 [ 295.882392 ] do_el0_svc+0x30/0xac [ 295.889008 ] el0_svc+0x48/0x160 [ 295.895278 ] el0t_64_sync_handler+0xa4/0x130 [ 295.903807 ] el0t_64_sync+0x1a4/0x1a8 [ 295.911120 ] ---[ end trace 4f1d2381d00d9dce ]--- References: - https://git.kernel.org/stable/c/471f59b3455314f0cafacf3096453727876355a9 - https://git.kernel.org/stable/c/53d737dfd3d7b023fa9fa445ea3f3db0ac9da402
CVE ID: CVE-2023-53508 State: PUBLISHED Published: 2025-10-01T11:45:58.042Z Last Updated: 2025-10-01T11:45:58.042Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: ublk: fail to start device if queue setup is interrupted In ublk_ctrl_start_dev(), if wait_for_completion_interruptible() is interrupted by signal, queues aren't setup successfully yet, so we have to fail UBLK_CMD_START_DEV, otherwise kernel oops can be triggered. Reported by German when working on qemu-storage-deamon which requires single thread ublk daemon. References: - https://git.kernel.org/stable/c/0d5916c439574b18a0734872daa0022b3d6105ad - https://git.kernel.org
daemon. References: - https://git.kernel.org/stable/c/0d5916c439574b18a0734872daa0022b3d6105ad - https://git.kernel.org/stable/c/6ab3e7d424cd413d7a5e976c8a30b4ffa84a65dd - https://git.kernel.org/stable/c/53e7d08f6d6e214c40db1f51291bb2975c789dc2
CVE ID: CVE-2023-53509 State: PUBLISHED Published: 2025-10-01T11:45:58.762Z Last Updated: 2025-10-01T11:45:58.762Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: qed: allow sleep in qed_mcp_trace_dump() By default, qed_mcp_cmd_and_union() delays 10us at a time in a loop that can run 500K times, so calls to qed_mcp_nvm_rd_cmd() may block the current thread for over 5s. We observed thread scheduling delays over 700ms in production, with stacktraces pointing to this code as the culprit. qed_mcp_trace_dump() is called from ethtool, so sleeping is permitted. It already can sleep in qed_mcp_halt(), which calls qed_mcp_cmd(). Add a "c
lled from ethtool, so sleeping is permitted. It already can sleep in qed_mcp_halt(), which calls qed_mcp_cmd(). Add a "can sleep" parameter to qed_find_nvram_image() and qed_nvram_read() so they can sleep during qed_mcp_trace_dump(). qed_mcp_trace_get_meta_info() and qed_mcp_trace_read_meta(), called only by qed_mcp_trace_dump(), allow these functions to sleep. I can't tell if the other caller (qed_grc_dump_mcp_hw_dump()) can sleep, so keep b_can_sleep set to false when it calls these functions. An example stacktrace from a custom warning we added to the kernel showing a thread that has not scheduled despite long needing resched: [ 2745.362925,17] ------------[ cut here ]------------ [ 2745.
read that has not scheduled despite long needing resched: [ 2745.362925,17] ------------[ cut here ]------------ [ 2745.362941,17] WARNING: CPU: 23 PID: 5640 at arch/x86/kernel/irq.c:233 do_IRQ+0x15e/0x1a0() [ 2745.362946,17] Thread not rescheduled for 744 ms after irq 99 [ 2745.362956,17] Modules linked in: ... [ 2745.363339,17] CPU: 23 PID: 5640 Comm: lldpd Tainted: P O 4.4.182+ #202104120910+6d1da174272d.61x [ 2745.363343,17] Hardware name: FOXCONN MercuryB/Quicksilver Controller, BIOS H11P1N09 07/08/2020 [ 2745.363346,17] 0000000000000000 ffff885ec07c3ed8 ffffffff8131eb2f ffff885ec07c3f20 [ 2745.363358,17] ffffffff81d14f64 ffff885ec07c3f10 ffffffff81072ac2 ffff88be98ed0000 [ 2745.363369,
2f ffff885ec07c3f20 [ 2745.363358,17] ffffffff81d14f64 ffff885ec07c3f10 ffffffff81072ac2 ffff88be98ed0000 [ 2745.363369,17] 0000000000000063 0000000000000174 0000000000000074 0000000000000000 [ 2745.363379,17] Call Trace: [ 2745.363382,17] <IRQ> [<ffffffff8131eb2f>] dump_stack+0x8e/0xcf [ 2745.363393,17] [<ffffffff81072ac2>] warn_slowpath_common+0x82/0xc0 [ 2745.363398,17] [<ffffffff81072b4c>] warn_slowpath_fmt+0x4c/0x50 [ 2745.363404,17] [<ffffffff810d5a8e>] ? rcu_irq_exit+0xae/0xc0 [ 2745.363408,17] [<ffffffff817c99fe>] do_IRQ+0x15e/0x1a0 [ 2745.363413,17] [<ffffffff817c7ac9>] common_interrupt+0x89/0x89 [ 2745.363416,17] <EOI> [<ffffffff8132aa74>] ? delay_tsc+0x24/0x50 [ 2745.363425,17] [<
ac9>] common_interrupt+0x89/0x89 [ 2745.363416,17] <EOI> [<ffffffff8132aa74>] ? delay_tsc+0x24/0x50 [ 2745.363425,17] [<ffffffff8132aa04>] __udelay+0x34/0x40 [ 2745.363457,17] [<ffffffffa04d45ff>] qed_mcp_cmd_and_union+0x36f/0x7d0 [qed] [ 2745.363473,17] [<ffffffffa04d5ced>] qed_mcp_nvm_rd_cmd+0x4d/0x90 [qed] [ 2745.363490,17] [<ffffffffa04e1dc7>] qed_mcp_trace_dump+0x4a7/0x630 [qed] [ 2745.363504,17] [<ffffffffa04e2556>] ? qed_fw_asserts_dump+0x1d6/0x1f0 [qed] [ 2745.363520,17] [<ffffffffa04e4ea7>] qed_dbg_mcp_trace_get_dump_buf_size+0x37/0x80 [qed] [ 2745.363536,17] [<ffffffffa04ea881>] qed_dbg_feature_size+0x61/0xa0 [qed] [ 2745.363551,17] [<ffffffffa04eb427>] qed_dbg_all_data_size+0x247/
fffffa04ea881>] qed_dbg_feature_size+0x61/0xa0 [qed] [ 2745.363551,17] [<ffffffffa04eb427>] qed_dbg_all_data_size+0x247/0x260 [qed] [ 2745.363560,17] [<ffffffffa0482c10>] qede_get_regs_len+0x30/0x40 [qede] [ 2745.363566,17] [<ffffffff816c9783>] ethtool_get_drvinfo+0xe3/0x190 [ 2745.363570,17] [<ffffffff816cc152>] dev_ethtool+0x1362/0x2140 [ 2745.363575,17] [<ffffffff8109bcc6>] ? finish_task_switch+0x76/0x260 [ 2745.363580,17] [<ffffffff817c2116>] ? __schedule+0x3c6/0x9d0 [ 2745.363585,17] [<ffffffff810dbd50>] ? hrtimer_start_range_ns+0x1d0/0x370 [ 2745.363589,17] [<ffffffff816c1e5b>] ? dev_get_by_name_rcu+0x6b/0x90 [ 2745.363594,17] [<ffffffff816de6a8>] dev_ioctl+0xe8/0x710 [ 2745.363599,17]
816c1e5b>] ? dev_get_by_name_rcu+0x6b/0x90 [ 2745.363594,17] [<ffffffff816de6a8>] dev_ioctl+0xe8/0x710 [ 2745.363599,17] [<ffffffff816a58a8>] sock_do_ioctl+0x48/0x60 [ 2745.363603,17] [<ffffffff816a5d87>] sock_ioctl+0x1c7/0x280 [ 2745.363608,17] [<ffffffff8111f393>] ? seccomp_phase1+0x83/0x220 [ 2745.363612,17] [<ffffffff811e3503>] do_vfs_ioctl+0x2b3/0x4e0 [ 2745.363616,17] [<ffffffff811e3771>] SyS_ioctl+0x41/0x70 [ 2745.363619,17] [<ffffffff817c6ffe>] entry_SYSCALL_64_fastpath+0x1e/0x79 [ 2745.363622,17] ---[ end trace f6954aa440266421 ]--- References: - https://git.kernel.org/stable/c/e0387f4f39a8d92302273ac356d1f6b2a38160d8 - https://git.kernel.org/stable/c/50c81b35df01db12b348c5cbf4b1917
.org/stable/c/e0387f4f39a8d92302273ac356d1f6b2a38160d8 - https://git.kernel.org/stable/c/50c81b35df01db12b348c5cbf4b1917dc9a7db54 - https://git.kernel.org/stable/c/5401c3e0992860b11fb4b25796e4c4f1921740df
CVE ID: CVE-2023-53510 State: PUBLISHED Published: 2025-10-01T11:45:59.421Z Last Updated: 2025-10-01T11:45:59.421Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: scsi: ufs: core: Fix handling of lrbp->cmd ufshcd_queuecommand() may be called two times in a row for a SCSI command before it is completed. Hence make the following changes: - In the functions that submit a command, do not check the old value of lrbp->cmd nor clear lrbp->cmd in error paths. - In ufshcd_release_scsi_cmd(), do not clear lrbp->cmd. See also scsi_send_eh_cmnd(). This commit prevents that the following appears if a command times out: WARNING: at drivers/uf
also scsi_send_eh_cmnd(). This commit prevents that the following appears if a command times out: WARNING: at drivers/ufs/core/ufshcd.c:2965 ufshcd_queuecommand+0x6f8/0x9a8 Call trace: ufshcd_queuecommand+0x6f8/0x9a8 scsi_send_eh_cmnd+0x2c0/0x960 scsi_eh_test_devices+0x100/0x314 scsi_eh_ready_devs+0xd90/0x114c scsi_error_handler+0x2b4/0xb70 kthread+0x16c/0x1e0 References: - https://git.kernel.org/stable/c/f3ee24af62681b942bbd799ac77b90a6d7e1fdb1 - https://git.kernel.org/stable/c/49234a401e161a2f2698f4612ab792c49b3cad1b - https://git.kernel.org/stable/c/549e91a9bbaa0ee480f59357868421a61d369770
CVE ID: CVE-2023-53511 State: PUBLISHED Published: 2025-10-01T11:46:00.185Z Last Updated: 2025-10-01T11:46:00.185Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: io_uring: fix fget leak when fs don't support nowait buffered read Heming reported a BUG when using io_uring doing link-cp on ocfs2. [1] Do the following steps can reproduce this BUG: mount -t ocfs2 /dev/vdc /mnt/ocfs2 cp testfile /mnt/ocfs2/ ./link-cp /mnt/ocfs2/testfile /mnt/ocfs2/testfile.1 umount /mnt/ocfs2 Then umount will fail, and it outputs: umount: /mnt/ocfs2: target is busy. While tracing umount, it blames mnt_get_count() not return as expected. Do a deep inv
mount: /mnt/ocfs2: target is busy. While tracing umount, it blames mnt_get_count() not return as expected. Do a deep investigation for fget()/fput() on related code flow, I've finally found that fget() leaks since ocfs2 doesn't support nowait buffered read. io_issue_sqe |-io_assign_file // do fget() first |-io_read |-io_iter_do_read |-ocfs2_file_read_iter // return -EOPNOTSUPP |-kiocb_done |-io_rw_done |-__io_complete_rw_common // set REQ_F_REISSUE |-io_resubmit_prep |-io_req_prep_async // override req->file, leak happens This was introduced by commit a196c78b5443 in v5.18. Fix it by don't re-assign req->file if it has already been assigned. [1] https://lore.kernel.org/ocfs2-devel/ab580a75-9
Fix it by don't re-assign req->file if it has already been assigned. [1] https://lore.kernel.org/ocfs2-devel/ab580a75-91c8-d68a-3455-40361be1bfa8@linux.alibaba.com/T/#t References: - https://git.kernel.org/stable/c/75a499fc9d66a32271e2b3e4ca71156e8ad3b484 - https://git.kernel.org/stable/c/10fb2e16ee6ffaf1716b9e90d007e6b300bfa457 - https://git.kernel.org/stable/c/54aa7f2330b82884f4a1afce0220add6e8312f8b
CVE ID: CVE-2023-53512 State: PUBLISHED Published: 2025-10-01T11:46:00.888Z Last Updated: 2025-10-01T11:46:00.888Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: scsi: mpt3sas: Fix a memory leak Add a forgotten kfree(). References: - https://git.kernel.org/stable/c/30c7c72b6cf9d8c95f9b219c9d2e4e31b15bebe5 - https://git.kernel.org/stable/c/378cc0eec4aa546ce1ae17515e2dfab719d4fb1e - https://git.kernel.org/stable/c/847cdbdcd5a24c1eec9595161a23b88fef91ff42 - https://git.kernel.org/stable/c/28137ea3eb05a87329a7154a8ff410d9e8bcc0a5 - https://git.kernel.org/stable/c/54dd96015e8d7a2a07359e2dfebf05b529d1780c
CVE ID: CVE-2023-53513 State: PUBLISHED Published: 2025-10-01T11:46:01.717Z Last Updated: 2025-10-01T11:46:01.717Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: nbd: fix incomplete validation of ioctl arg We tested and found an alarm caused by nbd_ioctl arg without verification. The UBSAN warning calltrace like below: UBSAN: Undefined behaviour in fs/buffer.c:1709:35 signed integer overflow: -9223372036854775808 - 1 cannot be represented in type 'long long int' CPU: 3 PID: 2523 Comm: syz-executor.0 Not tainted 4.19.90 #1 Hardware name: linux,dummy-virt (DT) Call trace: dump_backtrace+0x0/0x3f0 arch/arm64/kernel/time.c:78 show_
d 4.19.90 #1 Hardware name: linux,dummy-virt (DT) Call trace: dump_backtrace+0x0/0x3f0 arch/arm64/kernel/time.c:78 show_stack+0x28/0x38 arch/arm64/kernel/traps.c:158 __dump_stack lib/dump_stack.c:77 [inline] dump_stack+0x170/0x1dc lib/dump_stack.c:118 ubsan_epilogue+0x18/0xb4 lib/ubsan.c:161 handle_overflow+0x188/0x1dc lib/ubsan.c:192 __ubsan_handle_sub_overflow+0x34/0x44 lib/ubsan.c:206 __block_write_full_page+0x94c/0xa20 fs/buffer.c:1709 block_write_full_page+0x1f0/0x280 fs/buffer.c:2934 blkdev_writepage+0x34/0x40 fs/block_dev.c:607 __writepage+0x68/0xe8 mm/page-writeback.c:2305 write_cache_pages+0x44c/0xc70 mm/page-writeback.c:2240 generic_writepages+0xdc/0x148 mm/page-writeback.c:2329 bl
.c:2305 write_cache_pages+0x44c/0xc70 mm/page-writeback.c:2240 generic_writepages+0xdc/0x148 mm/page-writeback.c:2329 blkdev_writepages+0x2c/0x38 fs/block_dev.c:2114 do_writepages+0xd4/0x250 mm/page-writeback.c:2344 The reason for triggering this warning is __block_write_full_page() -> i_size_read(inode) - 1 overflow. inode->i_size is assigned in __nbd_ioctl() -> nbd_set_size() -> bytesize. We think it is necessary to limit the size of arg to prevent errors. Moreover, __nbd_ioctl() -> nbd_add_socket(), arg will be cast to int. Assuming the value of arg is 0x80000000000000001) (on a 64-bit machine), it will become 1 after the coercion, which will return unexpected results. Fix it by adding ch
1) (on a 64-bit machine), it will become 1 after the coercion, which will return unexpected results. Fix it by adding checks to prevent passing in too large numbers. References: - https://git.kernel.org/stable/c/52851d0c3354b397c11d31dfeb8b2a2fc85a0002 - https://git.kernel.org/stable/c/fab766c8a1aff715bce7075aab40e780266f8e1a - https://git.kernel.org/stable/c/ffb75ffaa68723276365d0f9d00b03362b750657 - https://git.kernel.org/stable/c/55793ea54d77719a071b1ccc05a05056e3b5e009
CVE ID: CVE-2023-53514 State: PUBLISHED Published: 2025-10-01T11:46:02.393Z Last Updated: 2025-10-01T11:46:02.393Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: gpu: host1x: Fix memory leak of device names The device names allocated by dev_set_name() need be freed before module unloading, but they can not be freed because the kobject's refcount which was set in device_initialize() has not be decreased to 0. As comment of device_add() says, if it fails, use only put_device() drop the refcount, then the name will be freed in kobejct_cleanup(). device_del() and put_device() can be replaced with device_unregister(), so call it to
ll be freed in kobejct_cleanup(). device_del() and put_device() can be replaced with device_unregister(), so call it to unregister the added successfully devices, and just call put_device() to the not added device. Add a release() function to device to avoid null release() function WARNING in device_release(), it's empty, because the context devices are freed together in host1x_memory_context_list_free(). References: - https://git.kernel.org/stable/c/958c6cbc32996c375af42db96ceba021a1959899 - https://git.kernel.org/stable/c/dba1aeaaf3d0e2f996cb0a5609e5e85ecf405a5c - https://git.kernel.org/stable/c/3ab0f5ddb761270b11d8c90b8550a59666cfc9bb - https://git.kernel.org/stable/c/55879dad0f3ae8468444
/git.kernel.org/stable/c/3ab0f5ddb761270b11d8c90b8550a59666cfc9bb - https://git.kernel.org/stable/c/55879dad0f3ae8468444b42f785ad79eac05fe5b
CVE ID: CVE-2023-53515 State: PUBLISHED Published: 2025-10-01T11:46:03.192Z Last Updated: 2025-10-01T11:46:03.192Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: virtio-mmio: don't break lifecycle of vm_dev vm_dev has a separate lifecycle because it has a 'struct device' embedded. Thus, having a release callback for it is correct. Allocating the vm_dev struct with devres totally breaks this protection, though. Instead of waiting for the vm_dev release callback, the memory is freed when the platform_device is removed. Resulting in a use-after-free when finally the callback is to be called. To easily see the problem, compile the
emoved. Resulting in a use-after-free when finally the callback is to be called. To easily see the problem, compile the kernel with CONFIG_DEBUG_KOBJECT_RELEASE and unbind with sysfs. The fix is easy, don't use devres in this case. Found during my research about object lifetime problems. References: - https://git.kernel.org/stable/c/97a2d55ead76358245b446efd87818e919196d7a - https://git.kernel.org/stable/c/b788ad3b2468512339c05f23692e36860264e674 - https://git.kernel.org/stable/c/3ff54d904fafabd0912796785e53cce4e69ca123 - https://git.kernel.org/stable/c/5b7d5c2dd664eb8b9a06ecbc06e28d39359c422e - https://git.kernel.org/stable/c/af5818c35173e096085c6ae2e3aac605d3d15e41 - https://git.kernel.org
ecbc06e28d39359c422e - https://git.kernel.org/stable/c/af5818c35173e096085c6ae2e3aac605d3d15e41 - https://git.kernel.org/stable/c/2dcb368fe5a8eee498ca75c93a18ce2f3b0d6a8e - https://git.kernel.org/stable/c/55c91fedd03d7b9cf0c5199b2eb12b9b8e95281a
CVE ID: CVE-2023-53516 State: PUBLISHED Published: 2025-10-01T11:46:03.878Z Last Updated: 2025-10-01T11:46:03.878Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: macvlan: add forgotten nla_policy for IFLA_MACVLAN_BC_CUTOFF The previous commit 954d1fa1ac93 ("macvlan: Add netlink attribute for broadcast cutoff") added one additional attribute named IFLA_MACVLAN_BC_CUTOFF to allow broadcast cutfoff. However, it forgot to describe the nla_policy at macvlan_policy (drivers/net/macvlan.c). Hence, this suppose NLA_S32 (4 bytes) integer can be faked as empty (0 bytes) by a malicious user, which could leads to OOB in heap just like CVE-
2 (4 bytes) integer can be faked as empty (0 bytes) by a malicious user, which could leads to OOB in heap just like CVE-2023-3773. To fix it, this commit just completes the nla_policy description for IFLA_MACVLAN_BC_CUTOFF. This enforces the length check and avoids the potential OOB read. References: - https://git.kernel.org/stable/c/79f44709aa7a744fbfbadd4aef678443290c6991 - https://git.kernel.org/stable/c/55cef78c244d0d076f5a75a35530ca63c92f4426
CVE ID: CVE-2023-53517 State: PUBLISHED Published: 2025-10-01T11:46:04.673Z Last Updated: 2025-10-01T11:46:04.673Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: tipc: do not update mtu if msg_max is too small in mtu negotiation When doing link mtu negotiation, a malicious peer may send Activate msg with a very small mtu, e.g. 4 in Shuang's testing, without checking for the minimum mtu, l->mtu will be set to 4 in tipc_link_proto_rcv(), then n->links[bearer_id].mtu is set to 4294967228, which is a overflow of '4 - INT_H_SIZE - EMSG_OVERHEAD' in tipc_link_mss(). With tipc_link.mtu = 4, tipc_link_xmit() kept printing the warning:
4 - INT_H_SIZE - EMSG_OVERHEAD' in tipc_link_mss(). With tipc_link.mtu = 4, tipc_link_xmit() kept printing the warning: tipc: Too large msg, purging xmit list 1 5 0 40 4! tipc: Too large msg, purging xmit list 1 15 0 60 4! And with tipc_link_entry.mtu 4294967228, a huge skb was allocated in named_distribute(), and when purging it in tipc_link_xmit(), a crash was even caused: general protection fault, probably for non-canonical address 0x2100001011000dd: 0000 [#1] PREEMPT SMP PTI CPU: 0 PID: 0 Comm: swapper/0 Kdump: loaded Not tainted 6.3.0.neta #19 RIP: 0010:kfree_skb_list_reason+0x7e/0x1f0 Call Trace: <IRQ> skb_release_data+0xf9/0x1d0 kfree_skb_reason+0x40/0x100 tipc_link_xmit+0x57a/0x740 [