deardaniel/secdata-raw huggingface dataset:
CVE: CVE-2025-37788
Published: 2025-05-01
Description: In the Linux kernel, the following vulnerability has been resolved:

cxgb4: fix memory leak in cxgb4_init_ethtool_filters() error path

In the for loop used to allocate the loc_array and bmap for each port, a
memory leak is possible when the allocation for loc_array succeeds,
but the allocation for bmap fails. This is because when the control flow
goes to the label free_eth_finfo, only the allocations starting from
(i-1)th iteration are freed.

Fix that by freeing the loc_array in the bmap allocation error path.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-401
References: https://git.kernel.org/stable/c/00ffb3724ce743578163f5ade[PII_REDACTED]ca021; https://git.kernel.org/stable/c/08aa59c0be[PII_REDACTED]52c129e9f82166779a67; https://git.kernel.org/stable/c/118d05b530343cd9322607b9719405ba254a4183
CVE: CVE-2025-37789
Published: 2025-05-01
Description: In the Linux kernel, the following vulnerability has been resolved:

net: openvswitch: fix nested key length validation in the set() action

It's not safe to access nla_len(ovs_key) if the data is smaller than
the netlink header.  Check that the attribute is OK first.
CVSS Score: 7.8 (HIGH)
References: https://git.kernel.org/stable/c/03d7262dd53e8c404da35cc81aaa887fd901f76b; https://git.kernel.org/stable/c/1489c195c8eecd262aa6712761ba5288203e28ec; https://git.kernel.org/stable/c/54c6957d1123a2032099b9eab51c314800f677ce
CVE: CVE-2025-37790
Published: 2025-05-01
Description: In the Linux kernel, the following vulnerability has been resolved:

net: mctp: Set SOCK_RCU_FREE

Bind lookup runs under RCU, so ensure that a socket doesn't go away in
the middle of a lookup.
CVSS Score: 5.5 (MEDIUM)
References: https://git.kernel.org/stable/c/3f899bd6dd56ddc46509b526e23a8f0a97712a6d; https://git.kernel.org/stable/c/52024cd6ec71a6ca934d0cc12452bd8d49850679; https://git.kernel.org/stable/c/5c1313b93c8c2e3904a48aa88e2fa1db28c607ae
CVE: CVE-2025-37791
Published: 2025-05-01
Description: In the Linux kernel, the following vulnerability has been resolved:

ethtool: cmis_cdb: use correct rpl size in ethtool_cmis_module_poll()

rpl is passed as a pointer to ethtool_cmis_module_poll(), so the correct
size of rpl is sizeof(*rpl) which should be just 1 byte.  Using the
pointer size instead can cause stack corruption:

Kernel panic - not syncing: stack-protector: Kernel stack is corrupted in: ethtool_cmis_wait_for_cond+0xf4/0x100
CPU: 72 UID: 0 PID: 4440 Comm: kworker/72:2 Kdump: loaded Tainted: G           OE      6.11.0 #24
Tainted: [O]=OOT_MODULE, [E]=UNSIGNED_MODULE
Hardware name: Dell Inc. PowerEdge R760/04GWWM, BIOS 1.6.6 09/20/2023
Workqueue: events module_flash_fw_work
Call Trace:
 <TASK>
 panic+0x339/0x360
 ? ethtool_cmis_wait_for_cond+0xf4/0x100
 ? __pfx_status_success+0x10/0x10
 ? __pfx_status_fail+0x10/0x10
 __stack_chk_fail+0x10/0x10
 ethtool_cmis_wait_for_cond+0xf4/0x100
 ethtool_cmis_cdb_execute_cmd+0x1fc/0x330
 ? __pfx_status_fail+0x10/0x10
 cmis_cdb_module_features_get+0x6d/0xd0
 ethtool_cmis_cdb_init+0x8a/0xd0
 ethtool_cmis_fw_update+0x46/0x1d0
 module_flash_fw_work+0x17/0xa0
 process_one_work+0x179/0x390
 worker_thread+0x239/0x340
 ? __pfx_worker_thread+0x10/0x10
 kthread+0xcc/0x100
 ? __pfx_kthread+0x10/0x10
 ret_from_fork+0x2d/0x50
 ? __pfx_kthread+0x10/0x10
 ret_from_fork_asm+0x1a/0x30
 </TASK>
CVSS Score: 5.5 (MEDIUM)
References: https://git.kernel.org/stable/c/61765e1b417a23371c3735e3cddf4ad9354ed2e9; https://git.kernel.org/stable/c/7eb0a0072f966bb0b01d8b7d529d9743a7187bd1; https://git.kernel.org/stable/c/f3fdd4fba16c74697d8bc730b82fb7c1eff7fab3
CVE: CVE-2025-37792
Published: 2025-05-01
Description: In the Linux kernel, the following vulnerability has been resolved:

Bluetooth: btrtl: Prevent potential NULL dereference

The btrtl_initialize() function checks that rtl_load_file() either
had an error or it loaded a zero length file.  However, if it loaded
a zero length file then the error code is not set correctly.  It
results in an error pointer vs NULL bug, followed by a NULL pointer
dereference.  This was detected by Smatch:

drivers/bluetooth/btrtl.c:592 btrtl_initialize() warn: passing zero to 'ERR_PTR'
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-476
References: https://git.kernel.org/stable/c/2d7c60c2a38b4b461fa960ad0995136a6bfe0756; https://git.kernel.org/stable/c/324dddea321078a6eeb535c2bff5257be74c9799; https://git.kernel.org/stable/c/3db6605043b50c8bb768547b23e0222f67ceef3e
CVE: CVE-2025-37793
Published: 2025-05-01
Description: In the Linux kernel, the following vulnerability has been resolved:

ASoC: Intel: avs: Fix null-ptr-deref in avs_component_probe()

devm_kasprintf() returns NULL when memory allocation fails. Currently,
avs_component_probe() does not check for this case, which results in a
NULL pointer dereference.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-476
References: https://git.kernel.org/stable/c/23fde311ea1d0a6c36bf92ce48b90b77d0ece1a4; https://git.kernel.org/stable/c/95f723cf141b95e3b3a5b92cf2ea98a863fe7275; https://git.kernel.org/stable/c/aaa93b[PII_REDACTED]de815759d39979661b82d5a5
CVE: CVE-2025-37795
Published: 2025-05-01
Description: Rejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.
CVE: CVE-2025-37796
Published: 2025-05-01
Description: In the Linux kernel, the following vulnerability has been resolved:

wifi: at76c50x: fix use after free access in at76_disconnect

The memory pointed to by priv is freed at the end of at76_delete_device
function (using ieee80211_free_hw). But the code then accesses the udev
field of the freed object to put the USB device. This may also lead to a
memory leak of the usb device. Fix this by using udev from interface.
CVSS Score: 7.8 (HIGH)
CWE: CWE-416
References: https://git.kernel.org/stable/c/152721cbae42713ecfbca6847e0f102ee6b19546; https://git.kernel.org/stable/c/27c7e63b3cb1a20bb78ed4a36c561ea4579fd7da; https://git.kernel.org/stable/c/3c619aec1f538333b56746d2f796aab1bca5c9a5
CVE: CVE-2025-44835
Published: 2025-05-01
Description: D-Link DIR-816 A2V1.1.0B05 was found to contain a command injection in iptablesWebsFilterRun, which allows remote attackers to execute arbitrary commands via shell.
CVSS Score: 6.3 (MEDIUM)
CWE: CWE-77
References: https://github.com/n0wstr/IOTVuln/tree/main/DIR-816/IptablesWebsFilterRun
CVE: CVE-2025-44854
Published: 2025-05-01
Description: TOTOLINK CP900 V6.3c.1144_B20190715 was found to contain a command injection vulnerability in the setUpgradeUboot function via the FileName parameter. This vulnerability allows attackers to execute arbitrary commands via a crafted request.
CVSS Score: 6.3 (MEDIUM)
CWE: CWE-77
References: https://github.com/Summermu/VulnForIoT/tree/main/Totolink_CP900/setUpgradeUboot/readme.md
CVE: CVE-2020-36790
Published: 2025-05-01
Description: In the Linux kernel, the following vulnerability has been resolved:

nvmet: fix a memory leak

We forgot to free new_model_number
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-401
References: https://git.kernel.org/stable/c/227064b2ca9e62270ed445665ae849c73f0dfb2c; https://git.kernel.org/stable/c/382fee1a8b623e2546a3e15e80517389e0e0673e
CVE: CVE-2022-49762
Published: 2025-05-01
Description: In the Linux kernel, the following vulnerability has been resolved:

ntfs: check overflow when iterating ATTR_RECORDs

Kernel iterates over ATTR_RECORDs in mft record in ntfs_attr_find(). 
Because the ATTR_RECORDs are next to each other, kernel can get the next
ATTR_RECORD from end address of current ATTR_RECORD, through current
ATTR_RECORD length field.

The problem is that during iteration, when kernel calculates the end
address of current ATTR_RECORD, kernel may trigger an integer overflow bug
in executing `a = (ATTR_RECORD*)((u8*)a + le32_to_cpu(a->length))`.  This
may wrap, leading to a forever iteration on 32bit systems.

This patch solves it by adding some checks on calculating end address
of current ATTR_RECORD during iteration.
CVSS Score: 5.5 (MEDIUM)
References: https://git.kernel.org/stable/c/45683723f6b53e39e8a4cec0894e61fd6ec71989; https://git.kernel.org/stable/c/5559eb5809353a83a40a1e4e7f066431c7b83020; https://git.kernel.org/stable/c/63095f4f3af59322bea984a6ae[PII_REDACTED]8fe0
CVE: CVE-2022-49764
Published: 2025-05-01
Description: In the Linux kernel, the following vulnerability has been resolved:

bpf: Prevent bpf program recursion for raw tracepoint probes

We got report from sysbot [1] about warnings that were caused by
bpf program attached to contention_begin raw tracepoint triggering
the same tracepoint by using bpf_trace_printk helper that takes
trace_printk_lock lock.

 Call Trace:
  <TASK>
  ? trace_event_raw_event_bpf_trace_printk+0x5f/0x90
  bpf_trace_printk+0x2b/0xe0
  bpf_prog_a9aec6167c091eef_prog+0x1f/0x24
  bpf_trace_run2+0x26/0x90
  native_queued_spin_lock_slowpath+0x1c6/0x2b0
  _raw_spin_lock_irqsave+0x44/0x50
  bpf_trace_printk+0x3f/0xe0
  bpf_prog_a9aec6167c091eef_prog+0x1f/0x24
  bpf_trace_run2+0x26/0x90
  native_queued_spin_lock_slowpath+0x1c6/0x2b0
  _raw_spin_lock_irqsave+0x44/0x50
  bpf_trace_printk+0x3f/0xe0
  bpf_prog_a9aec6167c091eef_prog+0x1f/0x24
  bpf_trace_run2+0x26/0x90
  native_queued_spin_lock_slowpath+0x1c6/0x2b0
  _raw_spin_lock_irqsave+0x44/0x50
  bpf_trace_printk+0x3f/0xe0
  bpf_prog_a9aec6167c091eef_prog+0x1f/0x24
  bpf_trace_run2+0x26/0x90
  native_queued_spin_lock_slowpath+0x1c6/0x2b0
  _raw_spin_lock_irqsave+0x44/0x50
  __unfreeze_partials+0x5b/0x160
  ...

The can be reproduced by attaching bpf program as raw tracepoint on
contention_begin tracepoint. The bpf prog calls bpf_trace_printk
helper. Then by running perf bench the spin lock code is forced to
take slow path and call contention_begin tracepoint.

Fixing this by skipping execution of the bpf program if it's
already running, Using bpf prog 'active' field, which is being
currently used by trampoline programs for the same reason.

Moving bpf_prog_inc_misses_counter to syscall.c because
trampoline.c is compiled in just for CONFIG_BPF_JIT option.

[1] https://lore.kernel.org/bpf/YxhFe3EwqchC%2FfYf@krava/T/#t
CVSS Score: 5.5 (MEDIUM)
References: https://git.kernel.org/stable/c/05b24ff9b2cfabfcfd951daaa915a036ab53c9e1; https://git.kernel.org/stable/c/2e[PII_REDACTED]fedd6cdc41f73fbf9bbe7208f899
CVE: CVE-2022-49765
Published: 2025-05-01
Description: In the Linux kernel, the following vulnerability has been resolved:

net/9p: use a dedicated spinlock for trans_fd

Shamelessly copying the explanation from Tetsuo Handa's suggested
patch[1] (slightly reworded):
syzbot is reporting inconsistent lock state in p9_req_put()[2],
for p9_tag_remove() from p9_req_put() from IRQ context is using
spin_lock_irqsave() on "struct p9_client"->lock but trans_fd
(not from IRQ context) is using spin_lock().

Since the locks actually protect different things in client.c and in
trans_fd.c, just replace trans_fd.c's lock by a new one specific to the
transport (client.c's protect the idr for fid/tag allocations,
while trans_fd.c's protects its own req list and request status field
that acts as the transport's state machine)
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-667
References: https://git.kernel.org/stable/c/296ab4a813841ba1d5f40b03190fd1bd8f25aab0; https://git.kernel.org/stable/c/43bbadb7e4636dc02f6a283c2a39e6438e6173cd; https://git.kernel.org/stable/c/717b9b4f38703d7f5293059e3a242d16f76fa045
CVE: CVE-2022-49766
Published: 2025-05-01
Description: In the Linux kernel, the following vulnerability has been resolved:

netlink: Bounds-check struct nlmsgerr creation

In preparation for FORTIFY_SOURCE doing bounds-check on memcpy(),
switch from __nlmsg_put to nlmsg_put(), and explain the bounds check
for dealing with the memcpy() across a composite flexible array struct.
Avoids this future run-time warning:

  memcpy: detected field-spanning write (size 32) of single field "&errmsg->msg" at net/netlink/af_netlink.c:2447 (size 16)
CVSS Score: 5.5 (MEDIUM)
References: https://git.kernel.org/stable/c/710d21fdff9a98d621cd4e64167f3ef8af4e2fd1; https://git.kernel.org/stable/c/aff4eb16f589c3af322a2582044bca365381fcd6
CVE: CVE-2022-49767
Published: 2025-05-01
Description: In the Linux kernel, the following vulnerability has been resolved:

9p/trans_fd: always use O_NONBLOCK read/write

syzbot is reporting hung task at p9_fd_close() [1], for p9_mux_poll_stop()
 from p9_conn_destroy() from p9_fd_close() is failing to interrupt already
started kernel_read() from p9_fd_read() from p9_read_work() and/or
kernel_write() from p9_fd_write() from p9_write_work() requests.

Since p9_socket_open() sets O_NONBLOCK flag, p9_mux_poll_stop() does not
need to interrupt kernel_read()/kernel_write(). However, since p9_fd_open()
does not set O_NONBLOCK flag, but pipe blocks unless signal is pending,
p9_mux_poll_stop() needs to interrupt kernel_read()/kernel_write() when
the file descriptor refers to a pipe. In other words, pipe file descriptor
needs to be handled as if socket file descriptor.

We somehow need to interrupt kernel_read()/kernel_write() on pipes.

A minimal change, which this patch is doing, is to set O_NONBLOCK flag
 from p9_fd_open(), for O_NONBLOCK flag does not affect reading/writing
of regular files. But this approach changes O_NONBLOCK flag on userspace-
supplied file descriptors (which might break userspace programs), and
O_NONBLOCK flag could be changed by userspace. It would be possible to set
O_NONBLOCK flag every time p9_fd_read()/p9_fd_write() is invoked, but still
remains small race window for clearing O_NONBLOCK flag.

If we don't want to manipulate O_NONBLOCK flag, we might be able to
surround kernel_read()/kernel_write() with set_thread_flag(TIF_SIGPENDING)
and recalc_sigpending(). Since p9_read_work()/p9_write_work() works are
processed by kernel threads which process global system_wq workqueue,
signals could not be delivered from remote threads when p9_mux_poll_stop()
 from p9_conn_destroy() from p9_fd_close() is called. Therefore, calling
set_thread_flag(TIF_SIGPENDING)/recalc_sigpending() every time would be
needed if we count on signals for making kernel_read()/kernel_write()
non-blocking.

[Dominique: add comment at Christian's suggestion]
CVSS Score: 5.5 (MEDIUM)
References: https://git.kernel.org/stable/c/0b5e6bd72b[PII_REDACTED]841603a70e4ba9837063; https://git.kernel.org/stable/c/0e07032b4b4724b8ad1003698cb81083c1818999; https://git.kernel.org/stable/c/5af16182c[PII_REDACTED]118e9e9aecd8355f7a08b
CVE: CVE-2022-49768
Published: 2025-05-01
Description: In the Linux kernel, the following vulnerability has been resolved:

9p: trans_fd/p9_conn_cancel: drop client lock earlier

syzbot reported a double-lock here and we no longer need this
lock after requests have been moved off to local list:
just drop the lock earlier.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-667
References: https://git.kernel.org/stable/c/52f1c45dde9136f964d63a77d19826c8a74e2c7f; https://git.kernel.org/stable/c/612c977f5d481f551d03d83d0aef588845c1300c; https://git.kernel.org/stable/c/82825dbf393f7c7979d462f9609a15bde8092b3f
CVE: CVE-2022-49769
Published: 2025-05-01
Description: In the Linux kernel, the following vulnerability has been resolved:

gfs2: Check sb_bsize_shift after reading superblock

Fuzzers like to scribble over sb_bsize_shift but in reality it's very
unlikely that this field would be corrupted on its own. Nevertheless it
should be checked to avoid the possibility of messy mount errors due to
bad calculations. It's always a fixed value based on the block size so
we can just check that it's the expected value.

Tested with:

    mkfs.gfs2 -O -p lock_nolock /dev/vdb
    for i in 0 -1 64 65 32 33; do
        gfs2_edit -p sb field sb_bsize_shift $i /dev/vdb
        mount /dev/vdb /mnt/test && umount /mnt/test
    done

Before this patch we get a withdraw after

[   76.413681] gfs2: fsid=loop0.0: fatal: invalid metadata block
[   76.413681]   bh = 19 (type: exp=5, found=4)
[   76.413681]   function = gfs2_meta_buffer, file = fs/gfs2/meta_io.c, line = 492

and with UBSAN configured we also get complaints like

[   76.373395] UBSAN: shift-out-of-bounds in fs/gfs2/ops_fstype.c:295:19
[   76.373815] shift exponent[PII_REDACTED] is too large for 64-bit type 'long unsigned int'

After the patch, these complaints don't appear, mount fails immediately
and we get an explanation in dmesg.
CVSS Score: 5.5 (MEDIUM)
References: https://git.kernel.org/stable/c/15c83fa0fd659dd9fbdc940a560b61236e876a80; https://git.kernel.org/stable/c/16670534c7cff1acd918a6a5ec751b14e7436b76; https://git.kernel.org/stable/c/1ad[PII_REDACTED]8066a8ffaa27ee7d0ae6d9f476
CVE: CVE-2022-49770
Published: 2025-05-01
Description: In the Linux kernel, the following vulnerability has been resolved:

ceph: avoid putting the realm twice when decoding snaps fails

When decoding the snaps fails it maybe leaving the 'first_realm'
and 'realm' pointing to the same snaprealm memory. And then it'll
put it twice and could cause random use-after-free, BUG_ON, etc
issues.
CVSS Score: 7.8 (HIGH)
CWE: CWE-416
References: https://git.kernel.org/stable/c/044bc6d3c2c0e9090b0841e7b[PII_REDACTED]34b45; https://git.kernel.org/stable/c/274e4c79a3a2a24fba7cfe0e41113f1138785c37; https://git.kernel.org/stable/c/2f6e2de3a[PII_REDACTED]118b61f138fe7c28e1905
CVE: CVE-2022-49771
Published: 2025-05-01
Description: In the Linux kernel, the following vulnerability has been resolved:

dm ioctl: fix misbehavior if list_versions races with module loading

__list_versions will first estimate the required space using the
"dm_target_iterate(list_version_get_needed, &needed)" call and then will
fill the space using the "dm_target_iterate(list_version_get_info,
&iter_info)" call. Each of these calls locks the targets using the
"down_read(&_lock)" and "up_read(&_lock)" calls, however between the first
and second "dm_target_iterate" there is no lock held and the target
modules can be loaded at this point, so the second "dm_target_iterate"
call may need more space than what was the first "dm_target_iterate"
returned.

The code tries to handle this overflow (see the beginning of
list_version_get_info), however this handling is incorrect.

The code sets "param->data_size = param->data_start + needed" and
"iter_info.end = (char *)vers+len" - "needed" is the size returned by the
first dm_target_iterate call; "len" is the size of the buffer allocated by
userspace.

"len" may be greater than "needed"; in this case, the code will write up
to "len" bytes into the buffer, however param->data_size is set to
"needed", so it may write data past the param->data_size value. The ioctl
interface copies only up to param->data_size into userspace, thus part of
the result will be truncated.

Fix this bug by setting "iter_info.end = (char *)vers + needed;" - this
guarantees that the second "dm_target_iterate" call will write only up to
the "needed" buffer and it will exit with "DM_BUFFER_FULL_FLAG" if it
overflows the "needed" space - in this case, userspace will allocate a
larger buffer and retry.

Note that there is also a bug in list_version_get_needed - we need to add
"strlen(tt->name) + 1" to the needed size, not "strlen(tt->name)".
CVSS Score: 4.7 (MEDIUM)
CWE: CWE-362
References: https://git.kernel.org/stable/c/0c8d4112df329bf3dfbf27693f918c3b08676538; https://git.kernel.org/stable/c/3a1c35d72dc0b34d1e746ed705790c0f630aa427; https://git.kernel.org/stable/c/4fe1ec995483737f3d2a14c3fe1d8fe634972979
CVE: CVE-2022-49772
Published: 2025-05-01
Description: In the Linux kernel, the following vulnerability has been resolved:

ALSA: usb-audio: Drop snd_BUG_ON() from snd_usbmidi_output_open()

snd_usbmidi_output_open() has a check of the NULL port with
snd_BUG_ON().  snd_BUG_ON() was used as this shouldn't have happened,
but in reality, the NULL port may be seen when the device gives an
invalid endpoint setup at the descriptor, hence the driver skips the
allocation.  That is, the check itself is valid and snd_BUG_ON()
should be dropped from there.  Otherwise it's confusing as if it were
a real bug, as recently syzbot stumbled on it.
CVSS Score: 5.5 (MEDIUM)
References: https://git.kernel.org/stable/c/00f5f1bbf815a39e9eecb468d12ca55d3360eb10; https://git.kernel.org/stable/c/02b94885b2fdf1808b1874e009bfb90753f8f4db; https://git.kernel.org/stable/c/a80369c8ca50bc885d14386087a834659ec54a54
CVE: CVE-2022-49773
Published: 2025-05-01
Description: In the Linux kernel, the following vulnerability has been resolved:

drm/amd/display: Fix optc2_configure warning on dcn314

[Why]
dcn314 uses optc2_configure_crc() that wraps
optc1_configure_crc() + set additional registers
not applicable to dcn314.
It's not critical but when used leads to warning like:
WARNING: drivers/gpu/drm/amd/amdgpu/../display/dc/dc_helper.c
Call Trace:
<TASK>
generic_reg_set_ex+0x6d/0xe0 [amdgpu]
optc2_configure_crc+0x60/0x80 [amdgpu]
dc_stream_configure_crc+0x129/0x150 [amdgpu]
amdgpu_dm_crtc_configure_crc_source+0x5d/0xe0 [amdgpu]

[How]
Use optc1_configure_crc() directly
CVSS Score: 5.5 (MEDIUM)
References: https://git.kernel.org/stable/c/e7e4f77c991c9abf90924929a9d55f90b0bb78de; https://git.kernel.org/stable/c/f67ef5aa88e3db0a13ae3befab2ddf14ac00a91c
CVE: CVE-2022-49774
Published: 2025-05-01
Description: In the Linux kernel, the following vulnerability has been resolved:

KVM: x86/xen: Fix eventfd error handling in kvm_xen_eventfd_assign()

Should not call eventfd_ctx_put() in case of error.

[Introduce new goto target instead. - Paolo]
CVSS Score: 5.5 (MEDIUM)
References: https://git.kernel.org/stable/c/[PII_REDACTED]f6e5b4899fb9ee1483709d6bb0e1cd; https://git.kernel.org/stable/c/d76f46f47dfde220712d1420ee5dbc546c8fc674
CVE: CVE-2022-49776
Published: 2025-05-01
Description: In the Linux kernel, the following vulnerability has been resolved:

macvlan: enforce a consistent minimal mtu

macvlan should enforce a minimal mtu of 68, even at link creation.

This patch avoids the current behavior (which could lead to crashes
in ipv6 stack if the link is brought up)

$ ip link add macvlan1 link eno1 mtu 8 type macvlan  # This should fail !
$ ip link sh dev macvlan1
5: macvlan1@eno1: <BROADCAST,MULTICAST> mtu 8 qdisc noop
    state DOWN mode DEFAULT group default qlen 1000
    link/ether 02:47:6c:24:74:82 brd ff:ff:ff:ff:ff:ff
$ ip link set macvlan1 mtu 67
Error: mtu less than device minimum.
$ ip link set macvlan1 mtu 68
$ ip link set macvlan1 mtu 8
Error: mtu less than device minimum.
CVSS Score: 5.5 (MEDIUM)
References: https://git.kernel.org/stable/c/2b055c719d8f94c15ec9b[PII_REDACTED]030c6a353; https://git.kernel.org/stable/c/650137a7c0b2892df2e5b0bc112d7b09a78c93c8; https://git.kernel.org/stable/c/a62aa84fe19eb24d083d600a074c009a0a66d4f3
CVE: CVE-2022-49777
Published: 2025-05-01
Description: In the Linux kernel, the following vulnerability has been resolved:

Input: i8042 - fix leaking of platform device on module removal

Avoid resetting the module-wide i8042_platform_device pointer in
i8042_probe() or i8042_remove(), so that the device can be properly
destroyed by i8042_exit() on module unload.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-401
References: https://git.kernel.org/stable/c/3f25add5ecf88de0f8ff2b27b6c0731a1f1b38ed; https://git.kernel.org/stable/c/4f348b60c79671eee33c1389efe89109c93047da; https://git.kernel.org/stable/c/81cd7e8489278d28794e7b272950c3e00c344e44