huzaifas-sidhpurwala/security-commit huggingface dataset:
CVE-2022-49788: kernel: misc/vmw_vmci: fix an infoleak in vmci_host_do_receive_datagram()
Component: kernel
Severity: Moderate
CWE: CWE-401 (Missing Release of Memory after Effective Lifetime)
CVSS v3: 7.1 (CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:H)
Public date: 2025-05-01T00:00:00+00:00

In the Linux kernel, the following vulnerability has been resolved:

misc/vmw_vmci: fix an infoleak in vmci_host_do_receive_datagram()

`struct vmci_event_qp` allocated by qp_notify_peer() contains padding,
which may carry uninitialized data to the userspace, as observed by
KMSAN:

  BUG: KMSAN: kernel-infoleak in instrument_copy_to_user ./include/linux/instrumented.h:121
   instrument_copy_to_user ./include/linux/instrumented.h:121
   _copy_to_user+0x5f/0xb0 lib/usercopy.c:33
   copy_to_user ./include/linux/uaccess.h:169
   vmci_host_do_receive_datagram drivers/misc/vmw_vmci/vmci_host.c:431
   vmci_host_unlocked_ioctl+0x33d/0x43d0 drivers/misc/vmw_vmci/vmci_host.c:925
   vfs_ioctl fs/ioctl.c:51
  ...

  Uninit was stored to memory at:
   kmemdup+0x74/0xb0 mm/util.c:131
   dg_dispatch_as_host drivers/misc/vmw_vmci/vmci_datagram.c:271
   vmci_datagram_dispatch+0x4f8/0xfc0 drivers/misc/vmw_vmci/vmci_datagram.c:339
   qp_notify_peer+0x19a/0x290 drivers/misc/vmw_vmci/vmci_queue_pair.c:1479
   qp_broker_attach drivers/misc/vmw_vmci/vmci_queue_pair.c:1662
   qp_broker_alloc+0x2977/0x2f30 drivers/misc/vmw_vmci/vmci_queue_pair.c:1750
   vmci_qp_broker_alloc+0x96/0xd0 drivers/misc/vmw_vmci/vmci_queue_pair.c:1940
   vmci_host_do_alloc_queuepair drivers/misc/vmw_vmci/vmci_host.c:488
   vmci_host_unlocked_ioctl+0x24fd/0x43d0 drivers/misc/vmw_vmci/vmci_host.c:927
  ...

  Local variable ev created at:
   qp_notify_peer+0x54/0x290 drivers/misc/vmw_vmci/vmci_queue_pair.c:1456
   qp_broker_attach drivers/misc/vmw_vmci/vmci_queue_pair.c:1662
   qp_broker_alloc+0x2977/0x2f30 drivers/misc/vmw_vmci/vmci_queue_pair.c:1750

  Bytes 28-31 of 48 are uninitialized
  Memory access of size 48 starts at ffff888035155e00
  Data copied to user address 0000000020000100

Use memset() to prevent the infoleaks.

Also speculatively fix qp_notify_peer_local(), which may suffer from the
same problem.


Affected upstream versions: 3.9
Fixed upstream versions: 0, 4.14.300, 4.19.267, 4.9.334, 5.10.156, 5.15.80, 5.4.225, 6.0.10, 6.1
Upstream repository: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
Upstream fix commit: 7ccf7229b96fadc3a185d1391f814a604c7ef609
CVE-2022-49804: kernel: s390: avoid using global register for current_stack_pointer
Component: kernel
Severity: Moderate
CVSS v3: 5.5 (CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H)
Public date: 2025-05-01T00:00:00+00:00

In the Linux kernel, the following vulnerability has been resolved:

s390: avoid using global register for current_stack_pointer

Commit 30de14b1884b ("s390: current_stack_pointer shouldn't be a
function") made current_stack_pointer a global register variable like
on many other architectures. Unfortunately on s390 it uncovers old
gcc bug which is fixed only since gcc-9.1 [gcc commit 3ad7fed1cc87
("S/390: Fix PR89775. Stackpointer save/restore instructions removed")]
and backported to gcc-8.4 and later. Due to this bug gcc versions prior
to 8.4 generate broken code which leads to stack corruptions.

Current minimal gcc version required to build the kernel is declared
as 5.1. It is not possible to fix all old gcc versions, so work
around this problem by avoiding using global register variable for
current_stack_pointer.


Affected upstream versions: 5.18
Fixed upstream versions: 0, 6.0.10, 6.1
Upstream repository: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
Upstream fix commit: a478952a8ac44e32316dc046a063a7dc34825aa6
CVE-2022-49815: kernel: erofs: fix missing xas_retry() in fscache mode
Component: kernel
Severity: Moderate
CVSS v3: 5.5 (CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H)
Public date: 2025-05-01T00:00:00+00:00

In the Linux kernel, the following vulnerability has been resolved:

erofs: fix missing xas_retry() in fscache mode

The xarray iteration only holds the RCU read lock and thus may encounter
XA_RETRY_ENTRY if there's process modifying the xarray concurrently.
This will cause oops when referring to the invalid entry.

Fix this by adding the missing xas_retry(), which will make the
iteration wind back to the root node if XA_RETRY_ENTRY is encountered.


Affected upstream versions: 5.19
Fixed upstream versions: 0, 6.0.10, 6.1
Upstream repository: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
Upstream fix commit: dbc98fe99e17ed18f2f272d5fe880d844b1c68c3
CVE-2022-49827: kernel: drm: Fix potential null-ptr-deref in drm_vblank_destroy_worker()
Component: kernel
Severity: Moderate
CWE: CWE-476 (NULL Pointer Dereference)
CVSS v3: 5.5 (CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H)
Public date: 2025-05-01T00:00:00+00:00

A flaw was found in the DRM subsystem in the Linux kernel. A NULL pointer dereference can be triggered due to a missing check, causing a system crash and resulting in a denial of service.

Statement: This issue has been fixed in Red Hat Enterprise Linux 8.9 and 9.3 via RHSA-2023:7077 [1] and RHSA-2023:6583 [2], respectively.

[1]. https://access.redhat.com/errata/RHSA-2023:7077

[2]. https://access.redhat.com/errata/RHSA-2023:6583

Affected upstream versions: 5.9
Fixed upstream versions: 0, 5.10.156, 5.15.80, 6.0.10, 6.1
Upstream repository: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
Upstream fix commit: 1d160dfb3fdf11ba9447e862c548447f91f4e74a
CVE-2022-49845: kernel: can: j1939: j1939_send_one(): fix missing CAN header initialization
Component: kernel
Severity: Moderate
CWE: CWE-908 (Use of Uninitialized Resource)
CVSS v3: 5.5 (CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H)
Public date: 2025-05-01T00:00:00+00:00

In the Linux kernel, the following vulnerability has been resolved:

can: j1939: j1939_send_one(): fix missing CAN header initialization

The read access to struct canxl_frame::len inside of a j1939 created
skbuff revealed a missing initialization of reserved and later filled
elements in struct can_frame.

This patch initializes the 8 byte CAN header with zero.


Affected upstream versions: 5.4
Fixed upstream versions: 0, 5.10.155, 5.15.79, 5.4.225, 6.0.9, 6.1
Upstream repository: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
Upstream fix commit: d0513b095e1ef1469718564dec3fb3348556d0a8
CVE-2022-49848: kernel: phy: qcom-qmp-combo: fix NULL-deref on runtime resume
Component: kernel
Severity: Low
CWE: CWE-476 (NULL Pointer Dereference)
CVSS v3: 5.5 (CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H)
Public date: 2025-05-01T00:00:00+00:00

In the Linux kernel, the following vulnerability has been resolved:

phy: qcom-qmp-combo: fix NULL-deref on runtime resume

Commit fc64623637da ("phy: qcom-qmp-combo,usb: add support for separate
PCS_USB region") started treating the PCS_USB registers as potentially
separate from the PCS registers but used the wrong base when no PCS_USB
offset has been provided.

Fix the PCS_USB base used at runtime resume to prevent dereferencing a
NULL pointer on platforms that do not provide a PCS_USB offset (e.g.
SC7180).


Affected upstream versions: 6.0
Fixed upstream versions: 0, 6.0.9, 6.1
Upstream repository: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
Upstream fix commit: c559a8b5cfa3db196ced0257b288f17027621348
CVE-2022-49853: kernel: net: macvlan: fix memory leaks of macvlan_common_newlink
Component: kernel
Severity: Moderate
CWE: CWE-401 (Missing Release of Memory after Effective Lifetime)
CVSS v3: 5.5 (CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H)
Public date: 2025-05-01T00:00:00+00:00

In the Linux kernel, the following vulnerability has been resolved:

net: macvlan: fix memory leaks of macvlan_common_newlink

kmemleak reports memory leaks in macvlan_common_newlink, as follows:

 ip link add link eth0 name .. type macvlan mode source macaddr add
 <MAC-ADDR>

kmemleak reports:

unreferenced object 0xffff8880109bb140 (size 64):
  comm "ip", pid 284, jiffies 4294986150 (age 430.108s)
  hex dump (first 32 bytes):
    00 00 00 00 00 00 00 00 b8 aa 5a 12 80 88 ff ff  ..........Z.....
    80 1b fa 0d 80 88 ff ff 1e ff ac af c7 c1 6b 6b  ..............kk
  backtrace:
    [<ffffffff813e06a7>] kmem_cache_alloc_trace+0x1c7/0x300
    [<ffffffff81b66025>] macvlan_hash_add_source+0x45/0xc0
    [<ffffffff81b66a67>] macvlan_changelink_sources+0xd7/0x170
    [<ffffffff81b6775c>] macvlan_common_newlink+0x38c/0x5a0
    [<ffffffff81b6797e>] macvlan_newlink+0xe/0x20
    [<ffffffff81d97f8f>] __rtnl_newlink+0x7af/0xa50
    [<ffffffff81d98278>] rtnl_newlink+0x48/0x70
    ...

In the scenario where the macvlan mode is configured as 'source',
macvlan_changelink_sources() will be execured to reconfigure list of
remote source mac addresses, at the same time, if register_netdevice()
return an error, the resource generated by macvlan_changelink_sources()
is not cleaned up.

Using this patch, in the case of an error, it will execute
macvlan_flush_sources() to ensure that the resource is cleaned up.


Affected upstream versions: 4.9
Fixed upstream versions: 0, 4.14.300, 4.19.267, 4.9.334, 5.10.155, 5.15.79, 5.4.225, 6.0.9, 6.1
Upstream repository: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
Upstream fix commit: 9f288e338be206713d79b29144c27fca4503c39b
CVE-2022-49860: kernel: dmaengine: ti: k3-udma-glue: fix memory leak when register device fail
Component: kernel
Severity: Moderate
CWE: CWE-401 (Missing Release of Memory after Effective Lifetime)
CVSS v3: 5.5 (CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H)
Public date: 2025-05-01T00:00:00+00:00

In the Linux kernel, the following vulnerability has been resolved:

dmaengine: ti: k3-udma-glue: fix memory leak when register device fail

If device_register() fails, it should call put_device() to give
up reference, the name allocated in dev_set_name() can be freed
in callback function kobject_cleanup().


Affected upstream versions: 5.11
Fixed upstream versions: 0, 5.15.79, 6.0.9, 6.1
Upstream repository: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
Upstream fix commit: 1dd27541aa2b95bde71bddd43d73f9c16d73272c
CVE-2022-49862: kernel: tipc: fix the msg->req tlv len check in tipc_nl_compat_name_table_dump_header
Component: kernel
Severity: Moderate
CWE: CWE-908 (Use of Uninitialized Resource)
CVSS v3: 5.5 (CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H)
Public date: 2025-05-01T00:00:00+00:00

A flaw was found in the tipc module in the Linux kernel. An uninitialized value issue can be triggered due to a missing type cast when comparing the length of data with the size of an object. This issue can potentially cause system instability and result in a denial of service.

Statement: This issue has been fixed in Red Hat Enterprise Linux 8.9 and 9.2 via RHSA-2023:7077 [1] and RHSA-2023:2458 [2], respectively.

[1]. https://access.redhat.com/errata/RHSA-2023:7077

[2]. https://access.redhat.com/errata/RHSA-2023:2458

Affected upstream versions: 4.9.152 < 4.9.334, 4.14.95 < 4.14.300, 4.19.17 < 4.19.267, 4.4.172 < 4.5, 4.20.4 < 4.21, 5.0
Fixed upstream versions: 0, 4.14.300, 4.19.267, 4.21, 4.5, 4.9.334, 5.10.155, 5.15.79, 5.4.225, 6.0.9, 6.1
Upstream repository: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
Upstream fix commit: 082707d3df191bf5bb8801d43e4ce3dea39ca173
CVE-2022-49864: kernel: drm/amdkfd: Fix NULL pointer dereference in svm_migrate_to_ram()
Component: kernel
Severity: Moderate
CWE: CWE-476 (NULL Pointer Dereference)
CVSS v3: 5.5 (CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H)
Public date: 2025-05-01T00:00:00+00:00

A flaw was found in the Linux kernel's AMD Kernel Fusion Driver (AMDKFD). In specific error conditions, an object holding a NULL value is used, causing a NULL pointer dereference and resulting in a denial of service.

Statement: This issue has been fixed in Red Hat Enterprise Linux 8.9 and 9.3 via RHSA-2023:7077 [1] and RHSA-2023:6583 [2], respectively.

[1]. https://access.redhat.com/errata/RHSA-2023:7077

[2]. https://access.redhat.com/errata/RHSA-2023:6583

Affected upstream versions: 5.14
Fixed upstream versions: 0, 5.15.79, 6.0.9, 6.1
Upstream repository: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
Upstream fix commit: 3c1bb6187e566143f15dbf0367ae671584aead5b
CVE-2022-49872: kernel: net: gso: fix panic on frag_list with mixed head alloc types
Component: kernel
Severity: Moderate
CVSS v3: 5.5 (CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H)
Public date: 2025-05-01T00:00:00+00:00

In the Linux kernel, the following vulnerability has been resolved:

net: gso: fix panic on frag_list with mixed head alloc types

Since commit 3dcbdb134f32 ("net: gso: Fix skb_segment splat when
splitting gso_size mangled skb having linear-headed frag_list"), it is
allowed to change gso_size of a GRO packet. However, that commit assumes
that "checking the first list_skb member suffices; i.e if either of the
list_skb members have non head_frag head, then the first one has too".

It turns out this assumption does not hold. We've seen BUG_ON being hit
in skb_segment when skbs on the frag_list had differing head_frag with
the vmxnet3 driver. This happens because __netdev_alloc_skb and
__napi_alloc_skb can return a skb that is page backed or kmalloced
depending on the requested size. As the result, the last small skb in
the GRO packet can be kmalloced.

There are three different locations where this can be fixed:

(1) We could check head_frag in GRO and not allow GROing skbs with
    different head_frag. However, that would lead to performance
    regression on normal forward paths with unmodified gso_size, where
    !head_frag in the last packet is not a problem.

(2) Set a flag in bpf_skb_net_grow and bpf_skb_net_shrink indicating
    that NETIF_F_SG is undesirable. That would need to eat a bit in
    sk_buff. Furthermore, that flag can be unset when all skbs on the
    frag_list are page backed. To retain good performance,
    bpf_skb_net_grow/shrink would have to walk the frag_list.

(3) Walk the frag_list in skb_segment when determining whether
    NETIF_F_SG should be cleared. This of course slows things down.

This patch implements (3). To limit the performance impact in
skb_segment, the list is walked only for skbs with SKB_GSO_DODGY set
that have gso_size changed. Normal paths thus will not hit it.

We could check only the last skb but since we need to walk the whole
list anyway, let's stay on the safe side.


Affected upstream versions: 4.9.194 < 4.9.334, 4.14.145 < 4.14.300, 4.19.74 < 4.19.267, 5.2.16 < 5.3, 5.3
Fixed upstream versions: 0, 4.14.300, 4.19.267, 4.9.334, 5.10.155, 5.15.79, 5.3, 5.4.225, 6.0.9, 6.1
Upstream repository: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
Upstream fix commit: 5876b7f249a1ecbbcc8e35072c3828d6526d1c3a
CVE-2022-49885: kernel: ACPI: APEI: Fix integer overflow in ghes_estatus_pool_init()
Component: kernel
Severity: Moderate
CWE: CWE-190 (Integer Overflow or Wraparound)
CVSS v3: 5.5 (CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H)
Public date: 2025-05-01T00:00:00+00:00

In the Linux kernel, the following vulnerability has been resolved:

ACPI: APEI: Fix integer overflow in ghes_estatus_pool_init()

Change num_ghes from int to unsigned int, preventing an overflow
and causing subsequent vmalloc() to fail.

The overflow happens in ghes_estatus_pool_init() when calculating
len during execution of the statement below as both multiplication
operands here are signed int:

len += (num_ghes * GHES_ESOURCE_PREALLOC_MAX_SIZE);

The following call trace is observed because of this bug:

[    9.317108] swapper/0: vmalloc error: size 18446744071562596352, exceeds total pages, mode:0xcc0(GFP_KERNEL), nodemask=(null),cpuset=/,mems_allowed=0-1
[    9.317131] Call Trace:
[    9.317134]  <TASK>
[    9.317137]  dump_stack_lvl+0x49/0x5f
[    9.317145]  dump_stack+0x10/0x12
[    9.317146]  warn_alloc.cold+0x7b/0xdf
[    9.317150]  ? __device_attach+0x16a/0x1b0
[    9.317155]  __vmalloc_node_range+0x702/0x740
[    9.317160]  ? device_add+0x17f/0x920
[    9.317164]  ? dev_set_name+0x53/0x70
[    9.317166]  ? platform_device_add+0xf9/0x240
[    9.317168]  __vmalloc_node+0x49/0x50
[    9.317170]  ? ghes_estatus_pool_init+0x43/0xa0
[    9.317176]  vmalloc+0x21/0x30
[    9.317177]  ghes_estatus_pool_init+0x43/0xa0
[    9.317179]  acpi_hest_init+0x129/0x19c
[    9.317185]  acpi_init+0x434/0x4a4
[    9.317188]  ? acpi_sleep_proc_init+0x2a/0x2a
[    9.317190]  do_one_initcall+0x48/0x200
[    9.317195]  kernel_init_freeable+0x221/0x284
[    9.317200]  ? rest_init+0xe0/0xe0
[    9.317204]  kernel_init+0x1a/0x130
[    9.317205]  ret_from_fork+0x22/0x30
[    9.317208]  </TASK>

[ rjw: Subject and changelog edits ]

Statement: Red Hat has stack protection mechanisms in place, such as FORTIFY_SOURCE, Position Independent Executables or Stack Smashing Protection.

Affected upstream versions: 5.1
Fixed upstream versions: 0, 5.10.154, 5.15.78, 6.0.8, 6.1
Upstream repository: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
Upstream fix commit: 9edf20e5a1d805855e78f241cf221d741b50d482
CVE-2022-49890: kernel: capabilities: fix potential memleak on error path from vfs_getxattr_alloc()
Component: kernel
Severity: Moderate
CWE: CWE-401 (Missing Release of Memory after Effective Lifetime)
CVSS v3: 5.5 (CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H)
Public date: 2025-05-01T00:00:00+00:00

A flaw was found in the capabilities subsystem in the Linux kernel. When memory is allocated for a temporary buffer and a subsequent function call fails, the allocated memory is not released, resulting in a memory leak. This issue could impact system performance and result in a denial of service.

Statement: This issue has been fixed in Red Hat Enterprise Linux 8.9 via RHSA-2023:7077 [1].

The capabilities subsystem as shipped in Red Hat Enterprise Linux 9 is not affected by this vulnerability because the vulnerable code is not present.

[1]. https://access.redhat.com/errata/RHSA-2023:7077

Affected upstream versions: 4.14
Fixed upstream versions: 0, 4.14.299, 4.19.265, 5.10.154, 5.15.78, 5.4.224, 6.0.8, 6.1
Upstream repository: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
Upstream fix commit: 6bb00eb21c0fbf18e5d3538c9ff0cf63fd0ace85
CVE-2022-49902: kernel: block: Fix possible memory leak for rq_wb on add_disk failure
Component: kernel
Severity: Low
CWE: CWE-401 (Missing Release of Memory after Effective Lifetime)
CVSS v3: 4.4 (CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:L)
Public date: 2025-05-01T00:00:00+00:00

In the Linux kernel, the following vulnerability has been resolved:

block: Fix possible memory leak for rq_wb on add_disk failure

kmemleak reported memory leaks in device_add_disk():

kmemleak: 3 new suspected memory leaks

unreferenced object 0xffff88800f420800 (size 512):
  comm "modprobe", pid 4275, jiffies 4295639067 (age 223.512s)
  hex dump (first 32 bytes):
    04 00 00 00 08 00 00 00 01 00 00 00 00 00 00 00  ................
    00 e1 f5 05 00 00 00 00 00 00 00 00 00 00 00 00  ................
  backtrace:
    [<00000000d3662699>] kmalloc_trace+0x26/0x60
    [<00000000edc7aadc>] wbt_init+0x50/0x6f0
    [<0000000069601d16>] wbt_enable_default+0x157/0x1c0
    [<0000000028fc393f>] blk_register_queue+0x2a4/0x420
    [<000000007345a042>] device_add_disk+0x6fd/0xe40
    [<0000000060e6aab0>] nbd_dev_add+0x828/0xbf0 [nbd]
    ...

It is because the memory allocated in wbt_enable_default() is not
released in device_add_disk() error path.
Normally, these memory are freed in:

del_gendisk()
  rq_qos_exit()
    rqos->ops->exit(rqos);
      wbt_exit()

So rq_qos_exit() is called to free the rq_wb memory for wbt_init().
However in the error path of device_add_disk(), only
blk_unregister_queue() is called and make rq_wb memory leaked.

Add rq_qos_exit() to the error path to fix it.


Affected upstream versions: 5.15
Fixed upstream versions: 0, 5.15.78, 6.0.8, 6.1
Upstream repository: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
Upstream fix commit: 4e68c5da60cd79950bd56287ae80b39d6261f995
CVE-2022-49903: kernel: ipv6: fix WARNING in ip6_route_net_exit_late()
Component: kernel
Severity: Moderate
CVSS v3: 5.5 (CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H)
Public date: 2025-05-01T00:00:00+00:00

In the Linux kernel, the following vulnerability has been resolved:

ipv6: fix WARNING in ip6_route_net_exit_late()

During the initialization of ip6_route_net_init_late(), if file
ipv6_route or rt6_stats fails to be created, the initialization is
successful by default. Therefore, the ipv6_route or rt6_stats file
doesn't be found during the remove in ip6_route_net_exit_late(). It
will cause WRNING.

The following is the stack information:
name 'rt6_stats'
WARNING: CPU: 0 PID: 9 at fs/proc/generic.c:712 remove_proc_entry+0x389/0x460
Modules linked in:
Workqueue: netns cleanup_net
RIP: 0010:remove_proc_entry+0x389/0x460
PKRU: 55555554
Call Trace:
<TASK>
ops_exit_list+0xb0/0x170
cleanup_net+0x4ea/0xb00
process_one_work+0x9bf/0x1710
worker_thread+0x665/0x1080
kthread+0x2e4/0x3a0
ret_from_fork+0x1f/0x30
</TASK>


Affected upstream versions: 2.6.26
Fixed upstream versions: 0, 4.19.265, 5.10.154, 5.15.78, 5.4.224, 6.0.8, 6.1
Upstream repository: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
Upstream fix commit: 83fbf246ced54dadd7b9adc2a16efeff30ba944d
CVE-2022-49908: kernel: Bluetooth: L2CAP: Fix memory leak in vhci_write
Component: kernel
Severity: Moderate
CWE: CWE-401 (Missing Release of Memory after Effective Lifetime)
CVSS v3: 5.5 (CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H)
Public date: 2025-05-01T00:00:00+00:00

In the Linux kernel, the following vulnerability has been resolved:

Bluetooth: L2CAP: Fix memory leak in vhci_write

Syzkaller reports a memory leak as follows:
====================================
BUG: memory leak
unreferenced object 0xffff88810d81ac00 (size 240):
  [...]
  hex dump (first 32 bytes):
    00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
    00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
  backtrace:
    [<ffffffff838733d9>] __alloc_skb+0x1f9/0x270 net/core/skbuff.c:418
    [<ffffffff833f742f>] alloc_skb include/linux/skbuff.h:1257 [inline]
    [<ffffffff833f742f>] bt_skb_alloc include/net/bluetooth/bluetooth.h:469 [inline]
    [<ffffffff833f742f>] vhci_get_user drivers/bluetooth/hci_vhci.c:391 [inline]
    [<ffffffff833f742f>] vhci_write+0x5f/0x230 drivers/bluetooth/hci_vhci.c:511
    [<ffffffff815e398d>] call_write_iter include/linux/fs.h:2192 [inline]
    [<ffffffff815e398d>] new_sync_write fs/read_write.c:491 [inline]
    [<ffffffff815e398d>] vfs_write+0x42d/0x540 fs/read_write.c:578
    [<ffffffff815e3cdd>] ksys_write+0x9d/0x160 fs/read_write.c:631
    [<ffffffff845e0645>] do_syscall_x64 arch/x86/entry/common.c:50 [inline]
    [<ffffffff845e0645>] do_syscall_64+0x35/0xb0 arch/x86/entry/common.c:80
    [<ffffffff84600087>] entry_SYSCALL_64_after_hwframe+0x63/0xcd
====================================

HCI core will uses hci_rx_work() to process frame, which is queued to
the hdev->rx_q tail in hci_recv_frame() by HCI driver.

Yet the problem is that, HCI core may not free the skb after handling
ACL data packets. To be more specific, when start fragment does not
contain the L2CAP length, HCI core just copies skb into conn->rx_skb and
finishes frame process in l2cap_recv_acldata(), without freeing the skb,
which triggers the above memory leak.

This patch solves it by releasing the relative skb, after processing
the above case in l2cap_recv_acldata().


Affected upstream versions: 5.12
Fixed upstream versions: 0, 5.15.78, 6.0.8, 6.1
Upstream repository: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
Upstream fix commit: aa16cac06b752e5f609c106735bd7838f444784c