configfs: fix a race in configfs_{,un}register_subsystem()
In the Linux kernel, the following vulnerability has been resolved:
configfs: fix a race in configfs_{,un}register_subsystem()
When configfs_register_subsystem() or configfs_unregister_subsystem()
is executing link_group() or unlink_group(),
it is possible that two processes add or delete list concurrently.
Some unfortunate interleavings of them can cause kernel panic.
One of cases is:
A --> B --> C --> D
A <-- B <-- C <-- D
delete list_head *B | delete list_head *C
--------------------------------|-----------------------------------
configfs_unregister_subsystem | configfs_unregister_subsystem
unlink_group
In the Linux kernel, the following vulnerability has been resolved:
RDMA/ib_srp: Fix a deadlock
Remove the flush_workqueue(system_long_wq) call since flushing
system_long_wq is deadlock-prone and since that call is redundant with a
preceding cancel_work_sync()
iio: adc: men_z188_adc: Fix a resource leak in an error handling path
In the Linux kernel, the following vulnerability has been resolved:
iio: adc: men_z188_adc: Fix a resource leak in an error handling path
If iio_device_register() fails, a previous ioremap() is left unbalanced.
Update the error handling path and add the missing iounmap() call, as
already done in the remove function.
usb: gadget: rndis: add spinlock for rndis response list
In the Linux kernel, the following vulnerability has been resolved:
usb: gadget: rndis: add spinlock for rndis response list
There's no lock for rndis response list. It could cause list corruption
if there're two different list_add at the same time like below.
It's better to add in rndis_add_response / rndis_free_response
/ rndis_get_next_response to prevent any race condition on response list.
[ 361.894299] [1: irq/191-dwc3:16979] list_add corruption.
next->prev should be prev (ffffff80651764d0),
but was ffffff883dc36f80. (next=ffffff80651764d0).
[ 361.904380] [1: irq/191-dwc3:16979] Call trace:
[ 361.904391] [1: irq/191-dwc3:16
thermal: int340x: fix memory leak in int3400_notify()
In the Linux kernel, the following vulnerability has been resolved:
thermal: int340x: fix memory leak in int3400_notify()
It is easy to hit the below memory leaks in my TigerLake platform:
unreferenced object 0xffff927c8b91dbc0 (size 32):
comm "kworker/0:2", pid 112, jiffies 4294893323 (age 83.604s)
hex dump (first 32 bytes):
4e 41 4d 45 3d 49 4e 54 33 34 30 30 20 54 68 65 NAME=INT3400 The
72 6d 61 6c 00 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b a5 rmal.kkkkkkkkkk.
backtrace:
[<ffffffff9c502c3e>] __kmalloc_track_caller+0x2fe/0x4a0
[<ffffffff9c7b7c15>] kvasprintf+0x65/0xd0
[<ffffffff9c7b7d6e>] kasprintf+0x4e/0x70
[<fffff
xen/netfront: destroy queues before real_num_tx_queues is zeroed
In the Linux kernel, the following vulnerability has been resolved:
xen/netfront: destroy queues before real_num_tx_queues is zeroed
xennet_destroy_queues() relies on info->netdev->real_num_tx_queues to
delete queues. Since d7dac083414eb5bb99a6d2ed53dc2c1b405224e5
("net-sysfs: update the queue counts in the unregistration path"),
unregister_netdev() indirectly sets real_num_tx_queues to 0. Those two
facts together means, that xennet_destroy_queues() called from
xennet_remove() cannot do its job, because it's called after
unregister_netdev(). This results in kfree-ing queues that are still
linked in napi, which ultimately crashes:
BUG:
netfilter: fix use-after-free in __nf_register_net_hook()
In the Linux kernel, the following vulnerability has been resolved:
netfilter: fix use-after-free in __nf_register_net_hook()
We must not dereference @new_hooks after nf_hook_mutex has been released,
because other threads might have freed our allocated hooks already.
BUG: KASAN: use-after-free in nf_hook_entries_get_hook_ops include/linux/netfilter.h:130 [inline]
BUG: KASAN: use-after-free in hooks_validate net/netfilter/core.c:171 [inline]
BUG: KASAN: use-after-free in __nf_register_net_hook+0x77a/0x820 net/netfilter/core.c:438
Read of size 2 at addr ffff88801c1a8000 by task syz-executor237/4430
CPU: 1 PID: 4430 Comm: syz-executor237 Not
In the Linux kernel, the following vulnerability has been resolved:
netfilter: nf_queue: fix possible use-after-free
Eric Dumazet says:
The sock_hold() side seems suspect, because there is no guarantee
that sk_refcnt is not already 0.
On failure, we cannot queue the packet and need to indicate an
error. The packet will be dropped by the caller.
v2: split skb prefetch hunk into separate change
net: ipv6: ensure we call ipv6_mc_down() at most once
In the Linux kernel, the following vulnerability has been resolved:
net: ipv6: ensure we call ipv6_mc_down() at most once
There are two reasons for addrconf_notify() to be called with NETDEV_DOWN:
either the network device is actually going down, or IPv6 was disabled
on the interface.
If either of them stays down while the other is toggled, we repeatedly
call the code for NETDEV_DOWN, including ipv6_mc_down(), while never
calling the corresponding ipv6_mc_up() in between. This will cause a
new entry in idev->mc_tomb to be allocated for each multicast group
the interface is subscribed to, which in turn leaks one struct ifmcaddr6
per nontriv
net: arcnet: com20020: Fix null-ptr-deref in com20020pci_probe()
In the Linux kernel, the following vulnerability has been resolved:
net: arcnet: com20020: Fix null-ptr-deref in com20020pci_probe()
During driver initialization, the pointer of card info, i.e. the
variable 'ci' is required. However, the definition of
'com20020pci_id_table' reveals that this field is empty for some
devices, which will cause null pointer dereference when initializing
these devices.
The following log reveals it:
[ 3.973806] KASAN: null-ptr-deref in range [0x0000000000000028-0x000000000000002f]
[ 3.973819] RIP: 0010:com20020pci_probe+0x18d/0x13e0 [com20020_pci]
[ 3.975181] Call Trace:
[ 3.976208] local_pci_probe
In the Linux kernel, the following vulnerability has been resolved:
ibmvnic: free reset-work-item when flushing
Fix a tiny memory leak when flushing the reset work queue.
spi: spi-zynq-qspi: Fix a NULL pointer dereference in zynq_qspi_exec_mem_op()
In the Linux kernel, the following vulnerability has been resolved:
spi: spi-zynq-qspi: Fix a NULL pointer dereference in zynq_qspi_exec_mem_op()
In zynq_qspi_exec_mem_op(), kzalloc() is directly used in memset(),
which could lead to a NULL pointer dereference on failure of
kzalloc().
Fix this bug by adding a check of tmpbuf.
This bug was found by a static analyzer. The analysis employs
differential checking to identify inconsistent security operations
(e.g., checks or kfrees) between two code paths and confirms that the
inconsistent operations are not recovered in the current function or
the callers, so they constitute bugs.
Note that,
nfc: pn533: Wait for out_urb's completion in pn533_usb_send_frame()
In the Linux kernel, the following vulnerability has been resolved:
nfc: pn533: Wait for out_urb's completion in pn533_usb_send_frame()
Fix a use-after-free that occurs in hcd when in_urb sent from
pn533_usb_send_frame() is completed earlier than out_urb. Its callback
frees the skb data in pn533_send_async_complete() that is used as a
transfer buffer of out_urb. Wait before sending in_urb until the
callback of out_urb is called. To modify the callback of out_urb alone,
separate the complete function of out_urb and ack_urb.
Found by a modified version of syzkaller.
BUG: KASAN: use-after-free in dummy_timer
Call Trace:
memcpy (mm/kasan/sha
net/sched: act_mpls: Fix warning during failed attribute validation
In the Linux kernel, the following vulnerability has been resolved:
net/sched: act_mpls: Fix warning during failed attribute validation
The 'TCA_MPLS_LABEL' attribute is of 'NLA_U32' type, but has a
validation type of 'NLA_VALIDATE_FUNCTION'. This is an invalid
combination according to the comment above 'struct nla_policy':
"
Meaning of `validate' field, use via NLA_POLICY_VALIDATE_FN:
NLA_BINARY Validation function called for the attribute.
All other Unused - but note that it's a union
"
This can trigger the warning [1] in nla_get_range_unsigned() when
validation of the attribute fails. Despite being of 'NLA_U3
usb: xhci: Check endpoint is valid before dereferencing it
In the Linux kernel, the following vulnerability has been resolved:
usb: xhci: Check endpoint is valid before dereferencing it
When the host controller is not responding, all URBs queued to all
endpoints need to be killed. This can cause a kernel panic if we
dereference an invalid endpoint.
Fix this by using xhci_get_virt_ep() helper to find the endpoint and
checking if the endpoint is valid before dereferencing it.
[233311.853271] xhci-hcd xhci-hcd.1.auto: xHCI host controller not responding, assume dead
[233311.853393] Unable to handle kernel NULL pointer dereference at virtual address 00000000000000e8
[233311.853964] pc : xhci_hc_died
nilfs2: fix general protection fault in nilfs_btree_insert()
In the Linux kernel, the following vulnerability has been resolved:
nilfs2: fix general protection fault in nilfs_btree_insert()
If nilfs2 reads a corrupted disk image and tries to reads a b-tree node
block by calling __nilfs_btree_get_block() against an invalid virtual
block address, it returns -ENOENT because conversion of the virtual block
address to a disk block address fails. However, this return value is the
same as the internal code that b-tree lookup routines return to indicate
that the block being searched does not exist, so functions that operate on
that b-tree may misbehave.
When nilfs_btree_insert() receives this spurious 'not
Add exception protection processing for vd in axi_chan_handle_err function
In the Linux kernel, the following vulnerability has been resolved:
Add exception protection processing for vd in axi_chan_handle_err function
Since there is no protection for vd, a kernel panic will be
triggered here in exceptional cases.
You can refer to the processing of axi_chan_block_xfer_complete function
The triggered kernel panic is as follows:
[ 67.848444] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000060
[ 67.848447] Mem abort info:
[ 67.848449] ESR = 0x96000004
[ 67.848451] EC = 0x25: DABT (current EL), IL = 32 bits
[ 67.848454] SET = 0, FnV = 0
[ 67.848456] EA = 0, S1PTW
In the Linux kernel, the following vulnerability has been resolved:
xhci: Fix null pointer dereference when host dies
Make sure xhci_free_dev() and xhci_kill_endpoint_urbs() do not race
and cause null pointer dereference when host suddenly dies.
Usb core may call xhci_free_dev() which frees the xhci->devs[slot_id]
virt device at the same time that xhci_kill_endpoint_urbs() tries to
loop through all the device's endpoints, checking if there are any
cancelled urbs left to give back.
hold the xhci spinlock while freeing the virt device