deardaniel/secdata-raw huggingface dataset:
CVE: CVE-2022-48994
Published: 2024-10-21
Description: In the Linux kernel, the following vulnerability has been resolved:

ALSA: seq: Fix function prototype mismatch in snd_seq_expand_var_event

With clang's kernel control flow integrity (kCFI, CONFIG_CFI_CLANG),
indirect call targets are validated against the expected function
pointer prototype to make sure the call target is valid to help mitigate
ROP attacks. If they are not identical, there is a failure at run time,
which manifests as either a kernel panic or thread getting killed.

seq_copy_in_user() and seq_copy_in_kernel() did not have prototypes
matching snd_seq_dump_func_t. Adjust this and remove the casts. There
are not resulting binary output differences.

This was found as a result of Clang's new -Wcast-function-type-strict
flag, which is more sensitive than the simpler -Wcast-function-type,
which only checks for type width mismatches.
CVSS Score: 5.5 (MEDIUM)
References: https://git.kernel.org/stable/c/05530ef7cf7c7d700f6753f058999b1b5099a026; https://git.kernel.org/stable/c/13ee8fb5410b740c8dd2867d3557c7662f7dda2d; https://git.kernel.org/stable/c/15c42ab8d43acb73e2eba361ad05822c0af0ecfa
CVE: CVE-2022-48995
Published: 2024-10-21
Description: In the Linux kernel, the following vulnerability has been resolved:

Input: raydium_ts_i2c - fix memory leak in raydium_i2c_send()

There is a kmemleak when test the raydium_i2c_ts with bpf mock device:

  unreferenced object 0xffff88812d3675a0 (size 8):
    comm "python3", pid 349, jiffies[PII_REDACTED] (age 95.695s)
    hex dump (first 8 bytes):
      11 0e 10 c0 01 00 04 00                          ........
    backtrace:
      [<[PII_REDACTED]>] __kmalloc+0x46/0x1b0
      [<[PII_REDACTED]180f91>] raydium_i2c_send+0xd4/0x2bf [raydium_i2c_ts]
      [<000000006e631aee>] raydium_i2c_initialize.cold+0xbc/0x3e4 [raydium_i2c_ts]
      [<00000000dc6fcf38>] raydium_i2c_probe+0x3cd/0x6bc [raydium_i2c_ts]
      [<00000000a310de16>] i2c_device_probe+0x651/0x680
      [<00000000f5a96bf3>] really_probe+0x17c/0x3f0
      [<[PII_REDACTED]6ba499>] __driver_probe_device+0xe3/0x170
      [<00000000c5acb4d9>] driver_probe_device+0x49/0x120
      [<[PII_REDACTED]4fe082>] __device_attach_driver+0xf7/0x150
      [<00000000f919423c>] bus_for_each_drv+0x114/0x180
      [<00000000e067feca>] __device_attach+0x1e5/0x2d0
      [<[PII_REDACTED]301fc2>] bus_probe_device+0x126/0x140
      [<00000000aad93b22>] device_add+0x810/0x1130
      [<00000000c086a53f>] i2c_new_client_device+0x352/0x4e0
      [<000000003c2c248c>] of_i2c_register_device+0xf1/0x110
      [<00000000ffec4177>] of_i2c_notify+0x100/0x160
  unreferenced object 0xffff88812d3675c8 (size 8):
    comm "python3", pid 349, jiffies[PII_REDACTED] (age 95.692s)
    hex dump (first 8 bytes):
      22 00 36 2d 81 88 ff ff                          ".6-....
    backtrace:
      [<[PII_REDACTED]>] __kmalloc+0x46/0x1b0
      [<[PII_REDACTED]180f91>] raydium_i2c_send+0xd4/0x2bf [raydium_i2c_ts]
      [<000000001d5c9620>] raydium_i2c_initialize.cold+0x223/0x3e4 [raydium_i2c_ts]
      [<00000000dc6fcf38>] raydium_i2c_probe+0x3cd/0x6bc [raydium_i2c_ts]
      [<00000000a310de16>] i2c_device_probe+0x651/0x680
      [<00000000f5a96bf3>] really_probe+0x17c/0x3f0
      [<[PII_REDACTED]6ba499>] __driver_probe_device+0xe3/0x170
      [<00000000c5acb4d9>] driver_probe_device+0x49/0x120
      [<[PII_REDACTED]4fe082>] __device_attach_driver+0xf7/0x150
      [<00000000f919423c>] bus_for_each_drv+0x114/0x180
      [<00000000e067feca>] __device_attach+0x1e5/0x2d0
      [<[PII_REDACTED]301fc2>] bus_probe_device+0x126/0x140
      [<00000000aad93b22>] device_add+0x810/0x1130
      [<00000000c086a53f>] i2c_new_client_device+0x352/0x4e0
      [<000000003c2c248c>] of_i2c_register_device+0xf1/0x110
      [<00000000ffec4177>] of_i2c_notify+0x100/0x160

After BANK_SWITCH command from i2c BUS, no matter success or error
happened, the tx_buf should be freed.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-401
References: https://git.kernel.org/stable/c/097c1c7a28e3da8f2811ba532be6e81faab15aab; https://git.kernel.org/stable/c/53b9b1201e34ccc[PII_REDACTED]59123625c56fbcd; https://git.kernel.org/stable/c/8c9a59939deb4bfafdc451100c03d1e848b4169b
CVE: CVE-2022-48996
Published: 2024-10-21
Description: In the Linux kernel, the following vulnerability has been resolved:

mm/damon/sysfs: fix wrong empty schemes assumption under online tuning in damon_sysfs_set_schemes()

Commit da87878010e5 ("mm/damon/sysfs: support online inputs update") made
'damon_sysfs_set_schemes()' to be called for running DAMON context, which
could have schemes.  In the case, DAMON sysfs interface is supposed to
update, remove, or add schemes to reflect the sysfs files.  However, the
code is assuming the DAMON context wouldn't have schemes at all, and
therefore creates and adds new schemes.  As a result, the code doesn't
work as intended for online schemes tuning and could have more than
expected memory footprint.  The schemes are all in the DAMON context, so
it doesn't leak the memory, though.

Remove the wrong asssumption (the DAMON context wouldn't have schemes) in
'damon_sysfs_set_schemes()' to fix the bug.
CVSS Score: 5.5 (MEDIUM)
References: https://git.kernel.org/stable/c/95bc35f9bee5220dad4e8567654ab3288a181639; https://git.kernel.org/stable/c/f98d1f2a36ad7ab48fb4cf73ca14e7b19482fd4d
CVE: CVE-2022-48997
Published: 2024-10-21
Description: In the Linux kernel, the following vulnerability has been resolved:

char: tpm: Protect tpm_pm_suspend with locks

Currently tpm transactions are executed unconditionally in
tpm_pm_suspend() function, which may lead to races with other tpm
accessors in the system.

Specifically, the hw_random tpm driver makes use of tpm_get_random(),
and this function is called in a loop from a kthread, which means it's
not frozen alongside userspace, and so can race with the work done
during system suspend:

  tpm tpm0: tpm_transmit: tpm_recv: error -52
  tpm tpm0: invalid TPM_STS.x 0xff, dumping stack for forensics
  CPU: 0 PID: 1 Comm: init Not tainted 6.1.0-rc5+ #135
  Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.0-20220807_005459-localhost 04/01/2014
  Call Trace:
   tpm_tis_status.cold+0x19/0x20
   tpm_transmit+0x13b/0x390
   tpm_transmit_cmd+0x20/0x80
   tpm1_pm_suspend+0xa6/0x110
   tpm_pm_suspend+0x53/0x80
   __pnp_bus_suspend+0x35/0xe0
   __device_suspend+0x10f/0x350

Fix this by calling tpm_try_get_ops(), which itself is a wrapper around
tpm_chip_start(), but takes the appropriate mutex.

[Jason: reworked commit message, added metadata]
CVSS Score: 4.7 (MEDIUM)
References: https://git.kernel.org/stable/c/23393c6461422df5bf8084a086ada9a7e17dc2ba; https://git.kernel.org/stable/c/25b78bf98b07ff5aceb9b1e24f72ec0236c5c053; https://git.kernel.org/stable/c/4e0d6c687c925e27fd4bc78a2721d10acf5614d6
CVE: CVE-2022-48999
Published: 2024-10-21
Description: In the Linux kernel, the following vulnerability has been resolved:

ipv4: Handle attempt to delete multipath route when fib_info contains an nh reference

Gwangun Jung reported a slab-out-of-bounds access in fib_nh_match:
    fib_nh_match+0xf98/0x1130 linux-6.0-rc7/net/ipv4/fib_semantics.c:961
    fib_table_delete+0x5f3/0xa40 linux-6.0-rc7/net/ipv4/fib_trie.c:1753
    inet_rtm_delroute+0x2b3/0x380 linux-6.0-rc7/net/ipv4/fib_frontend.c:874

Separate nexthop objects are mutually exclusive with the legacy
multipath spec. Fix fib_nh_match to return if the config for the
to be deleted route contains a multipath spec while the fib_info
is using a nexthop object.
CVSS Score: 7.1 (HIGH)
CWE: CWE-125
References: https://git.kernel.org/stable/c/0b5394229ebae09afc07aabccb5ffd705ffd250e; https://git.kernel.org/stable/c/25174d91e4a32a24204060d283bd5fa6d0ddf133; https://git.kernel.org/stable/c/61b91eb33a69c3be11b259c5ea484505cd79f883
CVE: CVE-2022-49000
Published: 2024-10-21
Description: In the Linux kernel, the following vulnerability has been resolved:

iommu/vt-d: Fix PCI device refcount leak in has_external_pci()

for_each_pci_dev() is implemented by pci_get_device(). The comment of
pci_get_device() says that it will increase the reference count for the
returned pci_dev and also decrease the reference count for the input
pci_dev @from if it is not NULL.

If we break for_each_pci_dev() loop with pdev not NULL, we need to call
pci_dev_put() to decrease the reference count. Add the missing
pci_dev_put() before 'return true' to avoid reference count leak.
CVSS Score: 5.5 (MEDIUM)
References: https://git.kernel.org/stable/c/10ed7655a17f6a3eaecd[PII_REDACTED]59ccd5723; https://git.kernel.org/stable/c/17f67414718e6aba123335a33b7d15aa594fff34; https://git.kernel.org/stable/c/afca9e19cc720bfafc75dc5ce429c185ca93f31d
CVE: CVE-2022-49001
Published: 2024-10-21
Description: In the Linux kernel, the following vulnerability has been resolved:

riscv: fix race when vmap stack overflow

Currently, when detecting vmap stack overflow, riscv firstly switches
to the so called shadow stack, then use this shadow stack to call the
get_overflow_stack() to get the overflow stack. However, there's
a race here if two or more harts use the same shadow stack at the same
time.

To solve this race, we introduce spin_shadow_stack atomic var, which
will be swap between its own address and 0 in atomic way, when the
var is set, it means the shadow_stack is being used; when the var
is cleared, it means the shadow_stack isn't being used.

[Palmer: Add AQ to the swap, and also some comments.]
CVSS Score: 7.0 (HIGH)
CWE: CWE-362
References: https://git.kernel.org/stable/c/7e1864332fbc1b993659eab7974da9fe8bf8c128; https://git.kernel.org/stable/c/879fabc5a95401d9bce357e4b1d24ae4a360a81f; https://git.kernel.org/stable/c/ac00301adb19df54f2eae1efc4bad7447c0156ce
CVE: CVE-2022-49002
Published: 2024-10-21
Description: In the Linux kernel, the following vulnerability has been resolved:

iommu/vt-d: Fix PCI device refcount leak in dmar_dev_scope_init()

for_each_pci_dev() is implemented by pci_get_device(). The comment of
pci_get_device() says that it will increase the reference count for the
returned pci_dev and also decrease the reference count for the input
pci_dev @from if it is not NULL.

If we break for_each_pci_dev() loop with pdev not NULL, we need to call
pci_dev_put() to decrease the reference count. Add the missing
pci_dev_put() for the error path to avoid reference count leak.
CVSS Score: 5.5 (MEDIUM)
References: https://git.kernel.org/stable/c/2a8f7b[PII_REDACTED]8de172dbbf5a54cd342870aa; https://git.kernel.org/stable/c/4bedbbd782ebbe7287231fea862c158d4f08a9e3; https://git.kernel.org/stable/c/71c4a621985fc051ab86d3a86c749069a993fcb2
CVE: CVE-2022-49004
Published: 2024-10-21
Description: In the Linux kernel, the following vulnerability has been resolved:

riscv: Sync efi page table's kernel mappings before switching

The EFI page table is initially created as a copy of the kernel page table.
With VMAP_STACK enabled, kernel stacks are allocated in the vmalloc area:
if the stack is allocated in a new PGD (one that was not present at the
moment of the efi page table creation or not synced in a previous vmalloc
fault), the kernel will take a trap when switching to the efi page table
when the vmalloc kernel stack is accessed, resulting in a kernel panic.

Fix that by updating the efi kernel mappings before switching to the efi
page table.
CVSS Score: 5.5 (MEDIUM)
References: https://git.kernel.org/stable/c/3f105a742725a1b78766a55169f1d827732e62b8; https://git.kernel.org/stable/c/96f479383d92944406d4b3f2bc03c2f640def9f1; https://git.kernel.org/stable/c/fa7a7d185ef380546b4b1fed6f84f31dbae8cec7
CVE: CVE-2022-49005
Published: 2024-10-21
Description: In the Linux kernel, the following vulnerability has been resolved:

ASoC: ops: Fix bounds check for _sx controls

For _sx controls the semantics of the max field is not the usual one, max
is the number of steps rather than the maximum value. This means that our
check in snd_soc_put_volsw_sx() needs to just check against the maximum
value.
CVSS Score: 5.5 (MEDIUM)
References: https://git.kernel.org/stable/c/325d94d16e3131b54bdf07356e4cd855e0d853fc; https://git.kernel.org/stable/c/46bab25cc0230df60d1c02b651cc5640a14b08df; https://git.kernel.org/stable/c/4a95a49f26308782b[PII_REDACTED]ecd7768fda8fa
CVE: CVE-2022-49008
Published: 2024-10-21
Description: In the Linux kernel, the following vulnerability has been resolved:

can: can327: can327_feed_frame_to_netdev(): fix potential skb leak when netdev is down

In can327_feed_frame_to_netdev(), it did not free the skb when netdev
is down, and all callers of can327_feed_frame_to_netdev() did not free
allocated skb too. That would trigger skb leak.

Fix it by adding kfree_skb() in can327_feed_frame_to_netdev() when netdev
is down. Not tested, just compiled.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-401
References: https://git.kernel.org/stable/c/797b1d9fc0e1f4351e4ad49b078c1a3cdc0d4a08; https://git.kernel.org/stable/c/8fa452cfafed521aaf5a18c71003fe24b1ee6141
CVE: CVE-2022-49009
Published: 2024-10-21
Description: In the Linux kernel, the following vulnerability has been resolved:

hwmon: (asus-ec-sensors) Add checks for devm_kcalloc

As the devm_kcalloc may return NULL, the return value needs to be checked
to avoid NULL poineter dereference.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-476
References: https://git.kernel.org/stable/c/9bdc112be727cf1ba65be79541147f960c3349d8; https://git.kernel.org/stable/c/a41ec58ac352fd176d5808af847663dc890f6053
CVE: CVE-2022-49010
Published: 2024-10-21
Description: In the Linux kernel, the following vulnerability has been resolved:

hwmon: (coretemp) Check for null before removing sysfs attrs

If coretemp_add_core() gets an error then pdata->core_data[indx]
is already NULL and has been kfreed. Don't pass that to
sysfs_remove_group() as that will crash in sysfs_remove_group().

[Shortened for readability]
[91854.020159] sysfs: cannot create duplicate filename '/devices/platform/coretemp.0/hwmon/hwmon2/temp20_label'
<cpu offline>
[91855.126115] BUG: kernel NULL pointer dereference, address: [PII_REDACTED]
[91855.165103] #PF: supervisor read access in kernel mode
[91855.194506] #PF: error_code(0x0000) - not-present page
[91855.224445] PGD 0 P4D 0
[91855.238508] Oops: 0000 [#1] PREEMPT SMP PTI
...
[91855.342716] RIP: 0010:sysfs_remove_group+0xc/0x80
...
[91855.796571] Call Trace:
[91855.810524]  coretemp_cpu_offline+0x12b/0x1dd [coretemp]
[91855.841738]  ? coretemp_cpu_online+0x180/0x180 [coretemp]
[91855.871107]  cpuhp_invoke_callback+0x105/0x4b0
[91855.893432]  cpuhp_thread_fun+0x8e/0x150
...

Fix this by checking for NULL first.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-476
References: https://git.kernel.org/stable/c/070d5ea4a0592a37ad96ce7f7b6b024f90bb009f; https://git.kernel.org/stable/c/280110db1a7d62ad635b103bafc3ae96e8bef75c; https://git.kernel.org/stable/c/7692700ac818866d138a8de555130a6e70e6ac16
CVE: CVE-2022-49011
Published: 2024-10-21
Description: In the Linux kernel, the following vulnerability has been resolved:

hwmon: (coretemp) fix pci device refcount leak in nv1a_ram_new()

As comment of pci_get_domain_bus_and_slot() says, it returns
a pci device with refcount increment, when finish using it,
the caller must decrement the reference count by calling
pci_dev_put(). So call it after using to avoid refcount leak.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-401
References: https://git.kernel.org/stable/c/0dd1da5a15eeecb2fe4cf131b3216fb455af783c; https://git.kernel.org/stable/c/2f74cffc7c85f770b1b1833dccb03b8cde3be102; https://git.kernel.org/stable/c/6e035d5a2a6b907cfce9a80c5f442c2e459cd34e
CVE: CVE-2022-49012
Published: 2024-10-21
Description: In the Linux kernel, the following vulnerability has been resolved:

afs: Fix server->active leak in afs_put_server

The atomic_read was accidentally replaced with atomic_inc_return,
which prevents the server from getting cleaned up and causes rmmod
to hang with a warning:

    Can't purge s=00000001
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-459
References: https://git.kernel.org/stable/c/c5078548c29c735f71b05053659c0cb294e738ad; https://git.kernel.org/stable/c/ef4d3ea40565a781c25847e9cb96c1bd9f462bc6
CVE: CVE-2022-49013
Published: 2024-10-21
Description: In the Linux kernel, the following vulnerability has been resolved:

sctp: fix memory leak in sctp_stream_outq_migrate()

When sctp_stream_outq_migrate() is called to release stream out resources,
the memory pointed to by prio_head in stream out is not released.

The memory leak information is as follows:
 unreferenced object 0xffff88801fe79f80 (size 64):
   comm "sctp_repo", pid 7957, jiffies[PII_REDACTED] (age 36.480s)
   hex dump (first 32 bytes):
     80 9f e7 1f 80 88 ff ff 80 9f e7 1f 80 88 ff ff  ................
     90 9f e7 1f 80 88 ff ff 90 9f e7 1f 80 88 ff ff  ................
   backtrace:
     [<ffffffff81b215c6>] kmalloc_trace+0x26/0x60
     [<ffffffff88ae517c>] sctp_sched_prio_set+0x4cc/0x770
     [<ffffffff88ad64f2>] sctp_stream_init_ext+0xd2/0x1b0
     [<ffffffff88aa2604>] sctp_sendmsg_to_asoc+0x1614/0x1a30
     [<ffffffff88ab7ff1>] sctp_sendmsg+0xda1/0x1ef0
     [<ffffffff87f765ed>] inet_sendmsg+0x9d/0xe0
     [<ffffffff8754b5b3>] sock_sendmsg+0xd3/0x120
     [<ffffffff8755446a>] __sys_sendto+0x23a/0x340
     [<ffffffff87554651>] __x64_sys_sendto+0xe1/0x1b0
     [<ffffffff89978b49>] do_syscall_64+0x39/0xb0
     [<ffffffff89a0008b>] entry_SYSCALL_64_after_hwframe+0x63/0xcd
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-401
References: https://git.kernel.org/stable/c/0dfb9a[PII_REDACTED]87c90100ea54d8426cee8c67; https://git.kernel.org/stable/c/176ee6c673ccd118e9392fd2dbb165423bdb99ca; https://git.kernel.org/stable/c/9ed7bfc79542119ac0a9e1ce8a2a5285e43433e9
CVE: CVE-2022-49014
Published: 2024-10-21
Description: In the Linux kernel, the following vulnerability has been resolved:

net: tun: Fix use-after-free in tun_detach()

syzbot reported use-after-free in tun_detach() [1].  This causes call
trace like below:

==================================================================
BUG: KASAN: use-after-free in notifier_call_chain+0x1ee/0x200 kernel/notifier.c:75
Read of size 8 at addr ffff88807324e2a8 by task syz-executor.0/3673

CPU: 0 PID: 3673 Comm: syz-executor.0 Not tainted 6.1.0-rc5-syzkaller-00044-gcc675d22e422 #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 10/26/2022
Call Trace:
 <TASK>
 __dump_stack lib/dump_stack.c:88 [inline]
 dump_stack_lvl+0xd1/0x138 lib/dump_stack.c:106
 print_address_description mm/kasan/report.c:284 [inline]
 print_report+0x15e/0x461 mm/kasan/report.c:395
 kasan_report+0xbf/0x1f0 mm/kasan/report.c:495
 notifier_call_chain+0x1ee/0x200 kernel/notifier.c:75
 call_netdevice_notifiers_info+0x86/0x130 net/core/dev.c:1942
 call_netdevice_notifiers_extack net/core/dev.c:1983 [inline]
 call_netdevice_notifiers net/core/dev.c:1997 [inline]
 netdev_wait_allrefs_any net/core/dev.c:10237 [inline]
 netdev_run_todo+0xbc6/0x1100 net/core/dev.c:10351
 tun_detach drivers/net/tun.c:704 [inline]
 tun_chr_close+0xe4/0x190 drivers/net/tun.c:3467
 __fput+0x27c/0xa90 fs/file_table.c:320
 task_work_run+0x16f/0x270 kernel/task_work.c:179
 exit_task_work include/linux/task_work.h:38 [inline]
 do_exit+0xb3d/0x2a30 kernel/exit.c:820
 do_group_exit+0xd4/0x2a0 kernel/exit.c:950
 get_signal+0x21b1/0x2440 kernel/signal.c:2858
 arch_do_signal_or_restart+0x86/0x2300 arch/x86/kernel/signal.c:869
 exit_to_user_mode_loop kernel/entry/common.c:168 [inline]
 exit_to_user_mode_prepare+0x15f/0x250 kernel/entry/common.c:203
 __syscall_exit_to_user_mode_work kernel/entry/common.c:285 [inline]
 syscall_exit_to_user_mode+0x1d/0x50 kernel/entry/common.c:296
 do_syscall_64+0x46/0xb0 arch/x86/entry/common.c:86
 entry_SYSCALL_64_after_hwframe+0x63/0xcd

The cause of the issue is that sock_put() from __tun_detach() drops
last reference count for struct net, and then notifier_call_chain()
from netdev_state_change() accesses that struct net.

This patch fixes the issue by calling sock_put() from tun_detach()
after all necessary accesses for the struct net has done.
CVSS Score: 7.8 (HIGH)
CWE: CWE-416
References: https://git.kernel.org/stable/c/04b995e[PII_REDACTED]01810dab89dc73e7f12d054; https://git.kernel.org/stable/c/16c244bc65d[PII_REDACTED]ec0489a5a5c830e02c7; https://git.kernel.org/stable/c/1f23f1890d91812c35d32eab1b49621b6d32dc7b
CVE: CVE-2022-49015
Published: 2024-10-21
Description: In the Linux kernel, the following vulnerability has been resolved:

net: hsr: Fix potential use-after-free

The skb is delivered to netif_rx() which may free it, after calling this,
dereferencing skb may trigger use-after-free.
CVSS Score: 7.8 (HIGH)
CWE: CWE-416
References: https://git.kernel.org/stable/c/4b351609af4fdbc23f79ab2b12748f4403ea9af4; https://git.kernel.org/stable/c/53a62c5efe91665f7a41fad0f888a96f94dc59eb; https://git.kernel.org/stable/c/7ca81a161e406834a1fdc405fc83a572bd14b8d9
CVE: CVE-2022-49016
Published: 2024-10-21
Description: In the Linux kernel, the following vulnerability has been resolved:

net: mdiobus: fix unbalanced node reference count

I got the following report while doing device(mscc-miim) load test
with CONFIG_OF_UNITTEST and CONFIG_OF_DYNAMIC enabled:

  OF: ERROR: memory leak, expected refcount 1 instead of 2,
  of_node_get()/of_node_put() unbalanced - destroy cset entry:
  attach overlay node /spi/soc@0/mdio@7107009c/ethernet-phy@0

If the 'fwnode' is not an acpi node, the refcount is get in
fwnode_mdiobus_phy_device_register(), but it has never been
put when the device is freed in the normal path. So call
fwnode_handle_put() in phy_device_release() to avoid leak.

If it's an acpi node, it has never been get, but it's put
in the error path, so call fwnode_handle_get() before
phy_device_register() to keep get/put operation balanced.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-401
References: https://git.kernel.org/stable/c/2708b357440427d6a9fee667eb7b8307f4625adc; https://git.kernel.org/stable/c/543d917f691ab06885ee779c862065899eaa4251; https://git.kernel.org/stable/c/cdde1560118f82498fc9e9a7c1ef7f0ef7755891
CVE: CVE-2022-49017
Published: 2024-10-21
Description: In the Linux kernel, the following vulnerability has been resolved:

tipc: re-fetch skb cb after tipc_msg_validate

As the call trace shows, the original skb was freed in tipc_msg_validate(),
and dereferencing the old skb cb would cause an use-after-free crash.

  BUG: KASAN: use-after-free in tipc_crypto_rcv_complete+0x1835/0x2240 [tipc]
  Call Trace:
   <IRQ>
   tipc_crypto_rcv_complete+0x1835/0x2240 [tipc]
   tipc_crypto_rcv+0xd32/0x1ec0 [tipc]
   tipc_rcv+0x744/0x1150 [tipc]
  ...
  Allocated by task 47078:
   kmem_cache_alloc_node+0x158/0x4d0
   __alloc_skb+0x1c1/0x270
   tipc_buf_acquire+0x1e/0xe0 [tipc]
   tipc_msg_create+0x33/0x1c0 [tipc]
   tipc_link_build_proto_msg+0x38a/0x2100 [tipc]
   tipc_link_timeout+0x8b8/0xef0 [tipc]
   tipc_node_timeout+0x2a1/0x960 [tipc]
   call_timer_fn+0x2d/0x1c0
  ...
  Freed by task 47078:
   tipc_msg_validate+0x7b/0x440 [tipc]
   tipc_crypto_rcv_complete+0x4b5/0x2240 [tipc]
   tipc_crypto_rcv+0xd32/0x1ec0 [tipc]
   tipc_rcv+0x744/0x1150 [tipc]

This patch fixes it by re-fetching the skb cb from the new allocated skb
after calling tipc_msg_validate().
CVSS Score: 7.8 (HIGH)
CWE: CWE-416
References: https://git.kernel.org/stable/c/1daec0815655e110c6f206c5e777a4af8168ff58; https://git.kernel.org/stable/c/3067bc61fcfe3081bf4807ce65560f499e895e77; https://git.kernel.org/stable/c/a1ba595e35aa3afbe417ff0af353afb9f65559c0