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

KVM: SVM: Don't skip unrelated instruction if INT3/INTO is replaced

When re-injecting a soft interrupt from an INT3, INT0, or (select) INTn
instruction, discard the exception and retry the instruction if the code
stream is changed (e.g. by a different vCPU) between when the CPU
executes the instruction and when KVM decodes the instruction to get the
next RIP.

As effectively predicted by commit 6ef88d6e36c2 ("KVM: SVM: Re-inject
INT3/INTO instead of retrying the instruction"), failure to verify that
the correct INTn instruction was decoded can effectively clobber guest
state due to decoding the wrong instruction and thus specifying the
wrong next RIP.

The bug most often manifests as "Oops: int3" panics on static branch
checks in Linux guests.  Enabling or disabling a static branch in Linux
uses the kernel's "text poke" code patching mechanism.  To modify code
while other CPUs may be executing that code, Linux (temporarily)
replaces the first byte of the original instruction with an int3 (opcode
0xcc), then patches in the new code stream except for the first byte,
and finally replaces the int3 with the first byte of the new code
stream.  If a CPU hits the int3, i.e. executes the code while it's being
modified, then the guest kernel must look up the RIP to determine how to
handle the #BP, e.g. by emulating the new instruction.  If the RIP is
incorrect, then this lookup fails and the guest kernel panics.

The bug reproduces almost instantly by hacking the guest kernel to
repeatedly check a static branch[1] while running a drgn script[2] on
the host to constantly swap out the memory containing the guest's TSS.

[1]: https://gist.github.com/osandov/44d17c51c28c0ac998ea0334edf90b5a
[2]: https://gist.github.com/osandov/10e45e45afa29b11e0c7209247afc00b
References: https://git.kernel.org/stable/c/152289a51107ef45bbfe9b4aeeaa584a503042b5; https://git.kernel.org/stable/c/2e84a018c2895c05abe213eb10db128aa45f6ec6; https://git.kernel.org/stable/c/4da3768e1820cf15cced390242d8789aed34f54d
CVE: CVE-2025-68261
Published: 2025-12-16
Description: In the Linux kernel, the following vulnerability has been resolved:

ext4: add i_data_sem protection in ext4_destroy_inline_data_nolock()

Fix a race between inline data destruction and block mapping.

The function ext4_destroy_inline_data_nolock() changes the inode data
layout by clearing EXT4_INODE_INLINE_DATA and setting EXT4_INODE_EXTENTS.
At the same time, another thread may execute ext4_map_blocks(), which
tests EXT4_INODE_EXTENTS to decide whether to call ext4_ext_map_blocks()
or ext4_ind_map_blocks().

Without i_data_sem protection, ext4_ind_map_blocks() may receive inode
with EXT4_INODE_EXTENTS flag and triggering assert.

kernel BUG at fs/ext4/indirect.c:546!
EXT4-fs (loop2): unmounting filesystem.
invalid opcode: 0000 [#1] PREEMPT SMP KASAN NOPTI
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.12.0-1 04/01/2014
RIP: 0010:ext4_ind_map_blocks.cold+0x2b/0x5a fs/ext4/indirect.c:546

Call Trace:
 <TASK>
 ext4_map_blocks+0xb9b/0x16f0 fs/ext4/inode.c:681
 _ext4_get_block+0x242/0x590 fs/ext4/inode.c:822
 ext4_block_write_begin+0x48b/0x12c0 fs/ext4/inode.c:1124
 ext4_write_begin+0x598/0xef0 fs/ext4/inode.c:1255
 ext4_da_write_begin+0x21e/0x9c0 fs/ext4/inode.c:3000
 generic_perform_write+0x259/0x5d0 mm/filemap.c:3846
 ext4_buffered_write_iter+0x15b/0x470 fs/ext4/file.c:285
 ext4_file_write_iter+0x8e0/0x17f0 fs/ext4/file.c:679
 call_write_iter include/linux/fs.h:2271 [inline]
 do_iter_readv_writev+0x212/0x3c0 fs/read_write.c:735
 do_iter_write+0x186/0x710 fs/read_write.c:861
 vfs_iter_write+0x70/0xa0 fs/read_write.c:902
 iter_file_splice_write+0x73b/0xc90 fs/splice.c:685
 do_splice_from fs/splice.c:763 [inline]
 direct_splice_actor+0x10f/0x170 fs/splice.c:950
 splice_direct_to_actor+0x33a/0xa10 fs/splice.c:896
 do_splice_direct+0x1a9/0x280 fs/splice.c:1002
 do_sendfile+0xb13/0x12c0 fs/read_write.c:1255
 __do_sys_sendfile64 fs/read_write.c:1323 [inline]
 __se_sys_sendfile64 fs/read_write.c:1309 [inline]
 __x64_sys_sendfile64+0x1cf/0x210 fs/read_write.c:1309
 do_syscall_x64 arch/x86/entry/common.c:51 [inline]
 do_syscall_64+0x35/0x80 arch/x86/entry/common.c:81
 entry_SYSCALL_64_after_hwframe+0x6e/0xd8
References: https://git.kernel.org/stable/c/0cd8feea8777f8d9b9a862b89c688b049a5c8475; https://git.kernel.org/stable/c/144c48da33a01d92995aeccd8208eb47d2a8e659; https://git.kernel.org/stable/c/22a76b0861ae61a299c8e126c1aca8c4fda820fd
CVE: CVE-2025-68262
Published: 2025-12-16
Description: In the Linux kernel, the following vulnerability has been resolved:

crypto: zstd - fix double-free in per-CPU stream cleanup

The crypto/zstd module has a double-free bug that occurs when multiple
tfms are allocated and freed.

The issue happens because zstd_streams (per-CPU contexts) are freed in
zstd_exit() during every tfm destruction, rather than being managed at
the module level.  When multiple tfms exist, each tfm exit attempts to
free the same shared per-CPU streams, resulting in a double-free.

This leads to a stack trace similar to:

  BUG: Bad page state in process kworker/u16:1  pfn:106fd93
  page: refcount:0 mapcount:0 mapping:[PII_REDACTED] index:0x0 pfn:0x106fd93
  flags: 0x17ffffc0000000(node=0|zone=2|lastcpupid=0x1fffff)
  page_type: 0xffffffff()
  raw: 0017ffffc0000000 dead[PII_REDACTED]00 dead[PII_REDACTED]22 [PII_REDACTED]
  raw: [PII_REDACTED] [PII_REDACTED] 00000000ffffffff [PII_REDACTED]
  page dumped because: nonzero entire_mapcount
  Modules linked in: ...
  CPU: 3 UID: 0 PID: 2506 Comm: kworker/u16:1 Kdump: loaded Tainted: G    B
  Hardware name: ...
  Workqueue: btrfs-delalloc btrfs_work_helper
  Call Trace:
   <TASK>
   dump_stack_lvl+0x5d/0x80
   bad_page+0x71/0xd0
   free_unref_page_prepare+0x24e/0x490
   free_unref_page+0x60/0x170
   crypto_acomp_free_streams+0x5d/0xc0
   crypto_acomp_exit_tfm+0x23/0x50
   crypto_destroy_tfm+0x60/0xc0
   ...

Change the lifecycle management of zstd_streams to free the streams only
once during module cleanup.
References: https://git.kernel.org/stable/c/48bc9da3c97c15f1ea24934bcb3b736acd30163d; https://git.kernel.org/stable/c/dc0f4509b0ed5d82bef78e058db0ac4df04d0695; https://git.kernel.org/stable/c/e983feaa79de1e46c9087fb9f02fedb0e5397ce6
CVE: CVE-2025-68263
Published: 2025-12-16
Description: In the Linux kernel, the following vulnerability has been resolved:

ksmbd: ipc: fix use-after-free in ipc_msg_send_request

ipc_msg_send_request() waits for a generic netlink reply using an
ipc_msg_table_entry on the stack. The generic netlink handler
(handle_generic_event()/handle_response()) fills entry->response under
ipc_msg_table_lock, but ipc_msg_send_request() used to validate and free
entry->response without holding the same lock.

Under high concurrency this allows a race where handle_response() is
copying data into entry->response while ipc_msg_send_request() has just
freed it, leading to a slab-use-after-free reported by KASAN in
handle_generic_event():

  BUG: KASAN: slab-use-after-free in handle_generic_event+0x3c4/0x5f0 [ksmbd]
  Write of size 12 at addr ffff888198ee6e20 by task pool/109349
  ...
  Freed by task:
    kvfree
    ipc_msg_send_request [ksmbd]
    ksmbd_rpc_open -> ksmbd_session_rpc_open [ksmbd]

Fix by:
- Taking ipc_msg_table_lock in ipc_msg_send_request() while validating
  entry->response, freeing it when invalid, and removing the entry from
  ipc_msg_table.
- Returning the final entry->response pointer to the caller only after
  the hash entry is removed under the lock.
- Returning NULL in the error path, preserving the original API
  semantics.

This makes all accesses to entry->response consistent with
handle_response(), which already updates and fills the response buffer
under ipc_msg_table_lock, and closes the race that allowed the UAF.
CVSS Score: 9.8 (CRITICAL)
References: https://git.kernel.org/stable/c/1fab1fa091f5aa97265648b53ea031deedd26235; https://git.kernel.org/stable/c/5ac763713a1ef8f9a8bda1dbd81f0318d67baa4e; https://git.kernel.org/stable/c/708a620b471a14466f1f52c90bf3f65ebdb31460
CVE: CVE-2025-68264
Published: 2025-12-16
Description: In the Linux kernel, the following vulnerability has been resolved:

ext4: refresh inline data size before write operations

The cached ei->i_inline_size can become stale between the initial size
check and when ext4_update_inline_data()/ext4_create_inline_data() use
it. Although ext4_get_max_inline_size() reads the correct value at the
time of the check, concurrent xattr operations can modify i_inline_size
before ext4_write_lock_xattr() is acquired.

This causes ext4_update_inline_data() and ext4_create_inline_data() to
work with stale capacity values, leading to a BUG_ON() crash in
ext4_write_inline_data():

  kernel BUG at fs/ext4/inline.c:1331!
  BUG_ON(pos + len > EXT4_I(inode)->i_inline_size);

The race window:
1. ext4_get_max_inline_size() reads i_inline_size = 60 (correct)
2. Size check passes for 50-byte write
3. [Another thread adds xattr, i_inline_size changes to 40]
4. ext4_write_lock_xattr() acquires lock
5. ext4_update_inline_data() uses stale i_inline_size = 60
6. Attempts to write 50 bytes but only 40 bytes actually available
7. BUG_ON() triggers

Fix this by recalculating i_inline_size via ext4_find_inline_data_nolock()
immediately after acquiring xattr_sem. This ensures ext4_update_inline_data()
and ext4_create_inline_data() work with current values that are protected
from concurrent modifications.

This is similar to commit a54c4613dac1 ("ext4: fix race writing to an
inline_data file while its xattrs are changing") which fixed i_inline_off
staleness. This patch addresses the related i_inline_size staleness issue.
References: https://git.kernel.org/stable/c/1687a055a555347b002f406676a1aaae4668f242; https://git.kernel.org/stable/c/210ac60a86a3ad2c76ae60e0dc71c34af6e7ea0b; https://git.kernel.org/stable/c/43bf001f0fe4e59bba47c897505222f959f4a1cc
CVE: CVE-2025-68265
Published: 2025-12-16
Description: In the Linux kernel, the following vulnerability has been resolved:

nvme: fix admin request_queue lifetime

The namespaces can access the controller's admin request_queue, and
stale references on the namespaces may exist after tearing down the
controller. Ensure the admin request_queue is active by moving the
controller's 'put' to after all controller references have been released
to ensure no one is can access the request_queue. This fixes a reported
use-after-free bug:

  BUG: KASAN: slab-use-after-free in blk_queue_enter+0x41c/0x4a0
  Read of size 8 at addr ffff88c0a53819f8 by task nvme/3287
  CPU: 67 UID: 0 PID: 3287 Comm: nvme Tainted: G            E       6.13.2-ga1582f1a031e #15
  Tainted: [E]=UNSIGNED_MODULE
  Hardware name: Jabil /EGS 2S MB1, BIOS 1.00 06/18/2025
  Call Trace:
   <TASK>
   dump_stack_lvl+0x4f/0x60
   print_report+0xc4/0x620
   ? _raw_spin_lock_irqsave+0x70/0xb0
   ? _raw_read_unlock_irqrestore+0x30/0x30
   ? blk_queue_enter+0x41c/0x4a0
   kasan_report+0xab/0xe0
   ? blk_queue_enter+0x41c/0x4a0
   blk_queue_enter+0x41c/0x4a0
   ? __irq_work_queue_local+0x75/0x1d0
   ? blk_queue_start_drain+0x70/0x70
   ? irq_work_queue+0x18/0x20
   ? vprintk_emit.part.0+0x1cc/0x350
   ? wake_up_klogd_work_func+0x60/0x60
   blk_mq_alloc_request+0x2b7/0x6b0
   ? __blk_mq_alloc_requests+0x1060/0x1060
   ? __switch_to+0x5b7/0x1060
   nvme_submit_user_cmd+0xa9/0x330
   nvme_user_cmd.isra.0+0x240/0x3f0
   ? force_sigsegv+0xe0/0xe0
   ? nvme_user_cmd64+0x400/0x400
   ? vfs_fileattr_set+0x9b0/0x9b0
   ? cgroup_update_frozen_flag+0x24/0x1c0
   ? cgroup_leave_frozen+0x204/0x330
   ? nvme_ioctl+0x7c/0x2c0
   blkdev_ioctl+0x1a8/0x4d0
   ? blkdev_common_ioctl+0x1930/0x1930
   ? fdget+0x54/0x380
   __x64_sys_ioctl+0x129/0x190
   do_syscall_64+0x5b/0x160
   entry_SYSCALL_64_after_hwframe+0x4b/0x53
  RIP: 0033:0x7f765f703b0b
  Code: ff ff ff 85 c0 79 9b 49 c7 c4 ff ff ff ff 5b 5d 4c 89 e0 41 5c c3 66 0f 1f 84 00 00 00 00 00 f3 0f 1e fa b8 10 00 00 00 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d dd 52 0f 00 f7 d8 64 89 01 48
  RSP: 002b:00007ffe2cefe808 EFLAGS: 00000202 ORIG_RAX: [PII_REDACTED]
  RAX: ffffffffffffffda RBX: 00007ffe2cefe860 RCX: 00007f765f703b0b
  RDX: 00007ffe2cefe860 RSI: 00000000c0484e41 RDI: [PII_REDACTED]
  RBP: [PII_REDACTED] R08: [PII_REDACTED] R09: [PII_REDACTED]
  R10: 00007f765f611d50 R11: [PII_REDACTED] R12: [PII_REDACTED]
  R13: 00000000c0484e41 R14: [PII_REDACTED] R15: 00007ffe2cefea60
   </TASK>
References: https://git.kernel.org/stable/c/03b3bcd319b3ab5182bc9aaa[PII_REDACTED]c78ac0; https://git.kernel.org/stable/c/4896491c[PII_REDACTED]26c3acc46044fd182f943c; https://git.kernel.org/stable/c/a505f0ba36ab24176c300d7ff56aff85c2977e6c
CVE: CVE-2025-68266
Published: 2025-12-16
Description: In the Linux kernel, the following vulnerability has been resolved:

bfs: Reconstruct file type when loading from disk

syzbot is reporting that S_IFMT bits of inode->i_mode can become bogus when
the S_IFMT bits of the 32bits "mode" field loaded from disk are corrupted
or when the 32bits "attributes" field loaded from disk are corrupted.

A documentation says that BFS uses only lower 9 bits of the "mode" field.
But I can't find an explicit explanation that the unused upper 23 bits
(especially, the S_IFMT bits) are initialized with 0.

Therefore, ignore the S_IFMT bits of the "mode" field loaded from disk.
Also, verify that the value of the "attributes" field loaded from disk is
either BFS_VREG or BFS_VDIR (because BFS supports only regular files and
the root directory).
References: https://git.kernel.org/stable/c/34ab4c75588c07cca12884f2bf6b0347c7a13872; https://git.kernel.org/stable/c/77899444d46162aeb65f229590c26ba266864223; https://git.kernel.org/stable/c/8f73336b75bd3457b6f9410f2a0601a238f32238
CVE: CVE-2025-68281
Published: 2025-12-16
Description: In the Linux kernel, the following vulnerability has been resolved:

ASoC: SDCA: bug fix while parsing mipi-sdca-control-cn-list

"struct sdca_control" declares "values" field as integer array.
But the memory allocated to it is of char array. This causes
crash for sdca_parse_function API. This patch addresses the
issue by allocating correct data size.
References: https://git.kernel.org/stable/c/eb2d6774cc0d9d6ab8f924825695a85c14b2e0c2; https://git.kernel.org/stable/c/fcd5786b506c51cbabc2560c68e040d8dba22a0d
CVE: CVE-2025-10450
Published: 2025-12-16
Description: Exposure of Private Personal Information to an Unauthorized Actor vulnerability in RTI Connext Professional (Core Libraries) allows Sniffing Network Traffic.This issue affects Connext Professional: from 7.4.0 before 7.7.0, from 7.2.0 before 7.3.1.
CVSS Score: 7.5 (HIGH)
CWE: CWE-359
References: https://www.rti.com/vulnerabilities/#cve-2025-10450
CVE: CVE-2025-14432
Published: 2025-12-16
Description: In limited scenarios, sensitive data might be written to the log file if an admin uses Microsoft Teams Admin Center (TAC) to make device configuration changes. The affected log file is visible only to users with admin credentials. This is limited to Microsoft TAC and does not affect configuration changes made using the provisioning server or the device WebUI.
CVSS Score: 4.9 (MEDIUM)
CWE: CWE-532
References: https://support.hp.com/us-en/document/ish_13[PII_REDACTED]2332-16/hpsbpy04080
CVE: CVE-2025-62329
Published: 2025-12-16
Description: HCL DevOps Deploy / HCL Launch is susceptible to a race condition in http-session client-IP binding enforcement which may allow a session to be briefly reused from a new IP address before it is invalidated. This could lead to unauthorized access under certain network conditions.
CVSS Score: 5.0 (MEDIUM)
CWE: CWE-613
References: https://support.hcl-software.com/csm?id=kb_article&sysparm_article=KB0127332
CVE: CVE-2025-64012
Published: 2025-12-16
Description: InvoicePlane commit debb446c is vulnerable to Incorrect Access Control. The invoices/view handler fails to verify ownership before returning invoice data.
CVSS Score: 4.3 (MEDIUM)
CWE: CWE-639
References: https://gist.github.com/tarekramm/797073e9ae991211ff2ae71ed1190c7d; https://github.com/InvoicePlane/InvoicePlane/commit/debb446ceaa84efc136987fc1e21b268f34e47b0
CVE: CVE-2025-65318
Published: 2025-12-16
Description: When using the attachment interaction functionality, Canary Mail 5.1.40 and below saves documents to a file system without a Mark-of-the-Web tag, which allows attackers to bypass the built-in file protection mechanisms of both Windows OS and third-party software.
CVSS Score: 9.1 (CRITICAL)
CWE: CWE-693
References: http://canary.com; http://canarymail.com; https://drive.google.com/file/d/14wrTzvcLPfFsWmy-SAtDwwZKKPssBsx5/view
CVE: CVE-2025-65319
Published: 2025-12-16
Description: When using the attachment interaction functionality, Blue Mail 1.140.103 and below saves documents to a file system without a Mark-of-the-Web tag, which allows attackers to bypass the built-in file protection mechanisms of both Windows OS and third-party software.
CVSS Score: 9.1 (CRITICAL)
CWE: CWE-693
References: http://blue.com; https://drive.google.com/file/d/1dVzXuHBk3B1DiFpwFYwj2NNjeKGnGSwT/view; https://github.com/bbaboha/CVE-2025-65318-and-CVE-2025-65319
CVE: CVE-2025-65427
Published: 2025-12-16
Description: An issue was discovered in Dbit N300 T1 Pro Easy Setup Wireless Wi-Fi Router on firmware version V1.0.0 does not implement rate limiting to /api/login allowing attackers to brute force password enumerations.
CVSS Score: 6.5 (MEDIUM)
CWE: CWE-307
References: http://dbit.com; http://shenzhen.com; https://github.com/kirubel-cve/CVE-2025-65427
CVE: CVE-2025-68162
Published: 2025-12-16
Description: In JetBrains TeamCity before 2025.11 maven embedder allowed loading extensions via project configuration
CVSS Score: 2.7 (LOW)
CWE: CWE-829, CWE-829
References: https://www.jetbrains.com/privacy-security/issues-fixed/
CVE: CVE-2025-68163
Published: 2025-12-16
Description: In JetBrains TeamCity before 2025.11 stored XSS was possible on agentpushInstall page
CVSS Score: 3.5 (LOW)
CWE: CWE-79, CWE-79
References: https://www.jetbrains.com/privacy-security/issues-fixed/
CVE: CVE-2025-68164
Published: 2025-12-16
Description: In JetBrains TeamCity before 2025.11 port enumeration was possible via the Perforce connection test
CVSS Score: 2.7 (LOW)
CWE: CWE-203, CWE-203
References: https://www.jetbrains.com/privacy-security/issues-fixed/
CVE: CVE-2025-68165
Published: 2025-12-16
Description: In JetBrains TeamCity before 2025.11 reflected XSS was possible on VCS Root setup
CVSS Score: 5.4 (MEDIUM)
CWE: CWE-79, CWE-79
References: https://www.jetbrains.com/privacy-security/issues-fixed/
CVE: CVE-2025-68166
Published: 2025-12-16
Description: In JetBrains TeamCity before 2025.11 a DOM-based XSS was possible on the OAuth connections tab
CVSS Score: 5.4 (MEDIUM)
CWE: CWE-79, CWE-79
References: https://www.jetbrains.com/privacy-security/issues-fixed/
CVE: CVE-2025-68267
Published: 2025-12-16
Description: In JetBrains TeamCity before 2025.11.1 excessive privileges were possible due to storing GitHub personal access token instead of an installation token
CVSS Score: 6.5 (MEDIUM)
CWE: CWE-272
References: https://www.jetbrains.com/privacy-security/issues-fixed/
CVE: CVE-2025-68268
Published: 2025-12-16
Description: In JetBrains TeamCity before 2025.11.1 reflected XSS was possible on the storage settings page
CVSS Score: 5.4 (MEDIUM)
CWE: CWE-79
References: https://www.jetbrains.com/privacy-security/issues-fixed/
CVE: CVE-2025-68269
Published: 2025-12-16
Description: In JetBrains IntelliJ IDEA before 2025.3 missing confirmation allowed opening of untrusted remote projects over SSH
CVSS Score: 5.4 (MEDIUM)
CWE: CWE-349
References: https://www.jetbrains.com/privacy-security/issues-fixed/
CVE: CVE-2025-68282
Published: 2025-12-16
Description: In the Linux kernel, the following vulnerability has been resolved:

usb: gadget: udc: fix use-after-free in usb_gadget_state_work

A race condition during gadget teardown can lead to a use-after-free
in usb_gadget_state_work(), as reported by KASAN:

  BUG: KASAN: invalid-access in sysfs_notify+0x2c/0xd0
  Workqueue: events usb_gadget_state_work

The fundamental race occurs because a concurrent event (e.g., an
interrupt) can call usb_gadget_set_state() and schedule gadget->work
at any time during the cleanup process in usb_del_gadget().

Commit 399a45e5237c ("usb: gadget: core: flush gadget workqueue after
device removal") attempted to fix this by moving flush_work() to after
device_del(). However, this does not fully solve the race, as a new
work item can still be scheduled *after* flush_work() completes but
before the gadget's memory is freed, leading to the same use-after-free.

This patch fixes the race condition robustly by introducing a 'teardown'
flag and a 'state_lock' spinlock to the usb_gadget struct. The flag is
set during cleanup in usb_del_gadget() *before* calling flush_work() to
prevent any new work from being scheduled once cleanup has commenced.
The scheduling site, usb_gadget_set_state(), now checks this flag under
the lock before queueing the work, thus safely closing the race window.
References: https://git.kernel.org/stable/c/[PII_REDACTED]cf6736c1aeb4105c5f4a0818d0c65; https://git.kernel.org/stable/c/3b32caa73d135eea8fb9cabb45e9fc64c5a3ecb9; https://git.kernel.org/stable/c/baeb66fbd4201d1c4325074e78b1f557dff89b5b
CVE: CVE-2025-68283
Published: 2025-12-16
Description: In the Linux kernel, the following vulnerability has been resolved:

libceph: replace BUG_ON with bounds check for map->max_osd

OSD indexes come from untrusted network packets. Boundary checks are
added to validate these against map->max_osd.

[ idryomov: drop BUG_ON in ceph_get_primary_affinity(), minor cosmetic
  edits ]
References: https://git.kernel.org/stable/c/57f5fbae9f1024aba17ff75e[PII_REDACTED]5c548a; https://git.kernel.org/stable/c/b4368b7f97014e1015445d61abd0b27c4c6e8424; https://git.kernel.org/stable/c/becc488a4d864db338ebd4e313aa3c77da24b604
CVE: CVE-2025-68284
Published: 2025-12-16
Description: In the Linux kernel, the following vulnerability has been resolved:

libceph: prevent potential out-of-bounds writes in handle_auth_session_key()

The len field originates from untrusted network packets. Boundary
checks have been added to prevent potential out-of-bounds writes when
decrypting the connection secret or processing service tickets.

[ idryomov: changelog ]
References: https://git.kernel.org/stable/c/5ef575834ca99f719d7573cdece9df2fe2b72424; https://git.kernel.org/stable/c/6920ff09bf911bc919cd7a6b7176fbdd1a6e6850; https://git.kernel.org/stable/c/7fce830ecd0a0256590ee37eb65a39cbad3d64fc