deardaniel/secdata-raw huggingface dataset:
CVE: CVE-2024-45653
Published: 2025-01-19
Description: IBM Sterling Connect:Direct Web Services 6.0, 6.1, 6.2, and 6.3 could disclose sensitive IP address information to authenticated users in responses that could be used in further attacks against the system.
CVSS Score: 4.3 (MEDIUM)
CWE: CWE-201
References: https://www.ibm.com/support/pages/node/7174104
CVE: CVE-2024-45654
Published: 2025-01-19
Description: IBM Security ReaQta 3.12 could allow an authenticated user to perform unauthorized actions due to reliance on untrusted inputs.
CVSS Score: 4.3 (MEDIUM)
CWE: CWE-807
References: https://www.ibm.com/support/pages/node/7175072
CVE: CVE-2025-0564
Published: 2025-01-19
Description: A vulnerability was found in code-projects Fantasy-Cricket 1.0. It has been declared as critical. Affected by this vulnerability is an unknown functionality of the file /authenticate.php. The manipulation of the argument uname leads to sql injection. The attack can be launched remotely. The exploit has been disclosed to the public and may be used.
CVSS Score: 7.3 (HIGH)
CWE: CWE-74, CWE-89, CWE-89
References: https://code-projects.org/; https://github.com/LiuSir5211314/-sir/issues/3; https://vuldb.com/?ctiid.292525
CVE: CVE-2024-8722
Published: 2025-01-19
Description: The Import any XML or CSV File to WordPress PRO plugin for WordPress is vulnerable to Stored Cross-Site Scripting via SVG File uploads in all versions up to, and including, 4.9.7 due to insufficient input sanitization and output escaping. This makes it possible for authenticated attackers, with Administrator-level access and above, to inject arbitrary web scripts in pages that will execute whenever a user accesses the SVG file.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-79
References: https://www.wordfence.com/threat-intel/vulnerabilities/id/dbc6ad3f-698e-4dfd-bbba-086f94831bba?source=cve; https://www.wpallimport.com/downloads/wp-all-import-annual/?changelog=1; https://www.wpallimport.com/wp-all-import-wp-all-export-important-security-updates/
CVE: CVE-2025-0565
Published: 2025-01-19
Description: A vulnerability was found in ZZCMS 2023. It has been rated as critical. Affected by this issue is some unknown functionality of the file /index.php. The manipulation of the argument id leads to sql injection. The attack may be launched remotely. The exploit has been disclosed to the public and may be used.
CVSS Score: 7.3 (HIGH)
CWE: CWE-74, CWE-89, CWE-89
References: https://github.com/En0t5/vul/blob/main/zzcms/zzcsm-sql-inject.md; https://vuldb.com/?ctiid.292526; https://vuldb.com/?id.292526
CVE: CVE-2025-0566
Published: 2025-01-19
Description: A vulnerability classified as critical has been found in Tenda AC15 15.13.07.13. This affects the function formSetDevNetName of the file /goform/SetDevNetName. The manipulation of the argument mac leads to stack-based buffer overflow. It is possible to initiate the attack remotely. The exploit has been disclosed to the public and may be used.
CVSS Score: 8.8 (HIGH)
CWE: CWE-119, CWE-121, CWE-787
References: https://pan.baidu.com/s/1DBDf27oCTIMkW-PSZwg02Q?pwd=tara; https://vuldb.com/?ctiid.292527; https://vuldb.com/?id.292527
CVE: CVE-2025-0567
Published: 2025-01-19
Description: A vulnerability classified as problematic was found in Epic Games Launcher up to 17.2.1. This vulnerability affects unknown code in the library profapi.dll of the component Installer. The manipulation leads to untrusted search path. Attacking locally is a requirement. The complexity of an attack is rather high. The exploitation appears to be difficult.
CVSS Score: 4.5 (MEDIUM)
CWE: CWE-426
References: https://vuldb.com/?ctiid.292528; https://vuldb.com/?id.292528; https://vuldb.com/?submit.481104
CVE: CVE-2025-21632
Published: 2025-01-19
Description: In the Linux kernel, the following vulnerability has been resolved:

x86/fpu: Ensure shadow stack is active before "getting" registers

The x86 shadow stack support has its own set of registers. Those registers
are XSAVE-managed, but they are "supervisor state components" which means
that userspace can not touch them with XSAVE/XRSTOR.  It also means that
they are not accessible from the existing ptrace ABI for XSAVE state.
Thus, there is a new ptrace get/set interface for it.

The regset code that ptrace uses provides an ->active() handler in
addition to the get/set ones. For shadow stack this ->active() handler
verifies that shadow stack is enabled via the ARCH_SHSTK_SHSTK bit in the
thread struct. The ->active() handler is checked from some call sites of
the regset get/set handlers, but not the ptrace ones. This was not
understood when shadow stack support was put in place.

As a result, both the set/get handlers can be called with
XFEATURE_CET_USER in its init state, which would cause get_xsave_addr() to
return NULL and trigger a WARN_ON(). The ssp_set() handler luckily has an
ssp_active() check to avoid surprising the kernel with shadow stack
behavior when the kernel is not ready for it (ARCH_SHSTK_SHSTK==0). That
check just happened to avoid the warning.

But the ->get() side wasn't so lucky. It can be called with shadow stacks
disabled, triggering the warning in practice, as reported by Christina
Schimpe:

WARNING: CPU: 5 PID: 1773 at arch/x86/kernel/fpu/regset.c:198 ssp_get+0x89/0xa0
[...]
Call Trace:
<TASK>
? show_regs+0x6e/0x80
? ssp_get+0x89/0xa0
? __warn+0x91/0x150
? ssp_get+0x89/0xa0
? report_bug+0x19d/0x1b0
? handle_bug+0x46/0x80
? exc_invalid_op+0x1d/0x80
? asm_exc_invalid_op+0x1f/0x30
? __pfx_ssp_get+0x10/0x10
? ssp_get+0x89/0xa0
? ssp_get+0x52/0xa0
__regset_get+0xad/0xf0
copy_regset_to_user+0x52/0xc0
ptrace_regset+0x119/0x140
ptrace_request+0x13c/0x850
? wait_task_inactive+0x142/0x1d0
? do_syscall_64+0x6d/0x90
arch_ptrace+0x102/0x300
[...]

Ensure that shadow stacks are active in a thread before looking them up
in the XSAVE buffer. Since ARCH_SHSTK_SHSTK and user_ssp[SHSTK_EN] are
set at the same time, the active check ensures that there will be
something to find in the XSAVE buffer.

[ dhansen: changelog/subject tweaks ]
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-476
References: https://git.kernel.org/stable/c/0a3a872214188e4268d31581ed0cd44508e038cf; https://git.kernel.org/stable/c/6bfe1fc22f462bec87422cdcbec4d7a2f43ff01d; https://git.kernel.org/stable/c/a9d9c33132d49329ada647e4514d210d15e31d81
CVE: CVE-2025-21633
Published: 2025-01-19
Description: Rejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.
CVE: CVE-2025-21634
Published: 2025-01-19
Description: In the Linux kernel, the following vulnerability has been resolved:

cgroup/cpuset: remove kernfs active break

A warning was found:

WARNING: CPU: 10 PID: 3486953 at fs/kernfs/file.c:828
CPU: 10 PID: 3486953 Comm: rmdir Kdump: loaded Tainted: G
RIP: 0010:kernfs_should_drain_open_files+0x1a1/0x1b0
RSP: 0018:ffff8881107ef9e0 EFLAGS: 00010202
RAX: [PII_REDACTED] RBX: ffff888154738c00 RCX: dffffc[PII_REDACTED]
RDX: [PII_REDACTED] RSI: [PII_REDACTED] RDI: ffff888154738c04
RBP: ffff888154738c04 R08: ffffffffaf27fa15 R09: ffffed102a8e7180
R10: ffff888154738c07 R11: [PII_REDACTED] R12: ffff888154738c08
R13: ffff888750f8c000 R14: ffff888750f8c0e8 R15: ffff888154738ca0
FS:  00007f84cd0be740(0000) GS:ffff8887ddc00000(0000) knlGS:[PII_REDACTED]
CS:  0010 DS: 0000 ES: 0000 CR0: [PII_REDACTED]
CR2: 0000555f9fbe00c8 CR3:[PII_REDACTED]eec001 CR4:[PII_REDACTED]370ee0
DR0: [PII_REDACTED] DR1: [PII_REDACTED] DR2: [PII_REDACTED]
DR3: [PII_REDACTED] DR6: 00000000fffe0ff0 DR7: [PII_REDACTED]
Call Trace:
 kernfs_drain+0x15e/0x2f0
 __kernfs_remove+0x165/0x300
 kernfs_remove_by_name_ns+0x7b/0xc0
 cgroup_rm_file+0x154/0x1c0
 cgroup_addrm_files+0x1c2/0x1f0
 css_clear_dir+0x77/0x110
 kill_css+0x4c/0x1b0
 cgroup_destroy_locked+0x194/0x380
 cgroup_rmdir+0x2a/0x140

It can be explained by:
rmdir 				echo 1 > cpuset.cpus
				kernfs_fop_write_iter // active=0
cgroup_rm_file
kernfs_remove_by_name_ns	kernfs_get_active // active=1
__kernfs_remove					  // active=0x80000002
kernfs_drain			cpuset_write_resmask
wait_event
//waiting (active == 0x80000001)
				kernfs_break_active_protection
				// active = 0x80000001
// continue
				kernfs_unbreak_active_protection
				// active = 0x80000002
...
kernfs_should_drain_open_files
// warning occurs
				kernfs_put_active

This warning is caused by 'kernfs_break_active_protection' when it is
writing to cpuset.cpus, and the cgroup is removed concurrently.

The commit 3a5a6d0c2b03 ("cpuset: don't nest cgroup_mutex inside
get_online_cpus()") made cpuset_hotplug_workfn asynchronous, This change
involves calling flush_work(), which can create a multiple processes
circular locking dependency that involve cgroup_mutex, potentially leading
to a deadlock. To avoid deadlock. the commit 76bb5ab8f6e3 ("cpuset: break
kernfs active protection in cpuset_write_resmask()") added
'kernfs_break_active_protection' in the cpuset_write_resmask. This could
lead to this warning.

After the commit 2125c0034c5d ("cgroup/cpuset: Make cpuset hotplug
processing synchronous"), the cpuset_write_resmask no longer needs to
wait the hotplug to finish, which means that concurrent hotplug and cpuset
operations are no longer possible. Therefore, the deadlock doesn't exist
anymore and it does not have to 'break active protection' now. To fix this
warning, just remove kernfs_break_active_protection operation in the
'cpuset_write_resmask'.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-667, CWE-667
References: https://git.kernel.org/stable/c/11cb1d643a74665a4e14749414f48f82cbc15c64; https://git.kernel.org/stable/c/3cb97a927fffe443e1e7e8eddbfebfdb062e86ed
CVE: CVE-2025-21635
Published: 2025-01-19
Description: In the Linux kernel, the following vulnerability has been resolved:

rds: sysctl: rds_tcp_{rcv,snd}buf: avoid using current->nsproxy

As mentioned in a previous commit of this series, using the 'net'
structure via 'current' is not recommended for different reasons:

- Inconsistency: getting info from the reader's/writer's netns vs only
  from the opener's netns.

- current->nsproxy can be NULL in some cases, resulting in an 'Oops'
  (null-ptr-deref), e.g. when the current task is exiting, as spotted by
  syzbot [1] using acct(2).

The per-netns structure can be obtained from the table->data using
container_of(), then the 'net' one can be retrieved from the listen
socket (if available).
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-476, CWE-476
References: https://git.kernel.org/stable/c/7f5611cbc4871c7fb1ad36c2e5a9edad63dca95c; https://git.kernel.org/stable/c/de8d6de0ee27be4b2b1e5b06f04aeacbabbba492
CVE: CVE-2025-21636
Published: 2025-01-19
Description: In the Linux kernel, the following vulnerability has been resolved:

sctp: sysctl: plpmtud_probe_interval: avoid using current->nsproxy

As mentioned in a previous commit of this series, using the 'net'
structure via 'current' is not recommended for different reasons:

- Inconsistency: getting info from the reader's/writer's netns vs only
  from the opener's netns.

- current->nsproxy can be NULL in some cases, resulting in an 'Oops'
  (null-ptr-deref), e.g. when the current task is exiting, as spotted by
  syzbot [1] using acct(2).

The 'net' structure can be obtained from the table->data using
container_of().

Note that table->data could also be used directly, as this is the only
member needed from the 'net' structure, but that would increase the size
of this fix, to use '*data' everywhere 'net->sctp.probe_interval' is
used.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-476, CWE-476
References: https://git.kernel.org/stable/c/1dc5da6c4178f3e4b95c631418f72de9f86c0449; https://git.kernel.org/stable/c/284a221f8fa503628432c7bb5108277c688c6ffa; https://git.kernel.org/stable/c/44ee8635922b6eb940faddb961a8347c6857d722
CVE: CVE-2025-21637
Published: 2025-01-19
Description: In the Linux kernel, the following vulnerability has been resolved:

sctp: sysctl: udp_port: avoid using current->nsproxy

As mentioned in a previous commit of this series, using the 'net'
structure via 'current' is not recommended for different reasons:

- Inconsistency: getting info from the reader's/writer's netns vs only
  from the opener's netns.

- current->nsproxy can be NULL in some cases, resulting in an 'Oops'
  (null-ptr-deref), e.g. when the current task is exiting, as spotted by
  syzbot [1] using acct(2).

The 'net' structure can be obtained from the table->data using
container_of().

Note that table->data could also be used directly, but that would
increase the size of this fix, while 'sctp.ctl_sock' still needs to be
retrieved from 'net' structure.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-476, CWE-476
References: https://git.kernel.org/stable/c/0a0966312ac3eedd7f5f2a766ed4702df39a9a65; https://git.kernel.org/stable/c/55627918febdf9d71107a1e68d1528dc591c9a15; https://git.kernel.org/stable/c/5b77d73f3be5102720fb685b9e6900e3500e1096
CVE: CVE-2025-21638
Published: 2025-01-19
Description: In the Linux kernel, the following vulnerability has been resolved:

sctp: sysctl: auth_enable: avoid using current->nsproxy

As mentioned in a previous commit of this series, using the 'net'
structure via 'current' is not recommended for different reasons:

- Inconsistency: getting info from the reader's/writer's netns vs only
  from the opener's netns.

- current->nsproxy can be NULL in some cases, resulting in an 'Oops'
  (null-ptr-deref), e.g. when the current task is exiting, as spotted by
  syzbot [1] using acct(2).

The 'net' structure can be obtained from the table->data using
container_of().

Note that table->data could also be used directly, but that would
increase the size of this fix, while 'sctp.ctl_sock' still needs to be
retrieved from 'net' structure.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-476
References: https://git.kernel.org/stable/c/15649fd5415eda664ef35780c2013adeb5d9c695; https://git.kernel.org/stable/c/1b67030d39f2b00f94ac1f0af11ba6657589e4d3; https://git.kernel.org/stable/c/7ec30c54f339c640aa7e49d7e9f7bbed6bd42bf6
CVE: CVE-2025-21639
Published: 2025-01-19
Description: In the Linux kernel, the following vulnerability has been resolved:

sctp: sysctl: rto_min/max: avoid using current->nsproxy

As mentioned in a previous commit of this series, using the 'net'
structure via 'current' is not recommended for different reasons:

- Inconsistency: getting info from the reader's/writer's netns vs only
  from the opener's netns.

- current->nsproxy can be NULL in some cases, resulting in an 'Oops'
  (null-ptr-deref), e.g. when the current task is exiting, as spotted by
  syzbot [1] using acct(2).

The 'net' structure can be obtained from the table->data using
container_of().

Note that table->data could also be used directly, as this is the only
member needed from the 'net' structure, but that would increase the size
of this fix, to use '*data' everywhere 'net->sctp.rto_min/max' is used.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-476, CWE-476
References: https://git.kernel.org/stable/c/0f78f[PII_REDACTED]9e420935e646ae78212a38290; https://git.kernel.org/stable/c/246428bfb9e7db15c5cd08e1d0eca41b65af2b06; https://git.kernel.org/stable/c/4059507e34aa5fe0fa9fd5b2b5f0c8b26ab2d482
CVE: CVE-2025-21640
Published: 2025-01-19
Description: In the Linux kernel, the following vulnerability has been resolved:

sctp: sysctl: cookie_hmac_alg: avoid using current->nsproxy

As mentioned in a previous commit of this series, using the 'net'
structure via 'current' is not recommended for different reasons:

- Inconsistency: getting info from the reader's/writer's netns vs only
  from the opener's netns.

- current->nsproxy can be NULL in some cases, resulting in an 'Oops'
  (null-ptr-deref), e.g. when the current task is exiting, as spotted by
  syzbot [1] using acct(2).

The 'net' structure can be obtained from the table->data using
container_of().

Note that table->data could also be used directly, as this is the only
member needed from the 'net' structure, but that would increase the size
of this fix, to use '*data' everywhere 'net->sctp.sctp_hmac_alg' is
used.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-476
References: https://git.kernel.org/stable/c/03ca51faba2b017bf6c90e139434c4117d0afcdc; https://git.kernel.org/stable/c/3cd0659deb9c03535fd61839e91d4d4d3e51ac71; https://git.kernel.org/stable/c/5599b212d2f4466e1832a94e9932684aaa364587
CVE: CVE-2025-21641
Published: 2025-01-19
Description: In the Linux kernel, the following vulnerability has been resolved:

mptcp: sysctl: blackhole timeout: avoid using current->nsproxy

As mentioned in the previous commit, using the 'net' structure via
'current' is not recommended for different reasons:

- Inconsistency: getting info from the reader's/writer's netns vs only
  from the opener's netns.

- current->nsproxy can be NULL in some cases, resulting in an 'Oops'
  (null-ptr-deref), e.g. when the current task is exiting, as spotted by
  syzbot [1] using acct(2).

The 'pernet' structure can be obtained from the table->data using
container_of().
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-476, CWE-476
References: https://git.kernel.org/stable/c/4c74fbdc5ab95b13945be01e6065940b68222db7; https://git.kernel.org/stable/c/92cf7a51bdae24a32c592adcdd59a773ae149289
CVE: CVE-2025-21643
Published: 2025-01-19
Description: In the Linux kernel, the following vulnerability has been resolved:

netfs: Fix kernel async DIO

Netfslib needs to be able to handle kernel-initiated asynchronous DIO that
is supplied with a bio_vec[] array.  Currently, because of the async flag,
this gets passed to netfs_extract_user_iter() which throws a warning and
fails because it only handles IOVEC and UBUF iterators.  This can be
triggered through a combination of cifs and a loopback blockdev with
something like:

        mount //my/cifs/share /foo
        dd if=/dev/zero of=/foo/m0 bs=4K count=1K
        losetup --sector-size 4096 --direct-io=on /dev/loop2046 /foo/m0
        echo hello >/dev/loop2046

This causes the following to appear in syslog:

        WARNING: CPU: 2 PID: 109 at fs/netfs/iterator.c:50 netfs_extract_user_iter+0x170/0x250 [netfs]

and the write to fail.

Fix this by removing the check in netfs_unbuffered_write_iter_locked() that
causes async kernel DIO writes to be handled as userspace writes.  Note
that this change relies on the kernel caller maintaining the existence of
the bio_vec array (or kvec[] or folio_queue) until the op is complete.
CVSS Score: 5.5 (MEDIUM)
References: https://git.kernel.org/stable/c/3f6bc9e3ab9b127171d39f9ac6eca1abb693b731; https://git.kernel.org/stable/c/9f3a265836844eda30bf34c2584b8011fd4f0f49
CVE: CVE-2025-21644
Published: 2025-01-19
Description: In the Linux kernel, the following vulnerability has been resolved:

drm/xe: Fix tlb invalidation when wedging

If GuC fails to load, the driver wedges, but in the process it tries to
do stuff that may not be initialized yet. This moves the
xe_gt_tlb_invalidation_init() to be done earlier: as its own doc says,
it's a software-only initialization and should had been named with the
_early() suffix.

Move it to be called by xe_gt_init_early(), so the locks and seqno are
initialized, avoiding a NULL ptr deref when wedging:

	xe 0000:03:00.0: [drm] *ERROR* GT0: load failed: status: Reset = 0, BootROM = 0x50, UKernel = 0x00, MIA = 0x00, Auth = 0x01
	xe 0000:03:00.0: [drm] *ERROR* GT0: firmware signature verification failed
	xe 0000:03:00.0: [drm] *ERROR* CRITICAL: Xe has declared device 0000:03:00.0 as wedged.
	...
	BUG: kernel NULL pointer dereference, address: [PII_REDACTED]
	#PF: supervisor read access in kernel mode
	#PF: error_code(0x0000) - not-present page
	PGD 0 P4D 0
	Oops: Oops: 0000 [#1] PREEMPT SMP NOPTI
	CPU: 9 UID: 0 PID: 3908 Comm: modprobe Tainted: G     U  W          6.13.0-rc4-xe+ #3
	Tainted: [U]=USER, [W]=WARN
	Hardware name: Intel Corporation Alder Lake Client Platform/AlderLake-S ADP-S DDR5 UDIMM CRB, BIOS ADLSFWI1.R00.3275.A00[PII_REDACTED] 07/01/2022
	RIP: 0010:xe_gt_tlb_invalidation_reset+0x75/0x110 [xe]

This can be easily triggered by poking the GuC binary to force a
signature failure. There will still be an extra message,

	xe 0000:03:00.0: [drm] *ERROR* GT0: GuC mmio request 0x4100: no reply 0x4100

but that's better than a NULL ptr deref.

(cherry picked from commit 5001ef3af8f2c972d6fd9c5221a8457556f8bea6)
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-476, CWE-476
References: https://git.kernel.org/stable/c/09b94ddc58c6640cbbc7775a61a5387b8be71488; https://git.kernel.org/stable/c/9ab[PII_REDACTED]a9c45682d62424ba610edc3992d
CVE: CVE-2025-21645
Published: 2025-01-19
Description: In the Linux kernel, the following vulnerability has been resolved:

platform/x86/amd/pmc: Only disable IRQ1 wakeup where i8042 actually enabled it

Wakeup for IRQ1 should be disabled only in cases where i8042 had
actually enabled it, otherwise "wake_depth" for this IRQ will try to
drop below zero and there will be an unpleasant WARN() logged:

kernel: atkbd serio0: Disabling IRQ1 wakeup source to avoid platform firmware bug
kernel: ------------[ cut here ]------------
kernel: Unbalanced IRQ 1 wake disable
kernel: WARNING: CPU: 10 PID: 6431 at kernel/irq/manage.c:920 irq_set_irq_wake+0x147/0x1a0

The PMC driver uses DEFINE_SIMPLE_DEV_PM_OPS() to define its dev_pm_ops
which sets amd_pmc_suspend_handler() to the .suspend, .freeze, and
.poweroff handlers. i8042_pm_suspend(), however, is only set as
the .suspend handler.

Fix the issue by call PMC suspend handler only from the same set of
dev_pm_ops handlers as i8042_pm_suspend(), which currently means just
the .suspend handler.

To reproduce this issue try hibernating (S4) the machine after a fresh boot
without putting it into s2idle first.

[ij: edited the commit message.]
CVSS Score: 5.5 (MEDIUM)
References: https://git.kernel.org/stable/c/5cc621085e2b7a9b1905a98f8e5a86bb4aea2016; https://git.kernel.org/stable/c/ab47d72b736e78d3c2370b26e0bfc46eb0918391; https://git.kernel.org/stable/c/b25778c87a6bce40c31e92364f08aa6240309e25
CVE: CVE-2025-21646
Published: 2025-01-19
Description: In the Linux kernel, the following vulnerability has been resolved:

afs: Fix the maximum cell name length

The kafs filesystem limits the maximum length of a cell to 256 bytes, but a
problem occurs if someone actually does that: kafs tries to create a
directory under /proc/net/afs/ with the name of the cell, but that fails
with a warning:

        WARNING: CPU: 0 PID: 9 at fs/proc/generic.c:405

because procfs limits the maximum filename length to 255.

However, the DNS limits the maximum lookup length and, by extension, the
maximum cell name, to 255 less two (length count and trailing NUL).

Fix this by limiting the maximum acceptable cellname length to 253.  This
also allows us to be sure we can create the "/afs/.<cell>/" mountpoint too.

Further, split the YFS VL record cell name maximum to be the 256 allowed by
the protocol and ignore the record retrieved by YFSVL.GetCellName if it
exceeds 253.
CVSS Score: 5.5 (MEDIUM)
References: https://git.kernel.org/stable/c/7673030efe0f8ca1056d3849d61784c6caa052af; https://git.kernel.org/stable/c/7922b1f058fe24a93730511dd0ae2e[PII_REDACTED]; https://git.kernel.org/stable/c/7cb3e77e9b4e6ffa325a5559393d3283c9af3d01