nilfs2: fix kernel-infoleak in nilfs_ioctl_wrap_copy()
In the Linux kernel, the following vulnerability has been resolved:
nilfs2: fix kernel-infoleak in nilfs_ioctl_wrap_copy()
The ioctl helper function nilfs_ioctl_wrap_copy(), which exchanges a
metadata array to/from user space, may copy uninitialized buffer regions
to user space memory for read-only ioctl commands NILFS_IOCTL_GET_SUINFO
and NILFS_IOCTL_GET_CPINFO.
This can occur when the element size of the user space metadata given by
the v_size member of the argument nilfs_argv structure is larger than the
size of the metadata element (nilfs_suinfo structure or nilfs_cpinfo
structure) on the file system side.
KMSAN-enabled kernels detect
codel: remove sch->q.qlen check before qdisc_tree_reduce_backlog()
In the Linux kernel, the following vulnerability has been resolved:
codel: remove sch->q.qlen check before qdisc_tree_reduce_backlog()
After making all ->qlen_notify() callbacks idempotent, now it is safe to
remove the check of qlen!=0 from both fq_codel_dequeue() and
codel_qdisc_dequeue().
In the Linux kernel, the following vulnerability has been resolved:
nfs4: Fix kmemleak when allocate slot failed
If one of the slot allocate failed, should cleanup all the other
allocated slots, otherwise, the allocated slots will leak:
unreferenced object 0xffff8881115aa100 (size 64):
comm ""mount.nfs"", pid 679, jiffies 4294744957 (age 115.037s)
hex dump (first 32 bytes):
00 cc 19 73 81 88 ff ff 00 a0 5a 11 81 88 ff ff ...s......Z.....
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
backtrace:
[<000000007a4c434a>] nfs4_find_or_create_slot+0x8e/0x130
[<000000005472a39c>] nfs4_reallo
RDMA/core: Fix null-ptr-deref in ib_core_cleanup()
In the Linux kernel, the following vulnerability has been resolved:
RDMA/core: Fix null-ptr-deref in ib_core_cleanup()
KASAN reported a null-ptr-deref error:
KASAN: null-ptr-deref in range [0x0000000000000118-0x000000000000011f]
CPU: 1 PID: 379
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996)
RIP: 0010:destroy_workqueue+0x2f/0x740
RSP: 0018:ffff888016137df8 EFLAGS: 00000202
...
Call Trace:
ib_core_cleanup+0xa/0xa1 [ib_core]
__do_sys_delete_module.constprop.0+0x34f/0x5b0
do_syscall_64+0x3a/0x90
entry_SYSCALL_64_after_hwframe+0x63/0xcd
RIP: 0033:0x7fa1a0d221b7
...
It is because the fail of roce_gid_mgmt_in
nfc: fdp: Fix potential memory leak in fdp_nci_send()
In the Linux kernel, the following vulnerability has been resolved:
nfc: fdp: Fix potential memory leak in fdp_nci_send()
fdp_nci_send() will call fdp_nci_i2c_write that will not free skb in
the function. As a result, when fdp_nci_i2c_write() finished, the skb
will memleak. fdp_nci_send() should free skb after fdp_nci_i2c_write()
finished.
nfc: nxp-nci: Fix potential memory leak in nxp_nci_send()
In the Linux kernel, the following vulnerability has been resolved:
nfc: nxp-nci: Fix potential memory leak in nxp_nci_send()
nxp_nci_send() will call nxp_nci_i2c_write(), and only free skb when
nxp_nci_i2c_write() failed. However, even if the nxp_nci_i2c_write()
run succeeds, the skb will not be freed in nxp_nci_i2c_write(). As the
result, the skb will memleak. nxp_nci_send() should also free the skb
when nxp_nci_i2c_write() succeeds.
nfc: nfcmrvl: Fix potential memory leak in nfcmrvl_i2c_nci_send()
In the Linux kernel, the following vulnerability has been resolved:
nfc: nfcmrvl: Fix potential memory leak in nfcmrvl_i2c_nci_send()
nfcmrvl_i2c_nci_send() will be called by nfcmrvl_nci_send(), and skb
should be freed in nfcmrvl_i2c_nci_send(). However, nfcmrvl_nci_send()
will only free skb when i2c_master_send() return >=0, which means skb
will memleak when i2c_master_send() failed. Free skb no matter whether
i2c_master_send() succeeds.
In the Linux kernel, the following vulnerability has been resolved:
net: sched: Fix use after free in red_enqueue()
We can't use "skb" again after passing it to qdisc_enqueue(). This is
basically identical to commit 2f09707d0c97 ("sch_sfb: Also store skb
len before calling child enqueue").
In the Linux kernel, the following vulnerability has been resolved:
ipvs: fix WARNING in __ip_vs_cleanup_batch()
During the initialization of ip_vs_conn_net_init(), if file ip_vs_conn
or ip_vs_conn_sync fails to be created, the initialization is successful
by default. Therefore, the ip_vs_conn or ip_vs_conn_sync file doesn't
be found during the remove.
The following is the stack information:
name 'ip_vs_conn_sync'
WARNING: CPU: 3 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
Call Trace:
<TASK>
__ip_vs_cleanup_batch+0x7d/0x120
ops_exit_li
In the Linux kernel, the following vulnerability has been resolved:
ipvs: fix WARNING in ip_vs_app_net_cleanup()
During the initialization of ip_vs_app_net_init(), if file ip_vs_app
fails to be created, the initialization is successful by default.
Therefore, the ip_vs_app file doesn't be found during the remove in
ip_vs_app_net_cleanup(). It will cause WRNING.
The following is the stack information:
name 'ip_vs_app'
WARNING: CPU: 1 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
Call Trace:
<TASK>
ops_exit_list+0x125/0x170
cleanup_net+0x4e
mISDN: fix possible memory leak in mISDN_register_device()
In the Linux kernel, the following vulnerability has been resolved:
mISDN: fix possible memory leak in mISDN_register_device()
Afer commit 1fa5ae857bb1 ("driver core: get rid of struct device's
bus_id string array"), the name of device is allocated dynamically,
add put_device() to give up the reference, so that the name can be
freed in kobject_cleanup() when the refcount is 0.
Set device class before put_device() to avoid null release() function
WARN message in device_release().
btrfs: fix inode list leak during backref walking at resolve_indirect_refs()
In the Linux kernel, the following vulnerability has been resolved:
btrfs: fix inode list leak during backref walking at resolve_indirect_refs()
During backref walking, at resolve_indirect_refs(), if we get an error
we jump to the 'out' label and call ulist_free() on the 'parents' ulist,
which frees all the elements in the ulist - however that does not free
any inode lists that may be attached to elements, through the 'aux' field
of a ulist node, so we end up leaking lists if we have any attached to
the unodes.
Fix this by calling free_leaf_list() instead of ulist_free() when we exit
from resolve_indirect_refs(). The static function free_l
btrfs: fix ulist leaks in error paths of qgroup self tests
In the Linux kernel, the following vulnerability has been resolved:
btrfs: fix ulist leaks in error paths of qgroup self tests
In the test_no_shared_qgroup() and test_multiple_refs() qgroup self tests,
if we fail to add the tree ref, remove the extent item or remove the
extent ref, we are returning from the test function without freeing the
"old_roots" ulist that was allocated by the previous calls to
btrfs_find_all_roots(). Fix that by calling ulist_free() before returning.
Bluetooth: L2CAP: Fix use-after-free caused by l2cap_reassemble_sdu
In the Linux kernel, the following vulnerability has been resolved:
Bluetooth: L2CAP: Fix use-after-free caused by l2cap_reassemble_sdu
Fix the race condition between the following two flows that run in
parallel:
1. l2cap_reassemble_sdu -> chan->ops->recv (l2cap_sock_recv_cb) ->
__sock_queue_rcv_skb.
2. bt_sock_recvmsg -> skb_recv_datagram, skb_free_datagram.
An SKB can be queued by the first flow and immediately dequeued and
freed by the second flow, therefore the callers of l2cap_reassemble_sdu
can't use the SKB after that function returns. However, some places
continue accessing struct l2cap_ctrl that resides in the SKB's CB for a
net: mdio: fix undefined behavior in bit shift for __mdiobus_register
In the Linux kernel, the following vulnerability has been resolved:
net: mdio: fix undefined behavior in bit shift for __mdiobus_register
Shifting signed 32-bit value by 31 bits is undefined, so changing
significant bit to unsigned. The UBSAN warning calltrace like below:
UBSAN: shift-out-of-bounds in drivers/net/phy/mdio_bus.c:586:27
left shift of 1 by 31 places cannot be represented in type 'int'
Call Trace:
<TASK>
dump_stack_lvl+0x7d/0xa5
dump_stack+0x15/0x1b
ubsan_epilogue+0xe/0x4e
__ubsan_handle_shift_out_of_bounds+0x1e7/0x20c
__mdiobus_register+0x49d/0x4e0
fixed_mdio_bus_init+0xd8/0x12d
do_one_initcall+0x76/0x430
kernel_init
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 Trac
btrfs: fix tree mod log mishandling of reallocated nodes
In the Linux kernel, the following vulnerability has been resolved:
btrfs: fix tree mod log mishandling of reallocated nodes
We have been seeing the following panic in production
kernel BUG at fs/btrfs/tree-mod-log.c:677!
invalid opcode: 0000 [#1] SMP
RIP: 0010:tree_mod_log_rewind+0x1b4/0x200
RSP: 0000:ffffc9002c02f890 EFLAGS: 00010293
RAX: 0000000000000003 RBX: ffff8882b448c700 RCX: 0000000000000000
RDX: 0000000000008000 RSI: 00000000000000a7 RDI: ffff88877d831c00
RBP: 0000000000000002 R08: 000000000000009f R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000100c40 R12: 0000000000000001
R13: ffff8886c26d6a00 R14:
In the Linux kernel, the following vulnerability has been resolved:
ftrace: Fix use-after-free for dynamic ftrace_ops
KASAN reported a use-after-free with ftrace ops [1]. It was found from
vmcore that perf had registered two ops with the same content
successively, both dynamic. After unregistering the second ops, a
use-after-free occurred.
In ftrace_shutdown(), when the second ops is unregistered, the
FTRACE_UPDATE_CALLS command is not set because there is another enabled
ops with the same content. Also, both ops are dynamic and the ftrace
callback function is ftrace_ops_list_func, so the
FTRACE_UPDATE_TRACE_FUNC command will not be set.