deardaniel/secdata-raw huggingface dataset:
CVE: CVE-2025-39985
Published: 2025-10-15
Description: In the Linux kernel, the following vulnerability has been resolved:

can: mcba_usb: populate ndo_change_mtu() to prevent buffer overflow

Sending an PF_PACKET allows to bypass the CAN framework logic and to
directly reach the xmit() function of a CAN driver. The only check
which is performed by the PF_PACKET framework is to make sure that
skb->len fits the interface's MTU.

Unfortunately, because the mcba_usb driver does not populate its
net_device_ops->ndo_change_mtu(), it is possible for an attacker to
configure an invalid MTU by doing, for example:

  $ ip link set can0 mtu 9999

After doing so, the attacker could open a PF_PACKET socket using the
ETH_P_CANXL protocol:

	socket(PF_PACKET, SOCK_RAW, htons(ETH_P_CANXL))

to inject a malicious CAN XL frames. For example:

	struct canxl_frame frame = {
		.flags = 0xff,
		.len = 2048,
	};

The CAN drivers' xmit() function are calling can_dev_dropped_skb() to
check that the skb is valid, unfortunately under above conditions, the
malicious packet is able to go through can_dev_dropped_skb() checks:

  1. the skb->protocol is set to ETH_P_CANXL which is valid (the
     function does not check the actual device capabilities).

  2. the length is a valid CAN XL length.

And so, mcba_usb_start_xmit() receives a CAN XL frame which it is not
able to correctly handle and will thus misinterpret it as a CAN frame.

This can result in a buffer overflow. The driver will consume cf->len
as-is with no further checks on these lines:

	usb_msg.dlc = cf->len;

	memcpy(usb_msg.data, cf->data, usb_msg.dlc);

Here, cf->len corresponds to the flags field of the CAN XL frame. In
our previous example, we set canxl_frame->flags to 0xff. Because the
maximum expected length is 8, a buffer overflow of 247 bytes occurs!

Populate net_device_ops->ndo_change_mtu() to ensure that the
interface's MTU can not be set to anything bigger than CAN_MTU. By
fixing the root cause, this prevents the buffer overflow.
References: https://git.kernel.org/stable/c/0fa9303c4b9493727e0d3a6ac3729300e3013930; https://git.kernel.org/stable/c/17c8d794527f01def0d1c8b7dc2d7b8d34fed0e6; https://git.kernel.org/stable/c/3664ae91b26d1fd7e4cee9cde17301361f4c89d5
CVE: CVE-2025-39986
Published: 2025-10-15
Description: In the Linux kernel, the following vulnerability has been resolved:

can: sun4i_can: populate ndo_change_mtu() to prevent buffer overflow

Sending an PF_PACKET allows to bypass the CAN framework logic and to
directly reach the xmit() function of a CAN driver. The only check
which is performed by the PF_PACKET framework is to make sure that
skb->len fits the interface's MTU.

Unfortunately, because the sun4i_can driver does not populate its
net_device_ops->ndo_change_mtu(), it is possible for an attacker to
configure an invalid MTU by doing, for example:

  $ ip link set can0 mtu 9999

After doing so, the attacker could open a PF_PACKET socket using the
ETH_P_CANXL protocol:

	socket(PF_PACKET, SOCK_RAW, htons(ETH_P_CANXL))

to inject a malicious CAN XL frames. For example:

	struct canxl_frame frame = {
		.flags = 0xff,
		.len = 2048,
	};

The CAN drivers' xmit() function are calling can_dev_dropped_skb() to
check that the skb is valid, unfortunately under above conditions, the
malicious packet is able to go through can_dev_dropped_skb() checks:

  1. the skb->protocol is set to ETH_P_CANXL which is valid (the
     function does not check the actual device capabilities).

  2. the length is a valid CAN XL length.

And so, sun4ican_start_xmit() receives a CAN XL frame which it is not
able to correctly handle and will thus misinterpret it as a CAN frame.

This can result in a buffer overflow. The driver will consume cf->len
as-is with no further checks on this line:

	dlc = cf->len;

Here, cf->len corresponds to the flags field of the CAN XL frame. In
our previous example, we set canxl_frame->flags to 0xff. Because the
maximum expected length is 8, a buffer overflow of 247 bytes occurs a
couple line below when doing:

	for (i = 0; i < dlc; i++)
		writel(cf->data[i], priv->base + (dreg + i * 4));

Populate net_device_ops->ndo_change_mtu() to ensure that the
interface's MTU can not be set to anything bigger than CAN_MTU. By
fixing the root cause, this prevents the buffer overflow.
References: https://git.kernel.org/stable/c/063539db42203b29d5aa2adf0cae3d68c646a6b6; https://git.kernel.org/stable/c/2e423e1990f3972cbea779883fef52c2f2acb858; https://git.kernel.org/stable/c/4f382cc887adca8478b9d3e6b81aa6698a95fff4
CVE: CVE-2025-39987
Published: 2025-10-15
Description: In the Linux kernel, the following vulnerability has been resolved:

can: hi311x: populate ndo_change_mtu() to prevent buffer overflow

Sending an PF_PACKET allows to bypass the CAN framework logic and to
directly reach the xmit() function of a CAN driver. The only check
which is performed by the PF_PACKET framework is to make sure that
skb->len fits the interface's MTU.

Unfortunately, because the sun4i_can driver does not populate its
net_device_ops->ndo_change_mtu(), it is possible for an attacker to
configure an invalid MTU by doing, for example:

  $ ip link set can0 mtu 9999

After doing so, the attacker could open a PF_PACKET socket using the
ETH_P_CANXL protocol:

	socket(PF_PACKET, SOCK_RAW, htons(ETH_P_CANXL))

to inject a malicious CAN XL frames. For example:

	struct canxl_frame frame = {
		.flags = 0xff,
		.len = 2048,
	};

The CAN drivers' xmit() function are calling can_dev_dropped_skb() to
check that the skb is valid, unfortunately under above conditions, the
malicious packet is able to go through can_dev_dropped_skb() checks:

  1. the skb->protocol is set to ETH_P_CANXL which is valid (the
     function does not check the actual device capabilities).

  2. the length is a valid CAN XL length.

And so, hi3110_hard_start_xmit() receives a CAN XL frame which it is
not able to correctly handle and will thus misinterpret it as a CAN
frame. The driver will consume frame->len as-is with no further
checks.

This can result in a buffer overflow later on in hi3110_hw_tx() on
this line:

	memcpy(buf + HI3110_FIFO_EXT_DATA_OFF,
	       frame->data, frame->len);

Here, frame->len corresponds to the flags field of the CAN XL frame.
In our previous example, we set canxl_frame->flags to 0xff. Because
the maximum expected length is 8, a buffer overflow of 247 bytes
occurs!

Populate net_device_ops->ndo_change_mtu() to ensure that the
interface's MTU can not be set to anything bigger than CAN_MTU. By
fixing the root cause, this prevents the buffer overflow.
References: https://git.kernel.org/stable/c/57d332ce8c921d0e340650470bb0c1d707f216ee; https://git.kernel.org/stable/c/7ab85762274c0fa997f0ef9a2307b2001aae43c4; https://git.kernel.org/stable/c/8f351db6b2367991f0736b2cff082f5de4872113
CVE: CVE-2025-39988
Published: 2025-10-15
Description: In the Linux kernel, the following vulnerability has been resolved:

can: etas_es58x: populate ndo_change_mtu() to prevent buffer overflow

Sending an PF_PACKET allows to bypass the CAN framework logic and to
directly reach the xmit() function of a CAN driver. The only check
which is performed by the PF_PACKET framework is to make sure that
skb->len fits the interface's MTU.

Unfortunately, because the etas_es58x driver does not populate its
net_device_ops->ndo_change_mtu(), it is possible for an attacker to
configure an invalid MTU by doing, for example:

  $ ip link set can0 mtu 9999

After doing so, the attacker could open a PF_PACKET socket using the
ETH_P_CANXL protocol:

	socket(PF_PACKET, SOCK_RAW, htons(ETH_P_CANXL));

to inject a malicious CAN XL frames. For example:

	struct canxl_frame frame = {
		.flags = 0xff,
		.len = 2048,
	};

The CAN drivers' xmit() function are calling can_dev_dropped_skb() to
check that the skb is valid, unfortunately under above conditions, the
malicious packet is able to go through can_dev_dropped_skb() checks:

  1. the skb->protocol is set to ETH_P_CANXL which is valid (the
     function does not check the actual device capabilities).

  2. the length is a valid CAN XL length.

And so, es58x_start_xmit() receives a CAN XL frame which it is not
able to correctly handle and will thus misinterpret it as a CAN(FD)
frame.

This can result in a buffer overflow. For example, using the es581.4
variant, the frame will be dispatched to es581_4_tx_can_msg(), go
through the last check at the beginning of this function:

	if (can_is_canfd_skb(skb))
		return -EMSGSIZE;

and reach this line:

	memcpy(tx_can_msg->data, cf->data, cf->len);

Here, cf->len corresponds to the flags field of the CAN XL frame. In
our previous example, we set canxl_frame->flags to 0xff. Because the
maximum expected length is 8, a buffer overflow of 247 bytes occurs!

Populate net_device_ops->ndo_change_mtu() to ensure that the
interface's MTU can not be set to anything bigger than CAN_MTU or
CANFD_MTU (depending on the device capabilities). By fixing the root
cause, this prevents the buffer overflow.
References: https://git.kernel.org/stable/c/38c0abad45b190a30d8284a37264d2127a6ec303; https://git.kernel.org/stable/c/72de0facc50afdb101fb7197d880407f1abfc77f; https://git.kernel.org/stable/c/b26cccd87dcddc47b450a40f3b1ac3fe346efcff
CVE: CVE-2025-39990
Published: 2025-10-15
Description: In the Linux kernel, the following vulnerability has been resolved:

bpf: Check the helper function is valid in get_helper_proto

kernel test robot reported verifier bug [1] where the helper func
pointer could be NULL due to disabled config option.

As Alexei suggested we could check on that in get_helper_proto
directly. Marking tail_call helper func with BPF_PTR_POISON,
because it is unused by design.

  [1] https://lore.kernel.org/oe-lkp/[PII_REDACTED]18.68358831-lkp@intel.com
References: https://git.kernel.org/stable/c/3d429cb1278e995e22995ef117fa96d223a67e93; https://git.kernel.org/stable/c/6233715b4b714068d6c831d214a4e[PII_REDACTED]a; https://git.kernel.org/stable/c/e4414b01c1cd9887bbde92f946c1ba94e40d6d64
CVE: CVE-2025-39991
Published: 2025-10-15
Description: In the Linux kernel, the following vulnerability has been resolved:

wifi: ath11k: fix NULL dereference in ath11k_qmi_m3_load()

If ab->fw.m3_data points to data, then fw pointer remains null.
Further, if m3_mem is not allocated, then fw is dereferenced to be
passed to ath11k_err function.

Replace fw->size by m3_len.

Found by Linux Verification Center (linuxtesting.org) with SVACE.
References: https://git.kernel.org/stable/c/1f52119809b76d43759fc47da1cf708690b740a1; https://git.kernel.org/stable/c/3fd2ef2ae2b5c955584a3bee8e83ae7d7a98f782; https://git.kernel.org/stable/c/500fcc31e488d798937a23dbb1f62db46820c5b2
CVE: CVE-2025-39992
Published: 2025-10-15
Description: In the Linux kernel, the following vulnerability has been resolved:

mm: swap: check for stable address space before operating on the VMA

It is possible to hit a zero entry while traversing the vmas in unuse_mm()
called from swapoff path and accessing it causes the OOPS:

Unable to handle kernel NULL pointer dereference at virtual address
[PII_REDACTED]--> Loading the memory from offset 0x40 on the
XA_ZERO_ENTRY as address.
Mem abort info:
  ESR = 0x[PII_REDACTED]000005
  EC = 0x25: DABT (current EL), IL = 32 bits
  SET = 0, FnV = 0
  EA = 0, S1PTW = 0
  FSC = 0x05: level 1 translation fault

The issue is manifested from the below race between the fork() on a
process and swapoff:
fork(dup_mmap())			swapoff(unuse_mm)
---------------                         -----------------
1) Identical mtree is built using
   __mt_dup().

2) copy_pte_range()-->
	copy_nonpresent_pte():
       The dst mm is added into the
    mmlist to be visible to the
    swapoff operation.

3) Fatal signal is sent to the parent
process(which is the current during the
fork) thus skip the duplication of the
vmas and mark the vma range with
XA_ZERO_ENTRY as a marker for this process
that helps during exit_mmap().

				     4) swapoff is tried on the
					'mm' added to the 'mmlist' as
					part of the 2.

				     5) unuse_mm(), that iterates
					through the vma's of this 'mm'
					will hit the non-NULL zero entry
					and operating on this zero entry
					as a vma is resulting into the
					oops.

The proper fix would be around not exposing this partially-valid tree to
others when droping the mmap lock, which is being solved with [1].  A
simpler solution would be checking for MMF_UNSTABLE, as it is set if
mm_struct is not fully initialized in dup_mmap().

Thanks to Liam/Lorenzo/David for all the suggestions in fixing this
issue.
References: https://git.kernel.org/stable/c/1367da7eb875d01102d2ed18654b24d261ff5393; https://git.kernel.org/stable/c/4e5f060d7347466f77aaff1c0d5a6c4f1fb217ac; https://git.kernel.org/stable/c/9cddad3b26dac830407d2d3c0de5205ff6d6dda0
CVE: CVE-2025-39993
Published: 2025-10-15
Description: In the Linux kernel, the following vulnerability has been resolved:

media: rc: fix races with imon_disconnect()

Syzbot reports a KASAN issue as below:
BUG: KASAN: use-after-free in __create_pipe include/linux/usb.h:1945 [inline]
BUG: KASAN: use-after-free in send_packet+0xa2d/0xbc0 drivers/media/rc/imon.c:627
Read of size 4 at addr ffff8880256fb000 by task syz-executor314/4465

CPU: 2 PID: 4465 Comm: syz-executor314 Not tainted 6.0.0-rc1-syzkaller #0
Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.14.0-2 04/01/2014
Call Trace:
 <TASK>
__dump_stack lib/dump_stack.c:88 [inline]
dump_stack_lvl+0xcd/0x134 lib/dump_stack.c:106
print_address_description mm/kasan/report.c:317 [inline]
print_report.cold+0x2ba/0x6e9 mm/kasan/report.c:433
kasan_report+0xb1/0x1e0 mm/kasan/report.c:495
__create_pipe include/linux/usb.h:1945 [inline]
send_packet+0xa2d/0xbc0 drivers/media/rc/imon.c:627
vfd_write+0x2d9/0x550 drivers/media/rc/imon.c:991
vfs_write+0x2d7/0xdd0 fs/read_write.c:576
ksys_write+0x127/0x250 fs/read_write.c:631
do_syscall_x64 arch/x86/entry/common.c:50 [inline]
do_syscall_64+0x35/0xb0 arch/x86/entry/common.c:80
entry_SYSCALL_64_after_hwframe+0x63/0xcd

The iMON driver improperly releases the usb_device reference in
imon_disconnect without coordinating with active users of the
device.

Specifically, the fields usbdev_intf0 and usbdev_intf1 are not
protected by the users counter (ictx->users). During probe,
imon_init_intf0 or imon_init_intf1 increments the usb_device
reference count depending on the interface. However, during
disconnect, usb_put_dev is called unconditionally, regardless of
actual usage.

As a result, if vfd_write or other operations are still in
progress after disconnect, this can lead to a use-after-free of
the usb_device pointer.

Thread 1 vfd_write                      Thread 2 imon_disconnect
                                        ...
                                        if
                                          usb_put_dev(ictx->usbdev_intf0)
                                        else
                                          usb_put_dev(ictx->usbdev_intf1)
...
while
  send_packet
    if
      pipe = usb_sndintpipe(
        ictx->usbdev_intf0) UAF
    else
      pipe = usb_sndctrlpipe(
        ictx->usbdev_intf0, 0) UAF

Guard access to usbdev_intf0 and usbdev_intf1 after disconnect by
checking ictx->disconnected in all writer paths. Add early return
with -ENODEV in send_packet(), vfd_write(), lcd_write() and
display_open() if the device is no longer present.

Set and read ictx->disconnected under ictx->lock to ensure memory
synchronization. Acquire the lock in imon_disconnect() before setting
the flag to synchronize with any ongoing operations.

Ensure writers exit early and safely after disconnect before the USB
core proceeds with cleanup.

Found by Linux Verification Center (linuxtesting.org) with Syzkaller.
References: https://git.kernel.org/stable/c/2e7fd93b9cc565b839bc55a[PII_REDACTED]963e156; https://git.kernel.org/stable/c/71096a6161a25e84acddb89a9d77f138502d26ab; https://git.kernel.org/stable/c/71c52b073922d05e79e6de7fc7f5f38f927929a4
CVE: CVE-2025-39994
Published: 2025-10-15
Description: In the Linux kernel, the following vulnerability has been resolved:

media: tuner: xc5000: Fix use-after-free in xc5000_release

The original code uses cancel_delayed_work() in xc5000_release(), which
does not guarantee that the delayed work item timer_sleep has fully
completed if it was already running. This leads to use-after-free scenarios
where xc5000_release() may free the xc5000_priv while timer_sleep is still
active and attempts to dereference the xc5000_priv.

A typical race condition is illustrated below:

CPU 0 (release thread)                 | CPU 1 (delayed work callback)
xc5000_release()                       | xc5000_do_timer_sleep()
  cancel_delayed_work()                |
  hybrid_tuner_release_state(priv)     |
    kfree(priv)                        |
                                       |   priv = container_of() // UAF

Replace cancel_delayed_work() with cancel_delayed_work_sync() to ensure
that the timer_sleep is properly canceled before the xc5000_priv memory
is deallocated.

A deadlock concern was considered: xc5000_release() is called in a process
context and is not holding any locks that the timer_sleep work item might
also need. Therefore, the use of the _sync() variant is safe here.

This bug was initially identified through static analysis.

[hverkuil: fix typo in Subject: tunner -> tuner]
References: https://git.kernel.org/stable/c/3f876cd47ed8bca1e28d[PII_REDACTED]9f51f90703; https://git.kernel.org/stable/c/40b7a19f321e65789612ebaca966472055dab48c; https://git.kernel.org/stable/c/4266f012806fc18e46da4a04d130df59a4946f93
CVE: CVE-2025-39997
Published: 2025-10-15
Description: In the Linux kernel, the following vulnerability has been resolved:

ALSA: usb-audio: fix race condition to UAF in snd_usbmidi_free

The previous commit 0718a78f6a9f ("ALSA: usb-audio: Kill timer properly at
removal") patched a UAF issue caused by the error timer.

However, because the error timer kill added in this patch occurs after the
endpoint delete, a race condition to UAF still occurs, albeit rarely.

Additionally, since kill-cleanup for urb is also missing, freed memory can
be accessed in interrupt context related to urb, which can cause UAF.

Therefore, to prevent this, error timer and urb must be killed before
freeing the heap memory.
References: https://git.kernel.org/stable/c/353d8c715cc951a980728133c9dd64ca5a0a186c; https://git.kernel.org/stable/c/647d6b8d22be12842fde6ed0c56859ebc615f21e; https://git.kernel.org/stable/c/9f2c0ac1423d5f267e7f1d1940780fc764b0fee3
CVE: CVE-2025-39998
Published: 2025-10-15
Description: In the Linux kernel, the following vulnerability has been resolved:

scsi: target: target_core_configfs: Add length check to avoid buffer overflow

A buffer overflow arises from the usage of snprintf to write into the
buffer "buf" in target_lu_gp_members_show function located in
/drivers/target/target_core_configfs.c. This buffer is allocated with
size LU_GROUP_NAME_BUF (256 bytes).

snprintf(...) formats multiple strings into buf with the HBA name
(hba->hba_group.cg_item), a slash character, a devicename (dev->
dev_group.cg_item) and a newline character, the total formatted string
length may exceed the buffer size of 256 bytes.

Since snprintf() returns the total number of bytes that would have been
written (the length of %s/%sn ), this value may exceed the buffer length
(256 bytes) passed to memcpy(), this will ultimately cause function
memcpy reporting a buffer overflow error.

An additional check of the return value of snprintf() can avoid this
buffer overflow.
References: https://git.kernel.org/stable/c/27e06650a5eafe832a90fd2604f0c5e920857fae; https://git.kernel.org/stable/c/4b[PII_REDACTED]88bd2818e66ff102db278de8dd26; https://git.kernel.org/stable/c/53c6351597e6a17ec6619f6f060d54128cb9a187
CVE: CVE-2025-39999
Published: 2025-10-15
Description: In the Linux kernel, the following vulnerability has been resolved:

blk-mq: fix blk_mq_tags double free while nr_requests grown

In the case user trigger tags grow by queue sysfs attribute nr_requests,
hctx->sched_tags will be freed directly and replaced with a new
allocated tags, see blk_mq_tag_update_depth().

The problem is that hctx->sched_tags is from elevator->et->tags, while
et->tags is still the freed tags, hence later elevator exit will try to
free the tags again, causing kernel panic.

Fix this problem by replacing et->tags with new allocated tags as well.

Noted there are still some long term problems that will require some
refactor to be fixed thoroughly[1].

[1] https://lore.kernel.org/all/[PII_REDACTED]0216.410665-1-yukuai1@huaweicloud.com/
References: https://git.kernel.org/stable/c/392b1d64911f4de8887fe8b68299fa8bd6e5b923; https://git.kernel.org/stable/c/8faee580d63bc2a54a59dcdb7f9ce4de29384fec; https://git.kernel.org/stable/c/ba28afbd9eff2a6370f23ef4e6a036ab0cfda409
CVE: CVE-2025-55039
Published: 2025-10-15
Description: This issue affects Apache Spark versions before  3.4.4, 3.5.2 and 4.0.0.



Apache Spark versions before 4.0.0, 3.5.2 and 3.4.4 use an insecure default network encryption cipher for RPC communication between nodes.

When spark.network.crypto.enabled is set to true (it is set to false by default), but spark.network.crypto.cipher is not explicitly configured, Spark defaults to AES in CTR mode (AES/CTR/NoPadding), which provides encryption without authentication.

This vulnerability allows a man-in-the-middle attacker to modify encrypted RPC traffic undetected by flipping bits in ciphertext, potentially compromising heartbeat messages or application data and affecting the integrity of Spark workflows.


To mitigate this issue, users should either configure spark.network.crypto.cipher to AES/GCM/NoPadding to enable authenticated encryption or

enable SSL encryption by setting spark.ssl.enabled to true, which provides stronger transport security.
CVSS Score: 6.5 (MEDIUM)
CWE: CWE-326, CWE-347
References: https://lists.apache.org/thread/zrgyy9l85nm2c7vk36vr7bkyorg3w4qq; http://www.openwall.com/lists/oss-security/2025/10/14/11
CVE: CVE-2025-61941
Published: 2025-10-15
Description: A path traversal issue exists in WXR9300BE6P series firmware versions prior to Ver.1.10. Arbitrary file may be altered by an administrative user who logs in to the affected product. Moreover, arbitrary OS command may be executed via some file alteration.
CVSS Score: 7.2 (HIGH)
CWE: CWE-22
References: https://jvn.jp/en/vu/JVNVU96471278/; https://www.buffalo.jp/news/detail/20251014-01.html
CVE: CVE-2025-10038
Published: 2025-10-15
Description: The Binary MLM Plan plugin for WordPress is vulnerable to limited Privilege Escalation in all versions up to, and including, 3.0. This is due to bmp_user role granting all users with the manage_bmp capability by default upon registration through the plugin's form. This makes it possible for unauthenticated attackers to register and manage the plugin's settings.
CVSS Score: 6.5 (MEDIUM)
CWE: CWE-266
References: https://plugins.trac.wordpress.org/changeset/3380455/binary-mlm-plan/tags/5.0/includes/admin/class-bmp-admin-menus.php?old=3259986&old_path=binary-mlm-plan%2Ftags%2F3.0%2Fincludes%2Fadmin%2Fclass-bmp-admin-menus.php; https://plugins.trac.wordpress.org/changeset/3380455/binary-mlm-plan/tags/5.0/includes/bmp-hook-functions.php?old=3259986&old_path=binary-mlm-plan%2Ftags%2F3.0%2Fincludes%2Fbmp-hook-functions.php; https://wordpress.org/plugins/binary-mlm-plan/
CVE: CVE-2025-10041
Published: 2025-10-15
Description: The Flex QR Code Generator plugin for WordPress is vulnerable to arbitrary file uploads due to missing file type validation in thesave_qr_code_to_db() function in all versions up to, and including, 1.2.5. This makes it possible for unauthenticated attackers to upload arbitrary files on the affected site's server which may make remote code execution possible.
CVSS Score: 9.8 (CRITICAL)
CWE: CWE-434
References: https://plugins.trac.wordpress.org/browser/flex-qr-code-generator/tags/1.2.5/qr-code-generator.php#L208; https://plugins.trac.wordpress.org/changeset?sfp_email=&sfph_mail=&reponame=&old=3379026%40flex-qr-code-generator&new=3379026%40flex-qr-code-generator&sfp_email=&sfph_mail=; https://wordpress.org/plugins/flex-qr-code-generator/