deardaniel/secdata-raw huggingface dataset:
CVE: CVE-2022-50705
Published: 2025-12-24
Description: In the Linux kernel, the following vulnerability has been resolved:

io_uring/rw: defer fsnotify calls to task context

We can't call these off the kiocb completion as that might be off
soft/hard irq context. Defer the calls to when we process the
task_work for this request. That avoids valid complaints like:

stack backtrace:
CPU: 1 PID: 0 Comm: swapper/1 Not tainted 6.0.0-rc6-syzkaller-00321-g105a36f3694e #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 08/26/2022
Call Trace:
 <IRQ>
 __dump_stack lib/dump_stack.c:88 [inline]
 dump_stack_lvl+0xcd/0x134 lib/dump_stack.c:106
 print_usage_bug kernel/locking/lockdep.c:3961 [inline]
 valid_state kernel/locking/lockdep.c:3973 [inline]
 mark_lock_irq kernel/locking/lockdep.c:4176 [inline]
 mark_lock.part.0.cold+0x18/0xd8 kernel/locking/lockdep.c:4632
 mark_lock kernel/locking/lockdep.c:4596 [inline]
 mark_usage kernel/locking/lockdep.c:4527 [inline]
 __lock_acquire+0x11d9/0x56d0 kernel/locking/lockdep.c:5007
 lock_acquire kernel/locking/lockdep.c:5666 [inline]
 lock_acquire+0x1ab/0x570 kernel/locking/lockdep.c:5631
 __fs_reclaim_acquire mm/page_alloc.c:4674 [inline]
 fs_reclaim_acquire+0x115/0x160 mm/page_alloc.c:4688
 might_alloc include/linux/sched/mm.h:271 [inline]
 slab_pre_alloc_hook mm/slab.h:700 [inline]
 slab_alloc mm/slab.c:3278 [inline]
 __kmem_cache_alloc_lru mm/slab.c:3471 [inline]
 kmem_cache_alloc+0x39/0x520 mm/slab.c:3491
 fanotify_alloc_fid_event fs/notify/fanotify/fanotify.c:580 [inline]
 fanotify_alloc_event fs/notify/fanotify/fanotify.c:813 [inline]
 fanotify_handle_event+0x1130/0x3f40 fs/notify/fanotify/fanotify.c:948
 send_to_group fs/notify/fsnotify.c:360 [inline]
 fsnotify+0xafb/0x1680 fs/notify/fsnotify.c:570
 __fsnotify_parent+0x62f/0xa60 fs/notify/fsnotify.c:230
 fsnotify_parent include/linux/fsnotify.h:77 [inline]
 fsnotify_file include/linux/fsnotify.h:99 [inline]
 fsnotify_access include/linux/fsnotify.h:309 [inline]
 __io_complete_rw_common+0x485/0x720 io_uring/rw.c:195
 io_complete_rw+0x1a/0x1f0 io_uring/rw.c:228
 iomap_dio_complete_work fs/iomap/direct-io.c:144 [inline]
 iomap_dio_bio_end_io+0x438/0x5e0 fs/iomap/direct-io.c:178
 bio_endio+0x5f9/0x780 block/bio.c:1564
 req_bio_endio block/blk-mq.c:695 [inline]
 blk_update_request+0x3fc/0x1300 block/blk-mq.c:825
 scsi_end_request+0x7a/0x9a0 drivers/scsi/scsi_lib.c:541
 scsi_io_completion+0x173/0x1f70 drivers/scsi/scsi_lib.c:971
 scsi_complete+0x122/0x3b0 drivers/scsi/scsi_lib.c:1438
 blk_complete_reqs+0xad/0xe0 block/blk-mq.c:1022
 __do_softirq+0x1d3/0x9c6 kernel/softirq.c:571
 invoke_softirq kernel/softirq.c:445 [inline]
 __irq_exit_rcu+0x123/0x180 kernel/softirq.c:650
 irq_exit_rcu+0x5/0x20 kernel/softirq.c:662
 common_interrupt+0xa9/0xc0 arch/x86/kernel/irq.c:240
References: https://git.kernel.org/stable/c/2a853c206e553dd9c0a55c22858fd6a446d93e15; https://git.kernel.org/stable/c/89a410dbd0f159ddd308f19d6eb682fc753e4771; https://git.kernel.org/stable/c/b000145e[PII_REDACTED]d8164c3b2b8861d95aecd1
CVE: CVE-2022-50706
Published: 2025-12-24
Description: In the Linux kernel, the following vulnerability has been resolved:

net/ieee802154: don't warn zero-sized raw_sendmsg()

syzbot is hitting skb_assert_len() warning at __dev_queue_xmit() [1],
for PF_IEEE802154 socket's zero-sized raw_sendmsg() request is hitting
__dev_queue_xmit() with skb->len == 0.

Since PF_IEEE802154 socket's zero-sized raw_sendmsg() request was
able to return 0, don't call __dev_queue_xmit() if packet length is 0.

  ----------
  #include <sys/socket.h>
  #include <netinet/in.h>

  int main(int argc, char *argv[])
  {
    struct sockaddr_in addr = { .sin_family = AF_INET, .sin_addr.s_addr = htonl(INADDR_LOOPBACK) };
    struct iovec iov = { };
    struct msghdr hdr = { .msg_name = &addr, .msg_namelen = sizeof(addr), .msg_iov = &iov, .msg_iovlen = 1 };
    sendmsg(socket(PF_IEEE802154, SOCK_RAW, 0), &hdr, 0);
    return 0;
  }
  ----------

Note that this might be a sign that commit fd[PII_REDACTED]c484 ("bpf: Don't
redirect packets with invalid pkt_len") should be reverted, for
skb->len == 0 was acceptable for at least PF_IEEE802154 socket.
References: https://git.kernel.org/stable/c/34f31a2b667914ab701ca725554a0b447809d7ef; https://git.kernel.org/stable/c/4a36de8947794fa21435d1e916e089095f3246a8; https://git.kernel.org/stable/c/791489a5c56396ddfed75fc525066d4738dace46
CVE: CVE-2022-50707
Published: 2025-12-24
Description: In the Linux kernel, the following vulnerability has been resolved:

virtio-crypto: fix memory leak in virtio_crypto_alg_skcipher_close_session()

'vc_ctrl_req' is alloced in virtio_crypto_alg_skcipher_close_session(),
and should be freed in the invalid ctrl_status->status error handling
case. Otherwise there is a memory leak.
References: https://git.kernel.org/stable/c/0871df190fe6723464efe0f493d476411616f553; https://git.kernel.org/stable/c/67fb59ff1384e338679c0eb7a43c83ce8868c9fa; https://git.kernel.org/stable/c/79026a2d0a1b080257773d22a493f9bcab8c65be
CVE: CVE-2022-50708
Published: 2025-12-24
Description: In the Linux kernel, the following vulnerability has been resolved:

HSI: ssi_protocol: fix potential resource leak in ssip_pn_open()

ssip_pn_open() claims the HSI client's port with hsi_claim_port(). When
hsi_register_port_event() gets some error and returns a negetive value,
the HSI client's port should be released with hsi_release_port().

Fix it by calling hsi_release_port() when hsi_register_port_event() fails.
References: https://git.kernel.org/stable/c/78b0ef14896f843c45372f9bbdb6f6070f977eaf; https://git.kernel.org/stable/c/b28dbcb379e6a7f80262c2732a57681b1ee548ca; https://git.kernel.org/stable/c/e78b45b3eeee1cec77c794fcbf0512537c20b1dc
CVE: CVE-2022-50709
Published: 2025-12-24
Description: In the Linux kernel, the following vulnerability has been resolved:

wifi: ath9k: avoid uninit memory read in ath9k_htc_rx_msg()

syzbot is reporting uninit value at ath9k_htc_rx_msg() [1], for
ioctl(USB_RAW_IOCTL_EP_WRITE) can call ath9k_hif_usb_rx_stream() with
pkt_len = 0 but ath9k_hif_usb_rx_stream() uses
__dev_alloc_skb(pkt_len + 32, GFP_ATOMIC) based on an assumption that
pkt_len is valid. As a result, ath9k_hif_usb_rx_stream() allocates skb
with uninitialized memory and ath9k_htc_rx_msg() is reading from
uninitialized memory.

Since bytes accessed by ath9k_htc_rx_msg() is not known until
ath9k_htc_rx_msg() is called, it would be difficult to check minimal valid
pkt_len at "if (pkt_len > 2 * MAX_RX_BUF_SIZE) {" line in
ath9k_hif_usb_rx_stream().

We have two choices. One is to workaround by adding __GFP_ZERO so that
ath9k_htc_rx_msg() sees 0 if pkt_len is invalid. The other is to let
ath9k_htc_rx_msg() validate pkt_len before accessing. This patch chose
the latter.

Note that I'm not sure threshold condition is correct, for I can't find
details on possible packet length used by this protocol.
References: https://git.kernel.org/stable/c/0d2649b288b7b9484e3d4380c0d6c4720a17e473; https://git.kernel.org/stable/c/2c485f4f2a64258acc5228e78ffb828c68d9e770; https://git.kernel.org/stable/c/4891a50f5ed8bfcb8f2a4b816b0676f398687783
CVE: CVE-2022-50710
Published: 2025-12-24
Description: In the Linux kernel, the following vulnerability has been resolved:

ice: set tx_tstamps when creating new Tx rings via ethtool

When the user changes the number of queues via ethtool, the driver
allocates new rings. This allocation did not initialize tx_tstamps. This
results in the tx_tstamps field being zero (due to kcalloc allocation), and
would result in a NULL pointer dereference when attempting a transmit
timestamp on the new ring.
References: https://git.kernel.org/stable/c/13180cb88a7be5ee389f65f6ab9f78e46f7722b2; https://git.kernel.org/stable/c/624f03a027f2b18647cc4f1a7a81920a1e4e0201; https://git.kernel.org/stable/c/9eb5fff6b0e78819c758892282da5faa915724d0
CVE: CVE-2022-50711
Published: 2025-12-24
Description: In the Linux kernel, the following vulnerability has been resolved:

net: ethernet: mtk_eth_soc: fix possible memory leak in mtk_probe()

If mtk_wed_add_hw() has been called, mtk_wed_exit() needs be called
in error path or removing module to free the memory allocated in
mtk_wed_add_hw().
References: https://git.kernel.org/stable/c/96bde7c4f5683d8c1c809ddb781ef3fdec9b7215; https://git.kernel.org/stable/c/b3d0d98179d62f9d55635a600679c4fa362baf8d
CVE: CVE-2023-53867
Published: 2025-12-24
Description: In the Linux kernel, the following vulnerability has been resolved:

ceph: fix potential use-after-free bug when trimming caps

When trimming the caps and just after the 'session->s_cap_lock' is
released in ceph_iterate_session_caps() the cap maybe removed by
another thread, and when using the stale cap memory in the callbacks
it will trigger use-after-free crash.

We need to check the existence of the cap just after the 'ci->i_ceph_lock'
being acquired. And do nothing if it's already removed.
References: https://git.kernel.org/stable/c/2b2515b8095cf2149bef44383a99d5b5677f1831; https://git.kernel.org/stable/c/448875a73e16ba7d81dec9274ce9d33a12d092fb; https://git.kernel.org/stable/c/aaf67de78807c59c35bafb5003d4fb457c764800
CVE: CVE-2023-53986
Published: 2025-12-24
Description: In the Linux kernel, the following vulnerability has been resolved:

mips: bmips: BCM6358: disable RAC flush for TP1

RAC flush causes kernel panics on BCM6358 with EHCI/OHCI when booting from TP1:
[    3.881739] usb 1-1: new high-speed USB device number 2 using ehci-platform
[    3.895011] Reserved instruction in kernel code[#1]:
[    3.900113] CPU: 0 PID: 1 Comm: init Not tainted 5.10.16 #0
[    3.905829] $ 0   : [PII_REDACTED] 00000000 77d94060
[    3.911238] $ 4   : 7fd1f[PII_REDACTED]0 81431cac 81431ca0
[    3.916641] $ 8   : 00000000 ffffefff 8075cd34 00000000
[    3.922043] $12   : 806f8d40 f3e812b7 00000000 000d9aaa
[    3.927446] $16   : 7fd1f068 7fd1f080 7ff559b8 81428470
[    3.932848] $20   : [PII_REDACTED] 55590000 77d70000
[    3.938251] $24   : [PII_REDACTED]
[    3.943655] $28   : 8[PII_REDACTED]1e60 81431f28 800157fc
[    3.949058] Hi    : 00000000
[    3.952013] Lo    : 00000000
[    3.955019] epc   : 80015808 setup_sigcontext+0x54/0x24c
[    3.960464] ra    : 800157fc setup_sigcontext+0x48/0x24c
[    3.965913] Status: 10008703	KERNEL EXL IE
[    3.970216] Cause : 00800028 (ExcCode 0a)
[    3.974340] PrId  : 0002a010 (Broadcom BMIPS4350)
[    3.979170] Modules linked in: ohci_platform ohci_hcd fsl_mph_dr_of ehci_platform ehci_fsl ehci_hcd gpio_button_hotplug usbcore nls_base usb_common
[    3.992907] Process init (pid: 1, threadinfo=(ptrval), task=(ptrval), tls=77e22ec8)
[    4.000776] Stack : 81431ef4 7fd1f080 81431f28 81428470 7fd1f068 81431edc 7ff559b8 81428470
[    4.009467]         81431f28 7fd1f[PII_REDACTED]0 77d70000 77d5498c 80015c70 806f0000 8063ae74
[    4.018149]         08[PII_REDACTED]1f28 0000000a 08[PII_REDACTED]1f28 0000000a 77d6b[PII_REDACTED]3
[    4.026831]         ffffffff [PII_REDACTED] 81431ecc 81431ecc [PII_REDACTED] 04000000
[    4.035512]         77d54874 [PII_REDACTED] [PII_REDACTED] [PII_REDACTED] 00000000
[    4.044196]         ...
[    4.046706] Call Trace:
[    4.049238] [<80015808>] setup_sigcontext+0x54/0x24c
[    4.054356] [<80015c70>] setup_frame+0xdc/0x124
[    4.059015] [<80016414>] do_notify_resume+0x1dc/0x288
[    4.064207] [<80011b50>] work_notifysig+0x10/0x18
[    4.069036]
[    4.070538] Code: 8fc300b4  00001025  26240008 <ac820000> ac830004  3c048063  0c0228aa  24846a00  26240010
[    4.080686]
[    4.082517] ---[ end trace 22a8edb41f5f983b ]---
[    4.087374] Kernel panic - not syncing: Fatal exception
[    4.092753] Rebooting in 1 seconds..

Because the bootloader (CFE) is not initializing the Read-ahead cache properly
on the second thread (TP1). Since the RAC was not initialized properly, we
should avoid flushing it at the risk of corrupting the instruction stream as
seen in the trace above.
References: https://git.kernel.org/stable/c/288c96aa5b5526cd4a946e84ef85e165857693b5; https://git.kernel.org/stable/c/2cdbcff99f15db86a10672fb220379a1ae46ccae; https://git.kernel.org/stable/c/47a449ec09b4479b89dcc6b27ec3829fc82ffafb
CVE: CVE-2023-53987
Published: 2025-12-24
Description: In the Linux kernel, the following vulnerability has been resolved:

ping: Fix potentail NULL deref for /proc/net/icmp.

After commit dbca1596bbb0 ("ping: convert to RCU lookups, get rid
of rwlock"), we use RCU for ping sockets, but we should use spinlock
for /proc/net/icmp to avoid a potential NULL deref mentioned in
the previous patch.

Let's go back to using spinlock there.

Note we can convert ping sockets to use hlist instead of hlist_nulls
because we do not use SLAB_TYPESAFE_BY_RCU for ping sockets.
References: https://git.kernel.org/stable/c/176cbb6da28f36506cc60a4bec4ab8df0c16713a; https://git.kernel.org/stable/c/5a08a32e624908890aa0a2eb442bb6a7669891a8; https://git.kernel.org/stable/c/ab5fb73ffa01072b4d8031cc05801fa1cb653bee
CVE: CVE-2023-53988
Published: 2025-12-24
Description: In the Linux kernel, the following vulnerability has been resolved:

fs/ntfs3: Fix slab-out-of-bounds read in hdr_delete_de()

Here is a BUG report from syzbot:

BUG: KASAN: slab-out-of-bounds in hdr_delete_de+0xe0/0x150 fs/ntfs3/index.c:806
Read of size 16842960 at addr ffff888079cc0600 by task syz-executor934/3631

Call Trace:
 memmove+0x25/0x60 mm/kasan/shadow.c:54
 hdr_delete_de+0xe0/0x150 fs/ntfs3/index.c:806
 indx_delete_entry+0x74f/0x3670 fs/ntfs3/index.c:2193
 ni_remove_name+0x27a/0x980 fs/ntfs3/frecord.c:2910
 ntfs_unlink_inode+0x3d4/0x720 fs/ntfs3/inode.c:1712
 ntfs_rename+0x41a/0xcb0 fs/ntfs3/namei.c:276

Before using the meta-data in struct INDEX_HDR, we need to
check index header valid or not. Otherwise, the corruptedi
(or malicious) fs image can cause out-of-bounds access which
could make kernel panic.
References: https://git.kernel.org/stable/c/114204d25e1dffdd3a0c1cfbba219afd344f4b4f; https://git.kernel.org/stable/c/4a034ece7e2877673d9085d6e7ed45e6ee40b761; https://git.kernel.org/stable/c/9163a5b4ed290da4a7d23fa92533e0e81fd0166e
CVE: CVE-2023-53989
Published: 2025-12-24
Description: In the Linux kernel, the following vulnerability has been resolved:

arm64: mm: fix VA-range sanity check

Both create_mapping_noalloc() and update_mapping_prot() sanity-check
their 'virt' parameter, but the check itself doesn't make much sense.
The condition used today appears to be a historical accident.

The sanity-check condition:

	if ((virt >= PAGE_END) && (virt < VMALLOC_START)) {
		[ ... warning here ... ]
		return;
	}

... can only be true for the KASAN shadow region or the module region,
and there's no reason to exclude these specifically for creating and
updateing mappings.

When arm64 support was first upstreamed in commit:

  c1cc1552616d0f35 ("arm64: MMU initialisation")

... the condition was:

	if (virt < VMALLOC_START) {
		[ ... warning here ... ]
		return;
	}

At the time, VMALLOC_START was the lowest kernel address, and this was
checking whether 'virt' would be translated via TTBR1.

Subsequently in commit:

  14c127c957c1c607 ("arm64: mm: Flip kernel VA space")

... the condition was changed to:

	if ((virt >= VA_START) && (virt < VMALLOC_START)) {
		[ ... warning here ... ]
		return;
	}

This appear to have been a thinko. The commit moved the linear map to
the bottom of the kernel address space, with VMALLOC_START being at the
halfway point. The old condition would warn for changes to the linear
map below this, and at the time VA_START was the end of the linear map.

Subsequently we cleaned up the naming of VA_START in commit:

  77ad4ce69321abbe ("arm64: memory: rename VA_START to PAGE_END")

... keeping the erroneous condition as:

	if ((virt >= PAGE_END) && (virt < VMALLOC_START)) {
		[ ... warning here ... ]
		return;
	}

Correct the condition to check against the start of the TTBR1 address
space, which is currently PAGE_OFFSET. This simplifies the logic, and
more clearly matches the "outside kernel range" message in the warning.
References: https://git.kernel.org/stable/c/32020fc2a8373d3de35ae6d029d5969a42651e7a; https://git.kernel.org/stable/c/621619f626cbe702ddbdc54117f3868b8ebd8129; https://git.kernel.org/stable/c/9d8d3df71516ec3236d8d93ff029d251377ba4b1
CVE: CVE-2023-53990
Published: 2025-12-24
Description: In the Linux kernel, the following vulnerability has been resolved:

SMB3: Add missing locks to protect deferred close file list

cifs_del_deferred_close function has a critical section which modifies
the deferred close file list. We must acquire deferred_lock before
calling cifs_del_deferred_close function.
References: https://git.kernel.org/stable/c/0f87e18203bd30f71eb1a65259e28e291b6cc43a; https://git.kernel.org/stable/c/32a046ccaeea6c19965c04a4c521e703f6607924; https://git.kernel.org/stable/c/3aa9d065b0685b4e6052f3f2a2462966fdc44fd2
CVE: CVE-2023-53991
Published: 2025-12-24
Description: In the Linux kernel, the following vulnerability has been resolved:

drm/msm/dpu: Disallow unallocated resources to be returned

In the event that the topology requests resources that have not been
created by the system (because they are typically not represented in
dpu_mdss_cfg ^1), the resource(s) in global_state (in this case DSC
blocks, until their allocation/assignment is being sanity-checked in
"drm/msm/dpu: Reject topologies for which no DSC blocks are available")
remain NULL but will still be returned out of
dpu_rm_get_assigned_resources, where the caller expects to get an array
containing num_blks valid pointers (but instead gets these NULLs).

To prevent this from happening, where null-pointer dereferences
typically result in a hard-to-debug platform lockup, num_blks shouldn't
increase past NULL blocks and will print an error and break instead.
After all, max_blks represents the static size of the maximum number of
blocks whereas the actual amount varies per platform.

^1: which can happen after a git rebase ended up moving additions to
_dpu_cfg to a different struct which has the same patch context.

Patchwork: https://patchwork.freedesktop.org/patch/517636/
References: https://git.kernel.org/stable/c/8dbd54d679e3ab37be43bc1ed9f463dbf83a2259; https://git.kernel.org/stable/c/9e1e236acdc42b5c43ec8d7f03a39537e70cc309; https://git.kernel.org/stable/c/9fe3644c720ac87d150f0bba5a4ae86cae55afaf
CVE: CVE-2023-53992
Published: 2025-12-24
Description: In the Linux kernel, the following vulnerability has been resolved:

wifi: cfg80211: ocb: don't leave if not joined

If there's no OCB state, don't ask the driver/mac80211 to
leave, since that's just confusing. Since set/clear the
chandef state, that's a simple check.
References: https://git.kernel.org/stable/c/[PII_REDACTED]2967b7d63294b43428c8ed075b20e6; https://git.kernel.org/stable/c/abc76cf552e13cfa88a204b362a86b0e08e95228; https://git.kernel.org/stable/c/d7b0fe3487d203c04ee1bda91a63bd4dd398c350
CVE: CVE-2023-53993
Published: 2025-12-24
Description: In the Linux kernel, the following vulnerability has been resolved:

PCI/DOE: Fix memory leak with CONFIG_DEBUG_OBJECTS=y

After a pci_doe_task completes, its work_struct needs to be destroyed
to avoid a memory leak with CONFIG_DEBUG_OBJECTS=y.
References: https://git.kernel.org/stable/c/2a0e0f4773fe8032fb17e56f897bee32ce3cdc2b; https://git.kernel.org/stable/c/95628b[PII_REDACTED]31d3d74f73f431f501c5d6f5; https://git.kernel.org/stable/c/abf04be0e7071f2bcd39bf97ba407e7d4439785e
CVE: CVE-2023-53994
Published: 2025-12-24
Description: In the Linux kernel, the following vulnerability has been resolved:

ionic: remove WARN_ON to prevent panic_on_warn

Remove unnecessary early code development check and the WARN_ON
that it uses.  The irq alloc and free paths have long been
cleaned up and this check shouldn't have stuck around so long.
References: https://git.kernel.org/stable/c/1417dd787a5e55b410a00a28231b0dcb19172457; https://git.kernel.org/stable/c/4c7276a6daf7e13a6dd30b0347b3f2c7df4d40bb; https://git.kernel.org/stable/c/abfb2a58a5377ebab717d4362d6180f901b6e5c1
CVE: CVE-2023-53995
Published: 2025-12-24
Description: In the Linux kernel, the following vulnerability has been resolved:

net: ipv4: fix one memleak in __inet_del_ifa()

I got the below warning when do fuzzing test:
unregister_netdevice: waiting for bond0 to become free. Usage count = 2

It can be repoduced via:

ip link add bond0 type bond
sysctl -w net.ipv4.conf.bond0.promote_secondaries=1
ip addr add 4.117.174.103/0 scope 0x40 dev bond0
ip addr add 192.168.100.111/255.255.255.254 scope 0 dev bond0
ip addr add 0.0.0.4/0 scope 0x40 secondary dev bond0
ip addr del 4.117.174.103/0 scope 0x40 dev bond0
ip link delete bond0 type bond

In this reproduction test case, an incorrect 'last_prim' is found in
__inet_del_ifa(), as a result, the secondary address(0.0.0.4/0 scope 0x40)
is lost. The memory of the secondary address is leaked and the reference of
in_device and net_device is leaked.

Fix this problem:
Look for 'last_prim' starting at location of the deleted IP and inserting
the promoted IP into the location of 'last_prim'.
References: https://git.kernel.org/stable/c/2f1e86014d0cc084886c36a2d77bc620e2d42618; https://git.kernel.org/stable/c/42652af5360d30b43b06057c193739e7dfb18f42; https://git.kernel.org/stable/c/5624f26a3574500ce23929cb2c9976a0dec9920a
CVE: CVE-2023-53996
Published: 2025-12-24
Description: In the Linux kernel, the following vulnerability has been resolved:

x86/sev: Make enc_dec_hypercall() accept a size instead of npages

enc_dec_hypercall() accepted a page count instead of a size, which
forced its callers to round up. As a result, non-page aligned
vaddrs caused pages to be spuriously marked as decrypted via the
encryption status hypercall, which in turn caused consistent
corruption of pages during live migration. Live migration requires
accurate encryption status information to avoid migrating pages
from the wrong perspective.
References: https://git.kernel.org/stable/c/6615212d8e131b45bd9705b0d69cc0d2f624666f; https://git.kernel.org/stable/c/8ae7457e71a320867d868f2622d7c643596e4f43; https://git.kernel.org/stable/c/ac3f9c9f1b37edaa7d1a9b908bc79d843955a1a2
CVE: CVE-2023-53997
Published: 2025-12-24
Description: In the Linux kernel, the following vulnerability has been resolved:

thermal: of: fix double-free on unregistration

Since commit 3d439b1a2ad3 ("thermal/core: Alloc-copy-free the thermal
zone parameters structure"), thermal_zone_device_register() allocates
a copy of the tzp argument and frees it when unregistering, so
thermal_of_zone_register() now ends up leaking its original tzp and
double-freeing the tzp copy. Fix this by locating tzp on stack instead.
References: https://git.kernel.org/stable/c/ac4436a5b20e0ef1f608a9ef46c08d5d142f8da6; https://git.kernel.org/stable/c/adce49089412a9ae28f5c666e0bb12fbcd86b3f7
CVE: CVE-2023-53998
Published: 2025-12-24
Description: In the Linux kernel, the following vulnerability has been resolved:

hwrng: virtio - Fix race on data_avail and actual data

The virtio rng device kicks off a new entropy request whenever the
data available reaches zero.  When a new request occurs at the end
of a read operation, that is, when the result of that request is
only needed by the next reader, then there is a race between the
writing of the new data and the next reader.

This is because there is no synchronisation whatsoever between the
writer and the reader.

Fix this by writing data_avail with smp_store_release and reading
it with smp_load_acquire when we first enter read.  The subsequent
reads are safe because they're either protected by the first load
acquire, or by the completion mechanism.

Also remove the redundant zeroing of data_idx in random_recv_done
(data_idx must already be zero at this point) and data_avail in
request_entropy (ditto).
References: https://git.kernel.org/stable/c/22c30022cde6e2c88612b3a499223cfa912f1bc7; https://git.kernel.org/stable/c/241ef15776a7c8505008db689175b320d345ecd3; https://git.kernel.org/stable/c/2fc91f156b3f3446a1bce80cf4adedcbf41271c2