Kushalkhemka/embedding-cve-nvd-dataset huggingface dataset:
=, otherwise it potentially leads to an out of bounds write on the next iteration through the loop References: - https://git.kernel.org/stable/c/2843a2e703f5cb85c9eeca11b7ee90861635a010 - https://git.kernel.org/stable/c/195e806b2afb0bad6470c9094f7e45e0cf109ee0 - https://git.kernel.org/stable/c/ad249aa3c38f329f91fba8b4b3cd087e79fb0ce8 - https://git.kernel.org/stable/c/6d8a71e4c3a2fa4960cc50996e76a42b62fab677 - https://git.kernel.org/stable/c/01cb355bb92e8fcf8306e11a4774d610c5864e39 - https://git.kernel.org/stable/c/ce69eac840db0b559994dc4290fce3d7c0d7bccd - https://git.kernel.org/stable/c/13c088cf3657d70893d75cf116be937f1509cc0f
CVE ID: CVE-2023-53239 State: PUBLISHED Published: 2025-09-15T14:22:13.289Z Last Updated: 2025-09-15T14:22:13.289Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: drm/msm/mdp5: Add check for kzalloc As kzalloc may fail and return NULL pointer, it should be better to check the return value in order to avoid the NULL pointer dereference. Patchwork: https://patchwork.freedesktop.org/patch/514154/ References: - https://git.kernel.org/stable/c/3975ea6eaffe26aec634b5c473e51dc76e73af62 - https://git.kernel.org/stable/c/49907c8873826ee771ba0ca1629e809c6479f617 - https://git.kernel.org/stable/c/82943a0730e00c14b03e25a4b2a1a9477ae89d7b -
c/49907c8873826ee771ba0ca1629e809c6479f617 - https://git.kernel.org/stable/c/82943a0730e00c14b03e25a4b2a1a9477ae89d7b - https://git.kernel.org/stable/c/bc579a2ee8b2e20c152b24b437d094832d8c9c9e - https://git.kernel.org/stable/c/37ff771ed008b9cbffd0eab77985968364694ce3 - https://git.kernel.org/stable/c/13fcfcb2a9a4787fe4e49841d728f6f2e9fa6911
CVE ID: CVE-2023-53240 State: PUBLISHED Published: 2025-09-15T14:22:14.241Z Last Updated: 2025-09-15T14:22:14.241Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: xsk: check IFF_UP earlier in Tx path Xsk Tx can be triggered via either sendmsg() or poll() syscalls. These two paths share a call to common function xsk_xmit() which has two sanity checks within. A pseudo code example to show the two paths: __xsk_sendmsg() : xsk_poll(): if (unlikely(!xsk_is_bound(xs))) if (unlikely(!xsk_is_bound(xs))) return -ENXIO; return mask; if (unlikely(need_wait)) (...) return -EOPNOTSUPP; xsk_xmit() mark napi id (...) xsk_xmit() xsk_xmit(): if
return mask; if (unlikely(need_wait)) (...) return -EOPNOTSUPP; xsk_xmit() mark napi id (...) xsk_xmit() xsk_xmit(): if (unlikely(!(xs->dev->flags & IFF_UP))) return -ENETDOWN; if (unlikely(!xs->tx)) return -ENOBUFS; As it can be observed above, in sendmsg() napi id can be marked on interface that was not brought up and this causes a NULL ptr dereference: [31757.505631] BUG: kernel NULL pointer dereference, address: 0000000000000018 [31757.512710] #PF: supervisor read access in kernel mode [31757.517936] #PF: error_code(0x0000) - not-present page [31757.523149] PGD 0 P4D 0 [31757.525726] Oops: 0000 [#1] PREEMPT SMP NOPTI [31757.530154] CPU: 26 PID: 95641 Comm: xdpsock Not tainted 6.2.0-rc5+
[31757.525726] Oops: 0000 [#1] PREEMPT SMP NOPTI [31757.530154] CPU: 26 PID: 95641 Comm: xdpsock Not tainted 6.2.0-rc5+ #40 [31757.536871] Hardware name: Intel Corporation S2600WFT/S2600WFT, BIOS SE5C620.86B.02.01.0008.031920191559 03/19/2019 [31757.547457] RIP: 0010:xsk_sendmsg+0xde/0x180 [31757.551799] Code: 00 75 a2 48 8b 00 a8 04 75 9b 84 d2 74 69 8b 85 14 01 00 00 85 c0 75 1b 48 8b 85 28 03 00 00 48 8b 80 98 00 00 00 48 8b 40 20 <8b> 40 18 89 85 14 01 00 00 8b bd 14 01 00 00 81 ff 00 01 00 00 0f [31757.570840] RSP: 0018:ffffc90034f27dc0 EFLAGS: 00010246 [31757.576143] RAX: 0000000000000000 RBX: ffffc90034f27e18 RCX: 0000000000000000 [31757.583389] RDX: 0000000000000001 RSI: ffffc90034f2
RAX: 0000000000000000 RBX: ffffc90034f27e18 RCX: 0000000000000000 [31757.583389] RDX: 0000000000000001 RSI: ffffc90034f27e18 RDI: ffff88984cf3c100 [31757.590631] RBP: ffff88984714a800 R08: ffff88984714a800 R09: 0000000000000000 [31757.597877] R10: 0000000000000001 R11: 0000000000000000 R12: 00000000fffffffa [31757.605123] R13: 0000000000000000 R14: 0000000000000003 R15: 0000000000000000 [31757.612364] FS: 00007fb4c5931180(0000) GS:ffff88afdfa00000(0000) knlGS:0000000000000000 [31757.620571] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [31757.626406] CR2: 0000000000000018 CR3: 000000184b41c003 CR4: 00000000007706e0 [31757.633648] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000
8 CR3: 000000184b41c003 CR4: 00000000007706e0 [31757.633648] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [31757.640894] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 [31757.648139] PKRU: 55555554 [31757.650894] Call Trace: [31757.653385] <TASK> [31757.655524] sock_sendmsg+0x8f/0xa0 [31757.659077] ? sockfd_lookup_light+0x12/0x70 [31757.663416] __sys_sendto+0xfc/0x170 [31757.667051] ? do_sched_setscheduler+0xdb/0x1b0 [31757.671658] __x64_sys_sendto+0x20/0x30 [31757.675557] do_syscall_64+0x38/0x90 [31757.679197] entry_SYSCALL_64_after_hwframe+0x72/0xdc [31757.687969] Code: 8e f6 ff 44 8b 4c 24 2c 4c 8b 44 24 20 41 89 c4 44 8b 54 24 28 48 8b 54 24 18 b8
hwframe+0x72/0xdc [31757.687969] Code: 8e f6 ff 44 8b 4c 24 2c 4c 8b 44 24 20 41 89 c4 44 8b 54 24 28 48 8b 54 24 18 b8 2c 00 00 00 48 8b 74 24 10 8b 7c 24 08 0f 05 <48> 3d 00 f0 ff ff 77 3a 44 89 e7 48 89 44 24 08 e8 b5 8e f6 ff 48 [31757.707007] RSP: 002b:00007ffd49c73c70 EFLAGS: 00000293 ORIG_RAX: 000000000000002c [31757.714694] RAX: ffffffffffffffda RBX: 000055a996565380 RCX: 00007fb4c5727c16 [31757.721939] RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000003 [31757.729184] RBP: 0000000000000040 R08: 0000000000000000 R09: 0000000000000000 [31757.736429] R10: 0000000000000040 R11: 0000000000000293 R12: 0000000000000000 [31757.743673] R13: 0000000000000000 R14: 000000000000000
: 0000000000000040 R11: 0000000000000293 R12: 0000000000000000 [31757.743673] R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000 [31757.754940] </TASK> To fix this, let's make xsk_xmit a function that will be responsible for generic Tx, where RCU is handled accordingly and pull out sanity checks and xs->zc handling. Populate sanity checks to __xsk_sendmsg() and xsk_poll(). References: - https://git.kernel.org/stable/c/cecc68559cd57fffb2be50685f262b9af2318e16 - https://git.kernel.org/stable/c/ffe19750e68d0bb21e8110b398346eef20b156a7 - https://git.kernel.org/stable/c/1596dae2f17ec5c6e8c8f0e3fec78c5ae55c1e0b
CVE ID: CVE-2023-53241 State: PUBLISHED Published: 2025-09-15T14:23:09.750Z Last Updated: 2025-09-15T14:23:09.750Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: nfsd: call op_release, even when op_func returns an error For ops with "trivial" replies, nfsd4_encode_operation will shortcut most of the encoding work and skip to just marshalling up the status. One of the things it skips is calling op_release. This could cause a memory leak in the layoutget codepath if there is an error at an inopportune time. Have the compound processing engine always call op_release, even when op_func sets an error in op->status. With this change,
the compound processing engine always call op_release, even when op_func sets an error in op->status. With this change, we also need nfsd4_block_get_device_info_scsi to set the gd_device pointer to NULL on error to avoid a double free. References: - https://git.kernel.org/stable/c/65a33135e91e6dd661ecdf1194b9d90c49ae3570 - https://git.kernel.org/stable/c/b11d8162c24af4a351d21e2c804d25ca493305e3 - https://git.kernel.org/stable/c/b623a8e5d38a69a3ef8644acb1030dd7c7bc28b3 - https://git.kernel.org/stable/c/3d0dcada384af22dec764c8374a2997870ec86ae - https://git.kernel.org/stable/c/15a8b55dbb1ba154d82627547c5761cac884d810
CVE ID: CVE-2023-53242 State: PUBLISHED Published: 2025-09-15T14:23:11.251Z Last Updated: 2025-09-15T14:23:11.251Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: thermal/drivers/hisi: Drop second sensor hi3660 The commit 74c8e6bffbe1 ("driver core: Add __alloc_size hint to devm allocators") exposes a panic "BRK handler: Fatal exception" on the hi3660_thermal_probe funciton. This is because the function allocates memory for only one sensors array entry, but tries to fill up a second one. Fix this by removing the unneeded second access. References: - https://git.kernel.org/stable/c/3cf2181e438f43ed24e12424fe36d156cca233b9 - https
e unneeded second access. References: - https://git.kernel.org/stable/c/3cf2181e438f43ed24e12424fe36d156cca233b9 - https://git.kernel.org/stable/c/e02bc492883abf751fd1a8d89fc025fbce6744c6 - https://git.kernel.org/stable/c/f5aaf140ab1c02889c088e1b1098adad600541af - https://git.kernel.org/stable/c/9f6756cd09889c7201ee31e6f76fbd914fb0b80d - https://git.kernel.org/stable/c/68e675a9b69cfc34dd915d91a4650e3ee53421f4 - https://git.kernel.org/stable/c/15cc25829a97c3957e520e971868aacc84341317
CVE ID: CVE-2023-53243 State: PUBLISHED Published: 2025-09-15T14:46:11.637Z Last Updated: 2025-09-15T14:46:11.637Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: btrfs: add handling for RAID1C23/DUP to btrfs_reduce_alloc_profile Callers of `btrfs_reduce_alloc_profile` expect it to return exactly one allocation profile flag, and failing to do so may ultimately result in a WARN_ON and remount-ro when allocating new blocks, like the below transaction abort on 6.1. `btrfs_reduce_alloc_profile` has two ways of determining the profile, first it checks if a conversion balance is currently running and uses the profile we're converting
rmining the profile, first it checks if a conversion balance is currently running and uses the profile we're converting to. If no balance is currently running, it returns the max-redundancy profile which at least one block in the selected block group has. This works by simply checking each known allocation profile bit in redundancy order. However, `btrfs_reduce_alloc_profile` has not been updated as new flags have been added - first with the `DUP` profile and later with the RAID1C34 profiles. Because of the way it checks, if we have blocks with different profiles and at least one is known, that profile will be selected. However, if none are known we may return a flag set with multiple alloca
st one is known, that profile will be selected. However, if none are known we may return a flag set with multiple allocation profiles set. This is currently only possible when a balance from one of the three unhandled profiles to another of the unhandled profiles is canceled after allocating at least one block using the new profile. In that case, a transaction abort like the below will occur and the filesystem will need to be mounted with -o skip_balance to get it mounted rw again (but the balance cannot be resumed without a similar abort). [770.648] ------------[ cut here ]------------ [770.648] BTRFS: Transaction aborted (error -22) [770.648] WARNING: CPU: 43 PID: 1159593 at fs/btrfs/exten
]------------ [770.648] BTRFS: Transaction aborted (error -22) [770.648] WARNING: CPU: 43 PID: 1159593 at fs/btrfs/extent-tree.c:4122 find_free_extent+0x1d94/0x1e00 [btrfs] [770.648] CPU: 43 PID: 1159593 Comm: btrfs Tainted: G W 6.1.0-0.deb11.7-powerpc64le #1 Debian 6.1.20-2~bpo11+1a~test [770.648] Hardware name: T2P9D01 REV 1.00 POWER9 0x4e1202 opal:skiboot-bc106a0 PowerNV [770.648] NIP: c00800000f6784fc LR: c00800000f6784f8 CTR: c000000000d746c0 [770.648] REGS: c000200089afe9a0 TRAP: 0700 Tainted: G W (6.1.0-0.deb11.7-powerpc64le Debian 6.1.20-2~bpo11+1a~test) [770.648] MSR: 9000000002029033 <SF,HV,VEC,EE,ME,IR,DR,RI,LE> CR: 28848282 XER: 20040000 [770.648] CFAR: c000000000135110 IRQMASK:
SR: 9000000002029033 <SF,HV,VEC,EE,ME,IR,DR,RI,LE> CR: 28848282 XER: 20040000 [770.648] CFAR: c000000000135110 IRQMASK: 0 GPR00: c00800000f6784f8 c000200089afec40 c00800000f7ea800 0000000000000026 GPR04: 00000001004820c2 c000200089afea00 c000200089afe9f8 0000000000000027 GPR08: c000200ffbfe7f98 c000000002127f90 ffffffffffffffd8 0000000026d6a6e8 GPR12: 0000000028848282 c000200fff7f3800 5deadbeef0000122 c00000002269d000 GPR16: c0002008c7797c40 c000200089afef17 0000000000000000 0000000000000000 GPR20: 0000000000000000 0000000000000001 c000200008bc5a98 0000000000000001 GPR24: 0000000000000000 c0000003c73088d0 c000200089afef17 c000000016d3a800 GPR28: c0000003c7308800 c00000002269d000 ffffffffffff
000000000000000 c0000003c73088d0 c000200089afef17 c000000016d3a800 GPR28: c0000003c7308800 c00000002269d000 ffffffffffffffea 0000000000000001 [770.648] NIP [c00800000f6784fc] find_free_extent+0x1d94/0x1e00 [btrfs] [770.648] LR [c00800000f6784f8] find_free_extent+0x1d90/0x1e00 [btrfs] [770.648] Call Trace: [770.648] [c000200089afec40] [c00800000f6784f8] find_free_extent+0x1d90/0x1e00 [btrfs] (unreliable) [770.648] [c000200089afed30] [c00800000f681398] btrfs_reserve_extent+0x1a0/0x2f0 [btrfs] [770.648] [c000200089afeea0] [c00800000f681bf0] btrfs_alloc_tree_block+0x108/0x670 [btrfs] [770.648] [c000200089afeff0] [c00800000f66bd68] __btrfs_cow_block+0x170/0x850 [btrfs] [770.648] [c000200089aff100
btrfs] [770.648] [c000200089afeff0] [c00800000f66bd68] __btrfs_cow_block+0x170/0x850 [btrfs] [770.648] [c000200089aff100] [c00800000f66c58c] btrfs_cow_block+0x144/0x288 [btrfs] [770.648] [c000200089aff1b0] [c00800000f67113c] btrfs_search_slot+0x6b4/0xcb0 [btrfs] [770.648] [c000200089aff2a0] [c00800000f679f60] lookup_inline_extent_backref+0x128/0x7c0 [btrfs] [770.648] [c000200089aff3b0] [c00800000f67b338] lookup_extent_backref+0x70/0x190 [btrfs] [770.648] [c000200089aff470] [c00800000f67b54c] __btrfs_free_extent+0xf4/0x1490 [btrfs] [770.648] [ ---truncated--- References: - https://git.kernel.org/stable/c/a3fbd156bd2cd16e3c64e250ebce33eb9f2ef612 - https://git.kernel.org/stable/c/12b6d68498982a
ttps://git.kernel.org/stable/c/a3fbd156bd2cd16e3c64e250ebce33eb9f2ef612 - https://git.kernel.org/stable/c/12b6d68498982a053a4a7e561a04387e57ca6f1a - https://git.kernel.org/stable/c/4fadf53fa95142f01f215012e97c384529759a72 - https://git.kernel.org/stable/c/1b532748ba00bd2a1d9b09e0d5e81280582c7770 - https://git.kernel.org/stable/c/160fe8f6fdb13da6111677be6263e5d65e875987
CVE ID: CVE-2023-53244 State: PUBLISHED Published: 2025-09-15T14:46:12.951Z Last Updated: 2025-09-15T14:46:12.951Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: media: pci: tw68: Fix null-ptr-deref bug in buf prepare and finish When the driver calls tw68_risc_buffer() to prepare the buffer, the function call dma_alloc_coherent may fail, resulting in a empty buffer buf->cpu. Later when we free the buffer or access the buffer, null ptr deref is triggered. This bug is similar to the following one: https://git.linuxtv.org/media_stage.git/commit/?id=2b064d91440b33fba5b452f2d1b31f13ae911d71. We believe the bug can be also dynamicall
nuxtv.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 tw68_risc_buffer() and the value of buf->cpu before buffer free. References: - https://git.kernel.org/stable/c/dcf632bca424e6ff8c8eb89c96694e7f05cd29b6 - https://git.kernel.org/stable/c/3c67f49a6643d973e83968ea35806c7b5ae68b56 - https://git.kernel.org/stable/c/3715c5e9a8f96b6ed0dcbea06da443efccac1ecc - https://git.kernel.org/stable/c/1634b7adcc5bef645b3666fdd564e5952a9e24e0
CVE ID: CVE-2023-53245 State: PUBLISHED Published: 2025-09-15T14:46:14.280Z Last Updated: 2025-09-15T14:46:14.280Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: scsi: storvsc: Fix handling of virtual Fibre Channel timeouts Hyper-V provides the ability to connect Fibre Channel LUNs to the host system and present them in a guest VM as a SCSI device. I/O to the vFC device is handled by the storvsc driver. The storvsc driver includes a partial integration with the FC transport implemented in the generic portion of the Linux SCSI subsystem so that FC attributes can be displayed in /sys. However, the partial integration means that s
f the Linux SCSI subsystem so that FC attributes can be displayed in /sys. However, the partial integration means that some aspects of vFC don't work properly. Unfortunately, a full and correct integration isn't practical because of limitations in what Hyper-V provides to the guest. In particular, in the context of Hyper-V storvsc, the FC transport timeout function fc_eh_timed_out() causes a kernel panic because it can't find the rport and dereferences a NULL pointer. The original patch that added the call from storvsc_eh_timed_out() to fc_eh_timed_out() is faulty in this regard. In many cases a timeout is due to a transient condition, so the situation can be improved by just continuing to w
egard. In many cases a timeout is due to a transient condition, so the situation can be improved by just continuing to wait like with other I/O requests issued by storvsc, and avoiding the guaranteed panic. For a permanent failure, continuing to wait may result in a hung thread instead of a panic, which again may be better. So fix the panic by removing the storvsc call to fc_eh_timed_out(). This allows storvsc to keep waiting for a response. The change has been tested by users who experienced a panic in fc_eh_timed_out() due to transient timeouts, and it solves their problem. In the future we may want to deprecate the vFC functionality in storvsc since it can't be fully fixed. But it has cur
m. In the future we may want to deprecate the vFC functionality in storvsc since it can't be fully fixed. But it has current users for whom it is working well enough, so it should probably stay for a while longer. References: - https://git.kernel.org/stable/c/cd87f4df9865a53807001ed12c0f0420b14ececd - https://git.kernel.org/stable/c/311db605e07f0d4fc0cc7ddb74f1e5692ea2f469 - https://git.kernel.org/stable/c/048ebc9a28fb918ee635dd4b2fcf4248eb6e4050 - https://git.kernel.org/stable/c/1678408d08f31a694d5150a56796dd04c9710b22 - https://git.kernel.org/stable/c/7a792b3d888aab2c65389f9f4f9f2f6c000b1a0d - https://git.kernel.org/stable/c/ed70fa5629a8b992a5372d7044d1db1f8fa6de29 - https://git.kernel.org
9f9f4f9f2f6c000b1a0d - https://git.kernel.org/stable/c/ed70fa5629a8b992a5372d7044d1db1f8fa6de29 - https://git.kernel.org/stable/c/763c06565055ae373fe7f89c11e1447bd1ded264 - https://git.kernel.org/stable/c/175544ad48cbf56affeef2a679c6a4d4fb1e2881
CVE ID: CVE-2023-53246 State: PUBLISHED Published: 2025-09-15T14:46:15.977Z Last Updated: 2025-09-15T14:46:15.977Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: cifs: fix DFS traversal oops without CONFIG_CIFS_DFS_UPCALL When compiled with CONFIG_CIFS_DFS_UPCALL disabled, cifs_dfs_d_automount is NULL. cifs.ko logic for mapping CIFS_FATTR_DFS_REFERRAL attributes to S_AUTOMOUNT and corresponding dentry flags is retained regardless of CONFIG_CIFS_DFS_UPCALL, leading to a NULL pointer dereference in VFS follow_automount() when traversing a DFS referral link: BUG: kernel NULL pointer dereference, address: 0000000000000000 ... Call
tomount() when traversing a DFS referral link: BUG: kernel NULL pointer dereference, address: 0000000000000000 ... Call Trace: <TASK> __traverse_mounts+0xb5/0x220 ? cifs_revalidate_mapping+0x65/0xc0 [cifs] step_into+0x195/0x610 ? lookup_fast+0xe2/0xf0 path_lookupat+0x64/0x140 filename_lookup+0xc2/0x140 ? __create_object+0x299/0x380 ? kmem_cache_alloc+0x119/0x220 ? user_path_at_empty+0x31/0x50 user_path_at_empty+0x31/0x50 __x64_sys_chdir+0x2a/0xd0 ? exit_to_user_mode_prepare+0xca/0x100 do_syscall_64+0x42/0x90 entry_SYSCALL_64_after_hwframe+0x72/0xdc This fix adds an inline cifs_dfs_d_automount() {return -EREMOTE} handler when CONFIG_CIFS_DFS_UPCALL is disabled. An alternative would be to avoi
ifs_dfs_d_automount() {return -EREMOTE} handler when CONFIG_CIFS_DFS_UPCALL is disabled. An alternative would be to avoid flagging S_AUTOMOUNT, etc. without CONFIG_CIFS_DFS_UPCALL. This approach was chosen as it provides more control over the error path. References: - https://git.kernel.org/stable/c/8cd7dbc9c46d51e00a0a8372e07cc1cbb8d24a77 - https://git.kernel.org/stable/c/8afb1fabcec1929db46977e84baeee0cc0e79242 - https://git.kernel.org/stable/c/657d7c215ca974d366ab1808213f716e1e3aa950 - https://git.kernel.org/stable/c/26a32a212bc540f4773cd6af8cf73e967d72569c - https://git.kernel.org/stable/c/b64305185b76f1d5145ce594ff48f3f0e70695bd - https://git.kernel.org/stable/c/b7d854c33ab48e55fc233699
.kernel.org/stable/c/b64305185b76f1d5145ce594ff48f3f0e70695bd - https://git.kernel.org/stable/c/b7d854c33ab48e55fc233699bbefe39ec9bb5c05 - https://git.kernel.org/stable/c/1e144b68208e98fd4602c842a7149ba5f41d87fb - https://git.kernel.org/stable/c/179a88a8558bbf42991d361595281f3e45d7edfc
CVE ID: CVE-2023-53247 State: PUBLISHED Published: 2025-09-15T14:46:17.344Z Last Updated: 2025-09-15T14:46:17.344Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: btrfs: set_page_extent_mapped after read_folio in btrfs_cont_expand While trying to get the subpage blocksize tests running, I hit the following panic on generic/476 assertion failed: PagePrivate(page) && page->private, in fs/btrfs/subpage.c:229 kernel BUG at fs/btrfs/subpage.c:229! Internal error: Oops - BUG: 00000000f2000800 [#1] SMP CPU: 1 PID: 1453 Comm: fsstress Not tainted 6.4.0-rc7+ #12 Hardware name: QEMU KVM Virtual Machine, BIOS edk2-20230301gitf80f052277c8-2
3 Comm: fsstress Not tainted 6.4.0-rc7+ #12 Hardware name: QEMU KVM Virtual Machine, BIOS edk2-20230301gitf80f052277c8-26.fc38 03/01/2023 pstate: 61400005 (nZCv daif +PAN -UAO -TCO +DIT -SSBS BTYPE=--) pc : btrfs_subpage_assert+0xbc/0xf0 lr : btrfs_subpage_assert+0xbc/0xf0 Call trace: btrfs_subpage_assert+0xbc/0xf0 btrfs_subpage_clear_checked+0x38/0xc0 btrfs_page_clear_checked+0x48/0x98 btrfs_truncate_block+0x5d0/0x6a8 btrfs_cont_expand+0x5c/0x528 btrfs_write_check.isra.0+0xf8/0x150 btrfs_buffered_write+0xb4/0x760 btrfs_do_write_iter+0x2f8/0x4b0 btrfs_file_write_iter+0x1c/0x30 do_iter_readv_writev+0xc8/0x158 do_iter_write+0x9c/0x210 vfs_iter_write+0x24/0x40 iter_file_splice_write+0x224/0x390
x30 do_iter_readv_writev+0xc8/0x158 do_iter_write+0x9c/0x210 vfs_iter_write+0x24/0x40 iter_file_splice_write+0x224/0x390 direct_splice_actor+0x38/0x68 splice_direct_to_actor+0x12c/0x260 do_splice_direct+0x90/0xe8 generic_copy_file_range+0x50/0x90 vfs_copy_file_range+0x29c/0x470 __arm64_sys_copy_file_range+0xcc/0x498 invoke_syscall.constprop.0+0x80/0xd8 do_el0_svc+0x6c/0x168 el0_svc+0x50/0x1b0 el0t_64_sync_handler+0x114/0x120 el0t_64_sync+0x194/0x198 This happens because during btrfs_cont_expand we'll get a page, set it as mapped, and if it's not Uptodate we'll read it. However between the read and re-locking the page we could have called release_folio() on the page, but left the page in the
ver between the read and re-locking the page we could have called release_folio() on the page, but left the page in the file mapping. release_folio() can clear the page private, and thus further down we blow up when we go to modify the subpage bits. Fix this by putting the set_page_extent_mapped() after the read. This is safe because read_folio() will call set_page_extent_mapped() before it does the read, and then if we clear page private but leave it on the mapping we're completely safe re-setting set_page_extent_mapped(). With this patch I can now run generic/476 without panicing. References: - https://git.kernel.org/stable/c/0a5e0bc8e8618e32a6ca64450867628eb0a627bf - https://git.kernel.or
panicing. References: - https://git.kernel.org/stable/c/0a5e0bc8e8618e32a6ca64450867628eb0a627bf - https://git.kernel.org/stable/c/a5880e69cf7fe4a0bb1eabae02205352d1b59b7b - https://git.kernel.org/stable/c/17b17fcd6d446b95904a6929c40012ee7f0afc0c