deardaniel/secdata-raw huggingface dataset:
CVE: CVE-2025-22046
Published: 2025-04-16
Description: In the Linux kernel, the following vulnerability has been resolved:

uprobes/x86: Harden uretprobe syscall trampoline check

Jann reported a possible issue when trampoline_check_ip returns
address near the bottom of the address space that is allowed to
call into the syscall if uretprobes are not set up:

   https://lore.kernel.org/bpf/[PII_REDACTED]35.5A6F352985@keescook/T/#m9d416df341b8fbc11737dacbcd29f0054413cbbf

Though the mmap minimum address restrictions will typically prevent
creating mappings there, let's make sure uretprobe syscall checks
for that.
CVSS Score: 5.5 (MEDIUM)
References: https://git.kernel.org/stable/c/b0065d712049c87e1994c6eac00c6a637e39b325; https://git.kernel.org/stable/c/c35771342e47d58ab9433f3be1c3c30f2c5fa4f3; https://git.kernel.org/stable/c/d4e48b8d59fe162938a5004ace698c847e6a3207
CVE: CVE-2025-22047
Published: 2025-04-16
Description: In the Linux kernel, the following vulnerability has been resolved:

x86/microcode/AMD: Fix __apply_microcode_amd()'s return value

When verify_sha256_digest() fails, __apply_microcode_amd() should propagate
the failure by returning false (and not -1 which is promoted to true).
CVSS Score: 5.5 (MEDIUM)
References: https://git.kernel.org/stable/c/31ab12df723543047c3fc19cb8f8c4498ec6267f; https://git.kernel.org/stable/c/763f4d638f71cb[PII_REDACTED]0a46e9f9e84227fd; https://git.kernel.org/stable/c/7f705a45f130a85fbf31c2abdc999c65644c8307
CVE: CVE-2025-22048
Published: 2025-04-16
Description: In the Linux kernel, the following vulnerability has been resolved:

LoongArch: BPF: Don't override subprog's return value

The verifier test `calls: div by 0 in subprog` triggers a panic at the
ld.bu instruction. The ld.bu insn is trying to load byte from memory
address returned by the subprog. The subprog actually set the correct
address at the a5 register (dedicated register for BPF return values).
But at commit 73c359d1d356 ("LoongArch: BPF: Sign-extend return values")
we also sign extended a5 to the a0 register (return value in LoongArch).
For function call insn, we later propagate the a0 register back to a5
register. This is right for native calls but wrong for bpf2bpf calls
which expect zero-extended return value in a5 register. So only move a0
to a5 for native calls (i.e. non-BPF_PSEUDO_CALL).
CVSS Score: 5.5 (MEDIUM)
References: https://git.kernel.org/stable/c/223d565d[PII_REDACTED]091cfbaf3466f2b0e289d3; https://git.kernel.org/stable/c/60f3caff1492e5b8616b9578c4bedb5c0a88ed14; https://git.kernel.org/stable/c/780628a780b622759d9e5adc76d15432144da1a3
CVE: CVE-2025-22049
Published: 2025-04-16
Description: In the Linux kernel, the following vulnerability has been resolved:

LoongArch: Increase ARCH_DMA_MINALIGN up to 16

ARCH_DMA_MINALIGN is 1 by default, but some LoongArch-specific devices
(such as APBDMA) require 16 bytes alignment. When the data buffer length
is too small, the hardware may make an error writing cacheline. Thus, it
is dangerous to allocate a small memory buffer for DMA. It's always safe
to define ARCH_DMA_MINALIGN as L1_CACHE_BYTES but unnecessary (kmalloc()
need small memory objects). Therefore, just increase it to 16.
CVSS Score: 5.5 (MEDIUM)
References: https://git.kernel.org/stable/c/1d0def2d1658666ec1f32c9495df60e7411e3c82; https://git.kernel.org/stable/c/279ec25c2df49fba1cd9488f2ddd045d9cb2112e; https://git.kernel.org/stable/c/4103cfe9dcb88010ae4911d3ff417457d1b6a720
CVE: CVE-2025-22050
Published: 2025-04-16
Description: In the Linux kernel, the following vulnerability has been resolved:

usbnet:fix NPE during rx_complete

Missing usbnet_going_away Check in Critical Path.
The usb_submit_urb function lacks a usbnet_going_away
validation, whereas __usbnet_queue_skb includes this check.

This inconsistency creates a race condition where:
A URB request may succeed, but the corresponding SKB data
fails to be queued.

Subsequent processes:
(e.g., rx_complete → defer_bh → __skb_unlink(skb, list))
attempt to access skb->next, triggering a NULL pointer
dereference (Kernel Panic).
CVSS Score: 4.7 (MEDIUM)
CWE: CWE-476
References: https://git.kernel.org/stable/c/0c30988588b28393e3e8873d5654f910e86391ba; https://git.kernel.org/stable/c/0f10f83acfd619e13c64d6705908dfd792f19544; https://git.kernel.org/stable/c/51de[PII_REDACTED]e3b712e5f091d767babc5dd6df
CVE: CVE-2025-22051
Published: 2025-04-16
Description: In the Linux kernel, the following vulnerability has been resolved:

staging: gpib: Fix Oops after disconnect in agilent usb

If the agilent usb dongle is disconnected subsequent calls to the
driver cause a NULL dereference Oops as the bus_interface
is set to NULL on disconnect.

This problem was introduced by setting usb_dev from the bus_interface
for dev_xxx messages.

Previously bus_interface was checked for NULL only in the functions
directly calling usb_fill_bulk_urb or usb_control_msg.

Check for valid bus_interface on all interface entry points
and return -ENODEV if it is NULL.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-476, CWE-476
References: https://git.kernel.org/stable/c/50ef6e45bec79da4c5a01fad4dc23466ba255099; https://git.kernel.org/stable/c/8491e73a5223acb0a4b4d78c3f8b96aa9c5e774d; https://git.kernel.org/stable/c/e[PII_REDACTED]8f40391a9afc6cc8ea3025e6f692b
CVE: CVE-2025-22052
Published: 2025-04-16
Description: In the Linux kernel, the following vulnerability has been resolved:

staging: gpib: Fix Oops after disconnect in ni_usb

If the usb dongle is disconnected subsequent calls to the
driver cause a NULL dereference Oops as the bus_interface
is set to NULL on disconnect.

This problem was introduced by setting usb_dev from the bus_interface
for dev_xxx messages.

Previously bus_interface was checked for NULL only in the the functions
directly calling usb_fill_bulk_urb or usb_control_msg.

Check for valid bus_interface on all interface entry points
and return -ENODEV if it is NULL.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-476, CWE-476
References: https://git.kernel.org/stable/c/5dc98ba6f7304c188b267ef[PII_REDACTED]38447bf; https://git.kernel.org/stable/c/a239c6e91b665f1837cf57b97fe638ef1baf2e78; https://git.kernel.org/stable/c/b2d8d7959077c5d4b11d0dc6bd2167791fd1c72e
CVE: CVE-2025-22054
Published: 2025-04-16
Description: In the Linux kernel, the following vulnerability has been resolved:

arcnet: Add NULL check in com20020pci_probe()

devm_kasprintf() returns NULL when memory allocation fails. Currently,
com20020pci_probe() does not check for this case, which results in a
NULL pointer dereference.

Add NULL check after devm_kasprintf() to prevent this issue and ensure
no resources are left allocated.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-476, CWE-476
References: https://git.kernel.org/stable/c/661cf5d102949898c931e81fd4e1c773afcdeafa; https://git.kernel.org/stable/c/[PII_REDACTED]04494ea7e58033a97c2d2ab12e05d4; https://git.kernel.org/stable/c/905a34dc1ad9a53a8aaaf8a759ea5dbaaa30418d
CVE: CVE-2025-22055
Published: 2025-04-16
Description: In the Linux kernel, the following vulnerability has been resolved:

net: fix geneve_opt length integer overflow

struct geneve_opt uses 5 bit length for each single option, which
means every vary size option should be smaller than 128 bytes.

However, all current related Netlink policies cannot promise this
length condition and the attacker can exploit a exact 128-byte size
option to *fake* a zero length option and confuse the parsing logic,
further achieve heap out-of-bounds read.

One example crash log is like below:

[    3.905425] ==================================================================
[    3.905925] BUG: KASAN: slab-out-of-bounds in nla_put+0xa9/0xe0
[    3.906255] Read of size 124 at addr ffff888005f291cc by task poc/177
[    3.906646]
[    3.906775] CPU: 0 PID: 177 Comm: poc-oob-read Not tainted 6.1.132 #1
[    3.907131] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.0-0-gd239552ce722-prebuilt.qemu.org 04/01/2014
[    3.907784] Call Trace:
[    3.907925]  <TASK>
[    3.908048]  dump_stack_lvl+0x44/0x5c
[    3.908258]  print_report+0x184/0x4be
[    3.909151]  kasan_report+0xc5/0x100
[    3.909539]  kasan_check_range+0xf3/0x1a0
[    3.909794]  memcpy+0x1f/0x60
[    3.909968]  nla_put+0xa9/0xe0
[    3.910147]  tunnel_key_dump+0x945/0xba0
[    3.911536]  tcf_action_dump_1+0x1c1/0x340
[    3.912436]  tcf_action_dump+0x101/0x180
[    3.912689]  tcf_exts_dump+0x164/0x1e0
[    3.912905]  fw_dump+0x18b/0x2d0
[    3.913483]  tcf_fill_node+0x2ee/0x460
[    3.914778]  tfilter_notify+0xf4/0x180
[    3.915208]  tc_new_tfilter+0xd51/0x10d0
[    3.918615]  rtnetlink_rcv_msg+0x4a2/0x560
[    3.919118]  netlink_rcv_skb+0xcd/0x200
[    3.919787]  netlink_unicast+0x395/0x530
[    3.921032]  netlink_sendmsg+0x3d0/0x6d0
[    3.921987]  __sock_sendmsg+0x99/0xa0
[    3.922220]  __sys_sendto+0x1b7/0x240
[    3.922682]  __x64_sys_sendto+0x72/0x90
[    3.922906]  do_syscall_64+0x5e/0x90
[    3.923814]  entry_SYSCALL_64_after_hwframe+0x6e/0xd8
[    3.924122] RIP: 0033:0x7e83eab84407
[    3.924331] Code: 48 89 fa 4c 89 df e8 38 aa 00 00 8b 93 08 03 00 00 59 5e 48 83 f8 fc 74 1a 5b c3 0f 1f 84 00 00 00 00 00 48 8b 44 24 10 0f 05 <5b> c3 0f 1f 80 00 00 00 00 83 e2 39 83 faf
[    3.925330] RSP: 002b:00007ffff505e370 EFLAGS: 00000202 ORIG_RAX:[PII_REDACTED]00002c
[    3.925752] RAX: ffffffffffffffda RBX: 00007e83eaafa740 RCX: 00007e83eab84407
[    3.926173] RDX:[PII_REDACTED]0001a8 RSI: 00007ffff505e3c0 RDI: [PII_REDACTED]
[    3.926587] RBP: 00007ffff505f460 R08: 00007e83eace1000 R09:[PII_REDACTED]00000c
[    3.926977] R10: [PII_REDACTED] R11: [PII_REDACTED] R12: 00007ffff505f3c0
[    3.927367] R13: 00007ffff505f5c8 R14: 00007e83ead1b000 R15: 00005d4fbbe6dcb8

Fix these issues by enforing correct length condition in related
policies.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-190
References: https://git.kernel.org/stable/c/21748669c5825761cbbf47cbeeb01387ddccc8cb; https://git.kernel.org/stable/c/2952776c69a1a551649ed770bf22e3f691f6ec65; https://git.kernel.org/stable/c/4d606069bdd3c76f8ab1f06796c97ef7f4746807
CVE: CVE-2025-22056
Published: 2025-04-16
Description: In the Linux kernel, the following vulnerability has been resolved:

netfilter: nft_tunnel: fix geneve_opt type confusion addition

When handling multiple NFTA_TUNNEL_KEY_OPTS_GENEVE attributes, the
parsing logic should place every geneve_opt structure one by one
compactly. Hence, when deciding the next geneve_opt position, the
pointer addition should be in units of char *.

However, the current implementation erroneously does type conversion
before the addition, which will lead to heap out-of-bounds write.

[    6.989857] ==================================================================
[    6.990293] BUG: KASAN: slab-out-of-bounds in nft_tunnel_obj_init+0x977/0xa70
[    6.990725] Write of size 124 at addr ffff888005f18974 by task poc/178
[    6.991162]
[    6.991259] CPU: 0 PID: 178 Comm: poc-oob-write Not tainted 6.1.132 #1
[    6.991655] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.0-0-gd239552ce722-prebuilt.qemu.org 04/01/2014
[    6.992281] Call Trace:
[    6.992423]  <TASK>
[    6.992586]  dump_stack_lvl+0x44/0x5c
[    6.992801]  print_report+0x184/0x4be
[    6.993790]  kasan_report+0xc5/0x100
[    6.994252]  kasan_check_range+0xf3/0x1a0
[    6.994486]  memcpy+0x38/0x60
[    6.994692]  nft_tunnel_obj_init+0x977/0xa70
[    6.995677]  nft_obj_init+0x10c/0x1b0
[    6.995891]  nf_tables_newobj+0x585/0x950
[    6.996922]  nfnetlink_rcv_batch+0xdf9/0x1020
[    6.998997]  nfnetlink_rcv+0x1df/0x220
[    6.999537]  netlink_unicast+0x395/0x530
[    7.000771]  netlink_sendmsg+0x3d0/0x6d0
[    7.001462]  __sock_sendmsg+0x99/0xa0
[    7.001707]  ____sys_sendmsg+0x409/0x450
[    7.002391]  ___sys_sendmsg+0xfd/0x170
[    7.003145]  __sys_sendmsg+0xea/0x170
[    7.004359]  do_syscall_64+0x5e/0x90
[    7.005817]  entry_SYSCALL_64_after_hwframe+0x6e/0xd8
[    7.006127] RIP: 0033:0x7ec756d4e407
[    7.006339] Code: 48 89 fa 4c 89 df e8 38 aa 00 00 8b 93 08 03 00 00 59 5e 48 83 f8 fc 74 1a 5b c3 0f 1f 84 00 00 00 00 00 48 8b 44 24 10 0f 05 <5b> c3 0f 1f 80 00 00 00 00 83 e2 39 83 faf
[    7.007364] RSP: 002b:00007ffed5d46760 EFLAGS: 00000202 ORIG_RAX:[PII_REDACTED]00002e
[    7.007827] RAX: ffffffffffffffda RBX: 00007ec756cc4740 RCX: 00007ec756d4e407
[    7.008223] RDX: [PII_REDACTED] RSI: 00007ffed5d467f0 RDI: [PII_REDACTED]
[    7.008620] RBP: 00007ffed5d468a0 R08: [PII_REDACTED] R09: [PII_REDACTED]
[    7.009039] R10: [PII_REDACTED] R11: [PII_REDACTED] R12: [PII_REDACTED]
[    7.009429] R13: 00007ffed5d478b0 R14: 00007ec756ee5000 R15: 00005cbd4e655cb8

Fix this bug with correct pointer addition and conversion in parse
and dump code.
CVSS Score: 7.8 (HIGH)
CWE: CWE-787, CWE-787
References: https://git.kernel.org/stable/c/0a93a710d6df334b828ea064c6d39fda34f901dc; https://git.kernel.org/stable/c/1b755d8eb1ace3870789d48fbd94f386ad6e30be; https://git.kernel.org/stable/c/28d88ee1e1cc8ac2d79aeb112717b97c5c833d43
CVE: CVE-2025-22057
Published: 2025-04-16
Description: In the Linux kernel, the following vulnerability has been resolved:

net: decrease cached dst counters in dst_release

Upstream fix ac888d58869b ("net: do not delay dst_entries_add() in
dst_release()") moved decrementing the dst count from dst_destroy to
dst_release to avoid accessing already freed data in case of netns
dismantle. However in case CONFIG_DST_CACHE is enabled and OvS+tunnels
are used, this fix is incomplete as the same issue will be seen for
cached dsts:

  Unable to handle kernel paging request at virtual address ffff5aabf6b5c000
  Call trace:
   percpu_counter_add_batch+0x3c/0x160 (P)
   dst_release+0xec/0x108
   dst_cache_destroy+0x68/0xd8
   dst_destroy+0x13c/0x168
   dst_destroy_rcu+0x1c/0xb0
   rcu_do_batch+0x18c/0x7d0
   rcu_core+0x174/0x378
   rcu_core_si+0x18/0x30

Fix this by invalidating the cache, and thus decrementing cached dst
counters, in dst_release too.
CVSS Score: 5.5 (MEDIUM)
References: https://git.kernel.org/stable/c/3a0a3ff6593d670af2451ec363ccb7b18aec0c0a; https://git.kernel.org/stable/c/836415a8405c9665ae55352fc5ba865c242f5e4f; https://git.kernel.org/stable/c/92a5c18513117be69bc00419dd1724c1940f8fcd
CVE: CVE-2025-22059
Published: 2025-04-16
Description: In the Linux kernel, the following vulnerability has been resolved:

udp: Fix multiple wraparounds of sk->sk_rmem_alloc.

__udp_enqueue_schedule_skb() has the following condition:

  if (atomic_read(&sk->sk_rmem_alloc) > sk->sk_rcvbuf)
          goto drop;

sk->sk_rcvbuf is initialised by net.core.rmem_default and later can
be configured by SO_RCVBUF, which is limited by net.core.rmem_max,
or SO_RCVBUFFORCE.

If we set INT_MAX to sk->sk_rcvbuf, the condition is always false
as sk->sk_rmem_alloc is also signed int.

Then, the size of the incoming skb is added to sk->sk_rmem_alloc
unconditionally.

This results in integer overflow (possibly multiple times) on
sk->sk_rmem_alloc and allows a single socket to have skb up to
net.core.udp_mem[1].

For example, if we set a large value to udp_mem[1] and INT_MAX to
sk->sk_rcvbuf and flood packets to the socket, we can see multiple
overflows:

  # cat /proc/net/sockstat | grep UDP:
  UDP: inuse 3 mem 7956736  <-- (7956736 << 12) bytes > INT_MAX * 15
                                             ^- PAGE_SHIFT
  # ss -uam
  State  Recv-Q      ...
  UNCONN [PII_REDACTED] ...    <-- flipping the sign repeatedly
         skmem:(r[PII_REDACTED],rb[PII_REDACTED],t0,tb212992,f1984,w0,o0,bl0,d0)

Previously, we had a boundary check for INT_MAX, which was removed by
commit 6a1f12dd85a8 ("udp: relax atomic operation on sk->sk_rmem_alloc").

A complete fix would be to revert it and cap the right operand by
INT_MAX:

  rmem = atomic_add_return(size, &sk->sk_rmem_alloc);
  if (rmem > min(size + (unsigned int)sk->sk_rcvbuf, INT_MAX))
          goto uncharge_drop;

but we do not want to add the expensive atomic_add_return() back just
for the corner case.

Casting rmem to unsigned int prevents multiple wraparounds, but we still
allow a single wraparound.

  # cat /proc/net/sockstat | grep UDP:
  UDP: inuse 3 mem 524288  <-- (INT_MAX + 1) >> 12

  # ss -uam
  State  Recv-Q      ...
  UNCONN [PII_REDACTED] ...   <-- INT_MAX + 831 bytes
         skmem:(r[PII_REDACTED],rb[PII_REDACTED],t0,tb212992,f3264,w0,o0,bl0,d14468947)

So, let's define rmem and rcvbuf as unsigned int and check skb->truesize
only when rcvbuf is large enough to lower the overflow possibility.

Note that we still have a small chance to see overflow if multiple skbs
to the same socket are processed on different core at the same time and
each size does not exceed the limit but the total size does.

Note also that we must ignore skb->truesize for a small buffer as
explained in commit 363dc73acacb ("udp: be less conservative with
sock rmem accounting").
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-190, CWE-190
References: https://git.kernel.org/stable/c/1f529988efe9870db802cb79d01d8f473099b4d7; https://git.kernel.org/stable/c/5a465a0da13ee9fbd7d3cd0b2893309b0fe4b7e3; https://git.kernel.org/stable/c/7571aadd20289e9ea10ebfed0986f39ed8b3c16b
CVE: CVE-2025-22060
Published: 2025-04-16
Description: In the Linux kernel, the following vulnerability has been resolved:

net: mvpp2: Prevent parser TCAM memory corruption

Protect the parser TCAM/SRAM memory, and the cached (shadow) SRAM
information, from concurrent modifications.

Both the TCAM and SRAM tables are indirectly accessed by configuring
an index register that selects the row to read or write to. This means
that operations must be atomic in order to, e.g., avoid spreading
writes across multiple rows. Since the shadow SRAM array is used to
find free rows in the hardware table, it must also be protected in
order to avoid TOCTOU errors where multiple cores allocate the same
row.

This issue was detected in a situation where `mvpp2_set_rx_mode()` ran
concurrently on two CPUs. In this particular case the
MVPP2_PE_MAC_UC_PROMISCUOUS entry was corrupted, causing the
classifier unit to drop all incoming unicast - indicated by the
`rx_classifier_drops` counter.
CVSS Score: 4.7 (MEDIUM)
CWE: CWE-367
References: https://git.kernel.org/stable/c/46c1e23e34c9d1eaadf37f88216d9d8ce0d0bcee; https://git.kernel.org/stable/c/5b0ae1723a7d9574ae1aee7d9cf9757a30069865; https://git.kernel.org/stable/c/[PII_REDACTED]6b49af25a69a1d084b648ec2d9b08d
CVE: CVE-2025-22061
Published: 2025-04-16
Description: In the Linux kernel, the following vulnerability has been resolved:

net: airoha: Fix qid report in airoha_tc_get_htb_get_leaf_queue()

Fix the following kernel warning deleting HTB offloaded leafs and/or root
HTB qdisc in airoha_eth driver properly reporting qid in
airoha_tc_get_htb_get_leaf_queue routine.

$tc qdisc replace dev eth1 root handle 10: htb offload
$tc class add dev eth1 arent 10: classid 10:4 htb rate 100mbit ceil 100mbit
$tc qdisc replace dev eth1 parent 10:4 handle 4: ets bands 8 \
 quanta [PII_REDACTED] 7570 9084 10598 12112
$tc qdisc del dev eth1 root

[   55.827864] ------------[ cut here ]------------
[   55.832493] WARNING: CPU: 3 PID: 2678 at 0xffffffc0798695a4
[   55.956510] CPU: 3 PID: 2678 Comm: tc Tainted: G           O 6.6.71 #0
[   55.963557] Hardware name: Airoha AN7581 Evaluation Board (DT)
[   55.969383] pstate: 20400005 (nzCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)
[   55.976344] pc : 0xffffffc0798695a4
[   55.979851] lr : 0xffffffc079869a20
[   55.983358] sp : ffffffc0850536a0
[   55.986665] x29: ffffffc0850536a0 x28: [PII_REDACTED] x27: [PII_REDACTED]
[   55.993800] x26: [PII_REDACTED] x25: ffffff8008b19000 x24: ffffff800222e800
[   56.000935] x23: [PII_REDACTED] x22: [PII_REDACTED] x21: ffffff8008b19000
[   56.008071] x20: ffffff[PII_REDACTED] x19: ffffff800379d000 x18: [PII_REDACTED]
[   56.015206] x17: ffffffbf9ea59000 x16: ffffffc080018000 x15: [PII_REDACTED]
[   56.022342] x14: [PII_REDACTED] x13: [PII_REDACTED] x12: [PII_REDACTED]
[   56.029478] x11: ffffffc081471008 x10: ffffffc081575a98 x9 : [PII_REDACTED]
[   56.036614] x8 : ffffffc08167fd40 x7 : ffffffc08069e104 x6 : ffffff8007f86000
[   56.043748] x5 : [PII_REDACTED] x4 : [PII_REDACTED] x3 : [PII_REDACTED]
[   56.050884] x2 : [PII_REDACTED] x1 : [PII_REDACTED] x0 : ffffff800222c000
[   56.058020] Call trace:
[   56.060459]  0xffffffc0798695a4
[   56.063618]  0xffffffc079869a20
[   56.066777]  __qdisc_destroy+0x40/0xa0
[   56.070528]  qdisc_put+0x54/0x6c
[   56.073748]  qdisc_graft+0x41c/0x648
[   56.077324]  tc_get_qdisc+0x168/0x2f8
[   56.080978]  rtnetlink_rcv_msg+0x230/0x330
[   56.085076]  netlink_rcv_skb+0x5c/0x128
[   56.088913]  rtnetlink_rcv+0x14/0x1c
[   56.092490]  netlink_unicast+0x1e0/0x2c8
[   56.096413]  netlink_sendmsg+0x198/0x3c8
[   56.100337]  ____sys_sendmsg+0x1c4/0x274
[   56.104261]  ___sys_sendmsg+0x7c/0xc0
[   56.107924]  __sys_sendmsg+0x44/0x98
[   56.111492]  __arm64_sys_sendmsg+0x20/0x28
[   56.115580]  invoke_syscall.constprop.0+0x58/0xfc
[   56.120285]  do_el0_svc+0x3c/0xbc
[   56.123592]  el0_svc+0x18/0x4c
[   56.126647]  el0t_64_sync_handler+0x118/0x124
[   56.131005]  el0t_64_sync+0x150/0x154
[   56.134660] ---[ end trace [PII_REDACTED] ]---
CVSS Score: 5.5 (MEDIUM)
References: https://git.kernel.org/stable/c/57b290d97c6150774bf929117ca737a26d8fc33d; https://git.kernel.org/stable/c/d7f76197e49e46a8c082a6fededaa8a07e69a860
CVE: CVE-2025-22062
Published: 2025-04-16
Description: In the Linux kernel, the following vulnerability has been resolved:

sctp: add mutual exclusion in proc_sctp_do_udp_port()

We must serialize calls to sctp_udp_sock_stop() and sctp_udp_sock_start()
or risk a crash as syzbot reported:

Oops: general protection fault, probably for non-canonical address 0xdffffc000000000d: 0000 [#1] SMP KASAN PTI
KASAN: null-ptr-deref in range [0x[PII_REDACTED]000068-0x[PII_REDACTED]00006f]
CPU: 1 UID: 0 PID: 6551 Comm: syz.1.44 Not tainted 6.14.0-syzkaller-g7f2ff7b62617 #0 PREEMPT(full)
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 02/12/2025
 RIP: 0010:kernel_sock_shutdown+0x47/0x70 net/socket.c:3653
Call Trace:
 <TASK>
  udp_tunnel_sock_release+0x68/0x80 net/ipv4/udp_tunnel_core.c:181
  sctp_udp_sock_stop+0x71/0x160 net/sctp/protocol.c:930
  proc_sctp_do_udp_port+0x264/0x450 net/sctp/sysctl.c:553
  proc_sys_call_handler+0x3d0/0x5b0 fs/proc/proc_sysctl.c:601
  iter_file_splice_write+0x91c/0x1150 fs/splice.c:738
  do_splice_from fs/splice.c:935 [inline]
  direct_splice_actor+0x18f/0x6c0 fs/splice.c:1158
  splice_direct_to_actor+0x342/0xa30 fs/splice.c:1102
  do_splice_direct_actor fs/splice.c:1201 [inline]
  do_splice_direct+0x174/0x240 fs/splice.c:1227
  do_sendfile+0xafd/0xe50 fs/read_write.c:1368
  __do_sys_sendfile64 fs/read_write.c:1429 [inline]
  __se_sys_sendfile64 fs/read_write.c:1415 [inline]
  __x64_sys_sendfile64+0x1d8/0x220 fs/read_write.c:1415
  do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-476
References: https://git.kernel.org/stable/c/10206302af856791fbcc27a33ed3c3eb09b2793d; https://git.kernel.org/stable/c/386507cb6fb7cdef598ddcb3f0fa37e6ca9e789d; https://git.kernel.org/stable/c/65ccb2793da7401772a3ffe85355c831b313c59f
CVE: CVE-2025-22063
Published: 2025-04-16
Description: In the Linux kernel, the following vulnerability has been resolved:

netlabel: Fix NULL pointer exception caused by CALIPSO on IPv4 sockets

When calling netlbl_conn_setattr(), addr->sa_family is used
to determine the function behavior. If sk is an IPv4 socket,
but the connect function is called with an IPv6 address,
the function calipso_sock_setattr() is triggered.
Inside this function, the following code is executed:

sk_fullsock(__sk) ? inet_sk(__sk)->pinet6 : NULL;

Since sk is an IPv4 socket, pinet6 is NULL, leading to a
null pointer dereference.

This patch fixes the issue by checking if inet6_sk(sk)
returns a NULL pointer before accessing pinet6.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-476, CWE-476
References: https://git.kernel.org/stable/c/078aabd567de3d63d37d7673f714e309d369e6e2; https://git.kernel.org/stable/c/172a8a996a[PII_REDACTED]67e871dd995ac07640b1; https://git.kernel.org/stable/c/1927d0bcd5b81e80971bf6b8eba267508bd1c78b