deardaniel/secdata-raw huggingface dataset:
CVE: CVE-2021-47396
Published: 2024-05-21
Description: In the Linux kernel, the following vulnerability has been resolved:

mac80211-hwsim: fix late beacon hrtimer handling

Thomas explained in https://lore.kernel.org/r/87mtoeb4hb.ffs@tglx
that our handling of the hrtimer here is wrong: If the timer fires
late (e.g. due to vCPU scheduling, as reported by Dmitry/syzbot)
then it tries to actually rearm the timer at the next deadline,
which might be in the past already:

 1          2          3          N          N+1
 |          |          |   ...    |          |

 ^ intended to fire here (1)
            ^ next deadline here (2)
                                      ^ actually fired here

The next time it fires, it's later, but will still try to schedule
for the next deadline (now 3), etc. until it catches up with N,
but that might take a long time, causing stalls etc.

Now, all of this is simulation, so we just have to fix it, but
note that the behaviour is wrong even per spec, since there's no
value then in sending all those beacons unaligned - they should be
aligned to the TBTT (1, 2, 3, ... in the picture), and if we're a
bit (or a lot) late, then just resume at that point.

Therefore, change the code to use hrtimer_forward_now() which will
ensure that the next firing of the timer would be at N+1 (in the
picture), i.e. the next interval point after the current time.
CVSS Score: 5.5 (MEDIUM)
References: https://git.kernel.org/stable/c/2c204cf594df3b9468368dc9d0b24d482d93cda7; https://git.kernel.org/stable/c/313bbd1990b6ddfdaa7da098d0c56b098a833572; https://git.kernel.org/stable/c/9bee85de2c8155388c09a2e1530a243ec1c96f05
CVE: CVE-2021-47397
Published: 2024-05-21
Description: In the Linux kernel, the following vulnerability has been resolved:

sctp: break out if skb_header_pointer returns NULL in sctp_rcv_ootb

We should always check if skb_header_pointer's return is NULL before
using it, otherwise it may cause null-ptr-deref, as syzbot reported:

  KASAN: null-ptr-deref in range [0x[PII_REDACTED]000000-0x[PII_REDACTED]000007]
  RIP: 0010:sctp_rcv_ootb net/sctp/input.c:705 [inline]
  RIP: 0010:sctp_rcv+0x1d84/0x3220 net/sctp/input.c:196
  Call Trace:
  <IRQ>
   sctp6_rcv+0x38/0x60 net/sctp/ipv6.c:1109
   ip6_protocol_deliver_rcu+0x2e9/0x1ca0 net/ipv6/ip6_input.c:422
   ip6_input_finish+0x62/0x170 net/ipv6/ip6_input.c:463
   NF_HOOK include/linux/netfilter.h:307 [inline]
   NF_HOOK include/linux/netfilter.h:301 [inline]
   ip6_input+0x9c/0xd0 net/ipv6/ip6_input.c:472
   dst_input include/net/dst.h:460 [inline]
   ip6_rcv_finish net/ipv6/ip6_input.c:76 [inline]
   NF_HOOK include/linux/netfilter.h:307 [inline]
   NF_HOOK include/linux/netfilter.h:301 [inline]
   ipv6_rcv+0x28c/0x3c0 net/ipv6/ip6_input.c:297
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-476
References: https://git.kernel.org/stable/c/77bc7dcf0fcc1519341a91788d7a2914fcfddf6d; https://git.kernel.org/stable/c/8180611c238e11676612eb2a9828b1c7a3a4d77b; https://git.kernel.org/stable/c/8c630a7b4f9dec63f08bd881ab77984a724a5124
CVE: CVE-2021-47398
Published: 2024-05-21
Description: In the Linux kernel, the following vulnerability has been resolved:

RDMA/hfi1: Fix kernel pointer leak

Pointers should be printed with %p or %px rather than cast to 'unsigned
long long' and printed with %llx.  Change %llx to %p to print the secured
pointer.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-401
References: https://git.kernel.org/stable/c/714bfabe5f2901d96902e271d7217601fe4703e5; https://git.kernel.org/stable/c/7d5cfafe8b4006a75b55c2f1fdfdb363f9a5cc98; https://git.kernel.org/stable/c/714bfabe5f2901d96902e271d7217601fe4703e5
CVE: CVE-2021-47399
Published: 2024-05-21
Description: In the Linux kernel, the following vulnerability has been resolved:

ixgbe: Fix NULL pointer dereference in ixgbe_xdp_setup

The ixgbe driver currently generates a NULL pointer dereference with
some machine (online cpus < 63). This is due to the fact that the
maximum value of num_xdp_queues is nr_cpu_ids. Code is in
"ixgbe_set_rss_queues"".

Here's how the problem repeats itself:
Some machine (online cpus < 63), And user set num_queues to 63 through
ethtool. Code is in the "ixgbe_set_channels",
	adapter->ring_feature[RING_F_FDIR].limit = count;

It becomes 63.

When user use xdp, "ixgbe_set_rss_queues" will set queues num.
	adapter->num_rx_queues = rss_i;
	adapter->num_tx_queues = rss_i;
	adapter->num_xdp_queues = ixgbe_xdp_queues(adapter);

And rss_i's value is from
	f = &adapter->ring_feature[RING_F_FDIR];
	rss_i = f->indices = f->limit;

So "num_rx_queues" > "num_xdp_queues", when run to "ixgbe_xdp_setup",
	for (i = 0; i < adapter->num_rx_queues; i++)
		if (adapter->xdp_ring[i]->xsk_umem)

It leads to panic.

Call trace:
[exception RIP: ixgbe_xdp+368]
RIP: ffffffffc02a76a0  RSP: ffff9fe16202f8d0  RFLAGS: 00010297
RAX: [PII_REDACTED]  RBX: [PII_REDACTED]  RCX: [PII_REDACTED]
RDX: [PII_REDACTED]  RSI:[PII_REDACTED]00001c  RDI: ffffffffa94ead90
RBP: ffff92f8f24c0c18   R8: [PII_REDACTED]   R9: [PII_REDACTED]
R10: ffff9fe16202f830  R11: [PII_REDACTED]  R12: ffff92f8f24c0000
R13: ffff9fe16202fc01  R14:[PII_REDACTED]00000a  R15: ffffffffc02a7530
ORIG_RAX: ffffffffffffffff  CS: 0010  SS: 0018
 7 [ffff9fe16202f8f0] dev_xdp_install at ffffffffa89fbbcc
 8 [ffff9fe16202f920] dev_change_xdp_fd at ffffffffa8a08808
 9 [ffff9fe16202f960] do_setlink at ffffffffa8a20235
10 [ffff9fe16202fa88] rtnl_setlink at ffffffffa8a20384
11 [ffff9fe16202fc78] rtnetlink_rcv_msg at ffffffffa8a1a8dd
12 [ffff9fe16202fcf0] netlink_rcv_skb at ffffffffa8a717eb
13 [ffff9fe16202fd40] netlink_unicast at ffffffffa8a70f88
14 [ffff9fe16202fd80] netlink_sendmsg at ffffffffa8a71319
15 [ffff9fe16202fdf0] sock_sendmsg at ffffffffa89df290
16 [ffff9fe16202fe08] __sys_sendto at ffffffffa89e19c8
17 [ffff9fe16202ff30] __x64_sys_sendto at ffffffffa89e1a64
18 [ffff9fe16202ff38] do_syscall_64 at ffffffffa84042b9
19 [ffff9fe16202ff50] entry_SYSCALL_64_after_hwframe at ffffffffa8c0008c

So I fix ixgbe_max_channels so that it will not allow a setting of queues
to be higher than the num_online_cpus(). And when run to ixgbe_xdp_setup,
take the smaller value of num_rx_queues and num_xdp_queues.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-476
References: https://git.kernel.org/stable/c/20f6c4a31a525edd9ea6243712b868ba0e4e331e; https://git.kernel.org/stable/c/2744341dd52e935344ca1b4bf189ba0d182a3e8e; https://git.kernel.org/stable/c/513e605d7a9ce136886cb42ebb2c40e9a6eb6333
CVE: CVE-2021-47400
Published: 2024-05-21
Description: In the Linux kernel, the following vulnerability has been resolved:

net: hns3: do not allow call hns3_nic_net_open repeatedly

hns3_nic_net_open() is not allowed to called repeatly, but there
is no checking for this. When doing device reset and setup tc
concurrently, there is a small oppotunity to call hns3_nic_net_open
repeatedly, and cause kernel bug by calling napi_enable twice.

The calltrace information is like below:
[ 3078.222780] ------------[ cut here ]------------
[ 3078.230255] kernel BUG at net/core/dev.c:6991!
[ 3078.236224] Internal error: Oops - BUG: 0 [#1] PREEMPT SMP
[ 3078.243431] Modules linked in: hns3 hclgevf hclge hnae3 vfio_iommu_type1 vfio_pci vfio_virqfd vfio pv680_mii(O)
[ 3078.258880] CPU: 0 PID: 295 Comm: kworker/u8:5 Tainted: G           O      5.14.0-rc4+ #1
[ 3078.269102] Hardware name:  , BIOS KpxxxFPGA 1P B600 V181 08/12/2021
[ 3078.276801] Workqueue: hclge hclge_service_task [hclge]
[ 3078.288774] pstate: 60400009 (nZCv daif +PAN -UAO -TCO BTYPE=--)
[ 3078.296168] pc : napi_enable+0x80/0x84
tc qdisc sho[w  3d0e7v8 .e3t0h218 79] lr : hns3_nic_net_open+0x138/0x510 [hns3]

[ 3078.314771] sp : ffff8000108abb20
[ 3078.319099] x29: ffff8000108abb20 x28: [PII_REDACTED] x27: ffff0820a8490300
[ 3078.329121] x26: [PII_REDACTED] x25: ffff08209cfc6200 x24: [PII_REDACTED]
[ 3078.339044] x23: ffff0820a8490300 x22: ffff08209cd76000 x21: ffff0820abfe3880
[ 3078.349018] x20: [PII_REDACTED] x19: ffff08209cd76900 x18: [PII_REDACTED]
[ 3078.358620] x17: [PII_REDACTED] x16: ffffc816e1727a50 x15: 0000ffff8f4ff930
[ 3078.368895] x14: [PII_REDACTED] x13: [PII_REDACTED] x12: 0000259e9dbeb6b4
[ 3078.377987] x11: 0096a8f7e764eb40 x10: 634615ad28d3eab5 x9 : ffffc816ad8885b8
[ 3078.387091] x8 : ffff08209cfc6fb8 x7 : ffff0820ac0da058 x6 : ffff0820a8490344
[ 3078.396356] x5 : [PII_REDACTED] x4 : [PII_REDACTED] x3 : ffff08209cd76938
[ 3078.405365] x2 : [PII_REDACTED] x1 : [PII_REDACTED] x0 : ffff0820abfe38a0
[ 3078.414657] Call trace:
[ 3078.418517]  napi_enable+0x80/0x84
[ 3078.424626]  hns3_reset_notify_up_enet+0x78/0xd0 [hns3]
[ 3078.433469]  hns3_reset_notify+0x64/0x80 [hns3]
[ 3078.441430]  hclge_notify_client+0x68/0xb0 [hclge]
[ 3078.450511]  hclge_reset_rebuild+0x524/0x884 [hclge]
[ 3078.458879]  hclge_reset_service_task+0x3c4/0x680 [hclge]
[ 3078.467470]  hclge_service_task+0xb0/0xb54 [hclge]
[ 3078.475675]  process_one_work+0x1dc/0x48c
[ 3078.481888]  worker_thread+0x15c/0x464
[ 3078.487104]  kthread+0x160/0x170
[ 3078.492479]  ret_from_fork+0x10/0x18
[ 3078.498785] Code: c8027c81 35ffffa2 d50323bf d65f03c0 (d4210000)
[ 3078.506889] ---[ end trace 8ebe0340a1b0fb44 ]---

Once hns3_nic_net_open() is excute success, the flag
HNS3_NIC_STATE_DOWN will be cleared. So add checking for this
flag, directly return when HNS3_NIC_STATE_DOWN is no set.
CVSS Score: 5.5 (MEDIUM)
References: https://git.kernel.org/stable/c/3dac38bdce7932901b9f0b71c62331852c809e61; https://git.kernel.org/stable/c/5a31d4e73ada8022427b69b10fd1f01a6a8d4b3d; https://git.kernel.org/stable/c/5b09e88e1bf7fe86540fab4b5f3eece8abead39e
CVE: CVE-2021-47401
Published: 2024-05-21
Description: In the Linux kernel, the following vulnerability has been resolved:

ipack: ipoctal: fix stack information leak

The tty driver name is used also after registering the driver and must
specifically not be allocated on the stack to avoid leaking information
to user space (or triggering an oops).

Drivers should not try to encode topology information in the tty device
name but this one snuck in through staging without anyone noticing and
another driver has since copied this malpractice.

Fixing the ABI is a separate issue, but this at least plugs the security
hole.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-668
References: https://git.kernel.org/stable/c/0a9c36a2e06a249acbed64e8e0b84637c2ad7575; https://git.kernel.org/stable/c/[PII_REDACTED]dc96a78069cd118ea3d66759bfdad7; https://git.kernel.org/stable/c/5f6a309a699675680df15d9b6d389114515b4426
CVE: CVE-2021-47403
Published: 2024-05-21
Description: In the Linux kernel, the following vulnerability has been resolved:

ipack: ipoctal: fix module reference leak

A reference to the carrier module was taken on every open but was only
released once when the final reference to the tty struct was dropped.

Fix this by taking the module reference and initialising the tty driver
data when installing the tty.
CVSS Score: 7.1 (HIGH)
CWE: CWE-200
References: https://git.kernel.org/stable/c/31398849b84ebae0d43a1cf379cb9895597f221a; https://git.kernel.org/stable/c/3253c87e1e5bc0107aab773af2f135ebccf38666; https://git.kernel.org/stable/c/7cea848678470daadbfdaa6a112b823c290f900c
CVE: CVE-2021-47404
Published: 2024-05-21
Description: In the Linux kernel, the following vulnerability has been resolved:

HID: betop: fix slab-out-of-bounds Write in betop_probe

Syzbot reported slab-out-of-bounds Write bug in hid-betopff driver.
The problem is the driver assumes the device must have an input report but
some malicious devices violate this assumption.

So this patch checks hid_device's input is non empty before it's been used.
CVSS Score: 7.8 (HIGH)
CWE: CWE-787
References: https://git.kernel.org/stable/c/1c83c38dec83d57bc18d0c01d82c413d3b34ccb9; https://git.kernel.org/stable/c/1e4ce418b1cb1a810256b5fb3fd33d22d1325993; https://git.kernel.org/stable/c/6fc4476dda58f6c00097c7ddec3b772513f57525
CVE: CVE-2021-47405
Published: 2024-05-21
Description: In the Linux kernel, the following vulnerability has been resolved:

HID: usbhid: free raw_report buffers in usbhid_stop

Free the unsent raw_report buffers when the device is removed.

Fixes a memory leak reported by syzbot at:
https://syzkaller.appspot.com/bug?id=7b4fa7cb1a7c2d3342a2a8a6c53371c8c418ab47
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-401
References: https://git.kernel.org/stable/c/2b704864c92dcec2b295f276fcfbfb81d9831f81; https://git.kernel.org/stable/c/764ac04de056801dfe52a716da63f6e7018e7f3b; https://git.kernel.org/stable/c/7ce4e[PII_REDACTED]1265671b1d30d[PII_REDACTED]0
CVE: CVE-2021-47406
Published: 2024-05-21
Description: In the Linux kernel, the following vulnerability has been resolved:

ext4: add error checking to ext4_ext_replay_set_iblocks()

If the call to ext4_map_blocks() fails due to an corrupted file
system, ext4_ext_replay_set_iblocks() can get stuck in an infinite
loop.  This could be reproduced by running generic/526 with a file
system that has inline_data and fast_commit enabled.  The system will
repeatedly log to the console:

EXT4-fs warning (device dm-3): ext4_block_to_path:105: block[PII_REDACTED] > max in inode 131076

and the stack that it gets stuck in is:

   ext4_block_to_path+0xe3/0x130
   ext4_ind_map_blocks+0x93/0x690
   ext4_map_blocks+0x100/0x660
   skip_hole+0x47/0x70
   ext4_ext_replay_set_iblocks+0x223/0x440
   ext4_fc_replay_inode+0x29e/0x3b0
   ext4_fc_replay+0x278/0x550
   do_one_pass+0x646/0xc10
   jbd2_journal_recover+0x14a/0x270
   jbd2_journal_load+0xc4/0x150
   ext4_load_journal+0x1f3/0x490
   ext4_fill_super+0x22d4/0x2c00

With this patch, generic/526 still fails, but system is no longer
locking up in a tight loop.  It's likely the root casue is that
fast_commit replay is corrupting file systems with inline_data, and we
probably need to add better error handling in the fast commit replay
code path beyond what is done here, which essentially just breaks the
infinite loop without reporting the to the higher levels of the code.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-835
References: https://git.kernel.org/stable/c/1fd95c05d8f742abfe906620780aee4dbe1a2db0; https://git.kernel.org/stable/c/27e10c5d31ff1d222c7f797f1ee96d422859ba67; https://git.kernel.org/stable/c/a63474dbf692dd09b50fed592bc41f6de5f102fc
CVE: CVE-2021-47407
Published: 2024-05-21
Description: In the Linux kernel, the following vulnerability has been resolved:

KVM: x86: Handle SRCU initialization failure during page track init

Check the return of init_srcu_struct(), which can fail due to OOM, when
initializing the page track mechanism.  Lack of checking leads to a NULL
pointer deref found by a modified syzkaller.

[Move the call towards the beginning of kvm_arch_init_vm. - Paolo]
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-476
References: https://git.kernel.org/stable/c/4664318f73e496cd22c71b10888e75434a123e23; https://git.kernel.org/stable/c/deb[PII_REDACTED]649e2413266d7ce8c2ff73952b4; https://git.kernel.org/stable/c/eb7511bf9182292ef1df1082d23039e856d1ddfb
CVE: CVE-2021-47409
Published: 2024-05-21
Description: In the Linux kernel, the following vulnerability has been resolved:

usb: dwc2: check return value after calling platform_get_resource()

It will cause null-ptr-deref if platform_get_resource() returns NULL,
we need check the return value.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-476
References: https://git.kernel.org/stable/c/2754fa3b73df7d0ae042f3ed6cfd9df9042f6262; https://git.kernel.org/stable/c/337f00a0bc62d7cb7d10ec0b872c79009a1641df; https://git.kernel.org/stable/c/4b7f4a0eb92bf37bea4cd838c7f83ea42823ca8b
CVE: CVE-2021-47410
Published: 2024-05-21
Description: In the Linux kernel, the following vulnerability has been resolved:

drm/amdkfd: fix svm_migrate_fini warning

Device manager releases device-specific resources when a driver
disconnects from a device, devm_memunmap_pages and
devm_release_mem_region calls in svm_migrate_fini are redundant.

It causes below warning trace after patch "drm/amdgpu: Split
amdgpu_device_fini into early and late", so remove function
svm_migrate_fini.

BUG: https://gitlab.freedesktop.org/drm/amd/-/issues/1718

WARNING: CPU: 1 PID: 3646 at drivers/base/devres.c:795
devm_release_action+0x51/0x60
Call Trace:
    ? memunmap_pages+0x360/0x360
    svm_migrate_fini+0x2d/0x60 [amdgpu]
    kgd2kfd_device_exit+0x23/0xa0 [amdgpu]
    amdgpu_amdkfd_device_fini_sw+0x1d/0x30 [amdgpu]
    amdgpu_device_fini_sw+0x45/0x290 [amdgpu]
    amdgpu_driver_release_kms+0x12/0x30 [amdgpu]
    drm_dev_release+0x20/0x40 [drm]
    release_nodes+0x196/0x1e0
    device_release_driver_internal+0x104/0x1d0
    driver_detach+0x47/0x90
    bus_remove_driver+0x7a/0xd0
    pci_unregister_driver+0x3d/0x90
    amdgpu_exit+0x11/0x20 [amdgpu]
CVSS Score: 5.5 (MEDIUM)
References: https://git.kernel.org/stable/c/197ae17722e989942b36e33e044787877f158574; https://git.kernel.org/stable/c/ac7d732b24f4061f8a732ada49b054ab38c63e15; https://git.kernel.org/stable/c/197ae17722e989942b36e33e044787877f158574
CVE: CVE-2021-47411
Published: 2024-05-21
Description: Rejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.
CVE: CVE-2021-47412
Published: 2024-05-21
Description: In the Linux kernel, the following vulnerability has been resolved:

block: don't call rq_qos_ops->done_bio if the bio isn't tracked

rq_qos framework is only applied on request based driver, so:

1) rq_qos_done_bio() needn't to be called for bio based driver

2) rq_qos_done_bio() needn't to be called for bio which isn't tracked,
such as bios ended from error handling code.

Especially in bio_endio():

1) request queue is referred via bio->bi_bdev->bd_disk->queue, which
may be gone since request queue refcount may not be held in above two
cases

2) q->rq_qos may be freed in blk_cleanup_queue() when calling into
__rq_qos_done_bio()

Fix the potential kernel panic by not calling rq_qos_ops->done_bio if
the bio isn't tracked. This way is safe because both ioc_rqos_done_bio()
and blkcg_iolatency_done_bio() are nop if the bio isn't tracked.
CVSS Score: 5.5 (MEDIUM)
References: https://git.kernel.org/stable/c/004b8f8a691205a93d9e80d98b786b2b97424d6e; https://git.kernel.org/stable/c/a647a524a46736786c95cdb553a070322ca096e3; https://git.kernel.org/stable/c/db60edbfff332a6a5477c367af8125f034570989
CVE: CVE-2021-47413
Published: 2024-05-21
Description: In the Linux kernel, the following vulnerability has been resolved:

usb: chipidea: ci_hdrc_imx: Also search for 'phys' phandle

When passing 'phys' in the devicetree to describe the USB PHY phandle
(which is the recommended way according to
Documentation/devicetree/bindings/usb/ci-hdrc-usb2.txt) the
following NULL pointer dereference is observed on i.MX7 and i.MX8MM:

[    1.489344] Unable to handle kernel NULL pointer dereference at virtual address [PII_REDACTED]
[    1.498170] Mem abort info:
[    1.500966]   ESR = 0x96000044
[    1.504030]   EC = 0x25: DABT (current EL), IL = 32 bits
[    1.509356]   SET = 0, FnV = 0
[    1.512416]   EA = 0, S1PTW = 0
[    1.515569]   FSC = 0x04: level 0 translation fault
[    1.520458] Data abort info:
[    1.523349]   ISV = 0, ISS = 0x00000044
[    1.527196]   CM = 0, WnR = 1
[    1.530176] [[PII_REDACTED]] user address but active_mm is swapper
[    1.536544] Internal error: Oops: 96000044 [#1] PREEMPT SMP
[    1.542125] Modules linked in:
[    1.545190] CPU: 3 PID: 7 Comm: kworker/u8:0 Not tainted 5.14.0-dirty #3
[    1.551901] Hardware name: Kontron i.MX8MM N801X S (DT)
[    1.557133] Workqueue: events_unbound deferred_probe_work_func
[    1.562984] pstate: 80000005 (Nzcv daif -PAN -UAO -TCO BTYPE=--)
[    1.568998] pc : imx7d_charger_detection+0x3f0/0x510
[    1.573973] lr : imx7d_charger_detection+0x22c/0x510

This happens because the charger functions check for the phy presence
inside the imx_usbmisc_data structure (data->usb_phy), but the chipidea
core populates the usb_phy passed via 'phys' inside 'struct ci_hdrc'
(ci->usb_phy) instead.

This causes the NULL pointer dereference inside imx7d_charger_detection().

Fix it by also searching for 'phys' in case 'fsl,usbphy' is not found.

Tested on a imx7s-warp board.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-476
References: https://git.kernel.org/stable/c/66dd03b10e1c0b2fae006c6e34c18ea8ee033e7b; https://git.kernel.org/stable/c/8253a34bfae3278baca52fc1209b7c29270486ca; https://git.kernel.org/stable/c/b3265b88e83b16c7be762fa5fb7e0632bce0002c
CVE: CVE-2021-47415
Published: 2024-05-21
Description: In the Linux kernel, the following vulnerability has been resolved:

iwlwifi: mvm: Fix possible NULL dereference

In __iwl_mvm_remove_time_event() check that 'te_data->vif' is NULL
before dereferencing it.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-476
References: https://git.kernel.org/stable/c/24d5f16e407b75bc59d5419b957a9cab423b2681; https://git.kernel.org/stable/c/432d8185e9ffce97e3866ca71c39b0807a456920; https://git.kernel.org/stable/c/24d5f16e407b75bc59d5419b957a9cab423b2681
CVE: CVE-2021-47416
Published: 2024-05-21
Description: In the Linux kernel, the following vulnerability has been resolved:

phy: mdio: fix memory leak

Syzbot reported memory leak in MDIO bus interface, the problem was in
wrong state logic.

MDIOBUS_ALLOCATED indicates 2 states:
	1. Bus is only allocated
	2. Bus allocated and __mdiobus_register() fails, but
	   device_register() was called

In case of device_register() has been called we should call put_device()
to correctly free the memory allocated for this device, but mdiobus_free()
calls just kfree(dev) in case of MDIOBUS_ALLOCATED state

To avoid this behaviour we need to set bus->state to MDIOBUS_UNREGISTERED
_before_ calling device_register(), because put_device() should be
called even in case of device_register() failure.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-401
References: https://git.kernel.org/stable/c/064c2616234a7394867c924b5c1303974f3a4f4d; https://git.kernel.org/stable/c/0d2dd40a7be61b89a7c99dae8ee96389d27b413a; https://git.kernel.org/stable/c/2250392d930bd0d989f24d355d6355b0150256e7
CVE: CVE-2021-47417
Published: 2024-05-21
Description: In the Linux kernel, the following vulnerability has been resolved:

libbpf: Fix memory leak in strset

Free struct strset itself, not just its internal parts.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-401
References: https://git.kernel.org/stable/c/9e8e7504e09831c469b67d6dc11d9a72654bdb8c; https://git.kernel.org/stable/c/b0e875bac0fab3e7a7431c2eee36a8ccc0c712ac; https://git.kernel.org/stable/c/9e8e7504e09831c469b67d6dc11d9a72654bdb8c