| CVE |
Vendors |
Products |
Updated |
CVSS v3.1 |
| In the Linux kernel, the following vulnerability has been resolved:
fs/smb: Fix inconsistent refcnt update
A possible inconsistent update of refcount was identified in `smb2_compound_op`.
Such inconsistent update could lead to possible resource leaks.
Why it is a possible bug:
1. In the comment section of the function, it clearly states that the
reference to `cfile` should be dropped after calling this function.
2. Every control flow path would check and drop the reference to
`cfile`, except the patched one.
3. Existing callers would not handle refcount update of `cfile` if
-ENOMEM is returned.
To fix the bug, an extra goto label "out" is added, to make sure that the
cleanup logic would always be respected. As the problem is caused by the
allocation failure of `vars`, the cleanup logic between label "finished"
and "out" can be safely ignored. According to the definition of function
`is_replayable_error`, the error code of "-ENOMEM" is not recoverable.
Therefore, the replay logic also gets ignored. |
| In the Linux kernel, the following vulnerability has been resolved:
sctp: initialize more fields in sctp_v6_from_sk()
syzbot found that sin6_scope_id was not properly initialized,
leading to undefined behavior.
Clear sin6_scope_id and sin6_flowinfo.
BUG: KMSAN: uninit-value in __sctp_v6_cmp_addr+0x887/0x8c0 net/sctp/ipv6.c:649
__sctp_v6_cmp_addr+0x887/0x8c0 net/sctp/ipv6.c:649
sctp_inet6_cmp_addr+0x4f2/0x510 net/sctp/ipv6.c:983
sctp_bind_addr_conflict+0x22a/0x3b0 net/sctp/bind_addr.c:390
sctp_get_port_local+0x21eb/0x2440 net/sctp/socket.c:8452
sctp_get_port net/sctp/socket.c:8523 [inline]
sctp_listen_start net/sctp/socket.c:8567 [inline]
sctp_inet_listen+0x710/0xfd0 net/sctp/socket.c:8636
__sys_listen_socket net/socket.c:1912 [inline]
__sys_listen net/socket.c:1927 [inline]
__do_sys_listen net/socket.c:1932 [inline]
__se_sys_listen net/socket.c:1930 [inline]
__x64_sys_listen+0x343/0x4c0 net/socket.c:1930
x64_sys_call+0x271d/0x3e20 arch/x86/include/generated/asm/syscalls_64.h:51
do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]
do_syscall_64+0xd9/0x210 arch/x86/entry/syscall_64.c:94
entry_SYSCALL_64_after_hwframe+0x77/0x7f
Local variable addr.i.i created at:
sctp_get_port net/sctp/socket.c:8515 [inline]
sctp_listen_start net/sctp/socket.c:8567 [inline]
sctp_inet_listen+0x650/0xfd0 net/sctp/socket.c:8636
__sys_listen_socket net/socket.c:1912 [inline]
__sys_listen net/socket.c:1927 [inline]
__do_sys_listen net/socket.c:1932 [inline]
__se_sys_listen net/socket.c:1930 [inline]
__x64_sys_listen+0x343/0x4c0 net/socket.c:1930 |
| In the Linux kernel, the following vulnerability has been resolved:
fs: fix UAF/GPF bug in nilfs_mdt_destroy
In alloc_inode, inode_init_always() could return -ENOMEM if
security_inode_alloc() fails, which causes inode->i_private
uninitialized. Then nilfs_is_metadata_file_inode() returns
true and nilfs_free_inode() wrongly calls nilfs_mdt_destroy(),
which frees the uninitialized inode->i_private
and leads to crashes(e.g., UAF/GPF).
Fix this by moving security_inode_alloc just prior to
this_cpu_inc(nr_inodes) |
| In the Linux kernel, the following vulnerability has been resolved:
accel/qaic: Fix slicing memory leak
The temporary buffer storing slicing configuration data from user is only
freed on error. This is a memory leak. Free the buffer unconditionally. |
| In the Linux kernel, the following vulnerability has been resolved:
media: ipu-bridge: Fix null pointer deref on SSDB/PLD parsing warnings
When ipu_bridge_parse_rotation() and ipu_bridge_parse_orientation() run
sensor->adev is not set yet.
So if either of the dev_warn() calls about unknown values are hit this
will lead to a NULL pointer deref.
Set sensor->adev earlier, with a borrowed ref to avoid making unrolling
on errors harder, to fix this. |
| In the Linux kernel, the following vulnerability has been resolved:
RDMA/cxgb4: Fix potential null-ptr-deref in pass_establish()
If get_ep_from_tid() fails to lookup non-NULL value for ep, ep is
dereferenced later regardless of whether it is empty.
This patch adds a simple sanity check to fix the issue.
Found by Linux Verification Center (linuxtesting.org) with SVACE. |
| In the Linux kernel, the following vulnerability has been resolved:
net/mlx5: Collect command failures data only for known commands
DEVX can issue a general command, which is not used by mlx5 driver.
In case such command is failed, mlx5 is trying to collect the failure
data, However, mlx5 doesn't create a storage for this command, since
mlx5 doesn't use it. This lead to array-index-out-of-bounds error.
Fix it by checking whether the command is known before collecting the
failure data. |
| In the Linux kernel, the following vulnerability has been resolved:
net: marvell: prestera: fix handling IPv4 routes with nhid
Fix handling IPv4 routes referencing a nexthop via its id by replacing
calls to fib_info_nh() with fib_info_nhc().
Trying to add an IPv4 route referencing a nextop via nhid:
$ ip link set up swp5
$ ip a a 10.0.0.1/24 dev swp5
$ ip nexthop add dev swp5 id 20 via 10.0.0.2
$ ip route add 10.0.1.0/24 nhid 20
triggers warnings when trying to handle the route:
[ 528.805763] ------------[ cut here ]------------
[ 528.810437] WARNING: CPU: 3 PID: 53 at include/net/nexthop.h:468 __prestera_fi_is_direct+0x2c/0x68 [prestera]
[ 528.820434] Modules linked in: prestera_pci act_gact act_police sch_ingress cls_u32 cls_flower prestera arm64_delta_tn48m_dn_led(O) arm64_delta_tn48m_dn_cpld(O) [last unloaded: prestera_pci]
[ 528.837485] CPU: 3 PID: 53 Comm: kworker/u8:3 Tainted: G O 6.4.5 #1
[ 528.845178] Hardware name: delta,tn48m-dn (DT)
[ 528.849641] Workqueue: prestera_ordered __prestera_router_fib_event_work [prestera]
[ 528.857352] pstate: 60000005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)
[ 528.864347] pc : __prestera_fi_is_direct+0x2c/0x68 [prestera]
[ 528.870135] lr : prestera_k_arb_fib_evt+0xb20/0xd50 [prestera]
[ 528.876007] sp : ffff80000b20bc90
[ 528.879336] x29: ffff80000b20bc90 x28: 0000000000000000 x27: ffff0001374d3a48
[ 528.886510] x26: ffff000105604000 x25: ffff000134af8a28 x24: ffff0001374d3800
[ 528.893683] x23: ffff000101c89148 x22: ffff000101c89000 x21: ffff000101c89200
[ 528.900855] x20: ffff00013641fda0 x19: ffff800009d01088 x18: 0000000000000059
[ 528.908027] x17: 0000000000000277 x16: 0000000000000000 x15: 0000000000000000
[ 528.915198] x14: 0000000000000003 x13: 00000000000fe400 x12: 0000000000000000
[ 528.922371] x11: 0000000000000002 x10: 0000000000000aa0 x9 : ffff8000013d2020
[ 528.929543] x8 : 0000000000000018 x7 : 000000007b1703f8 x6 : 000000001ca72f86
[ 528.936715] x5 : 0000000033399ea7 x4 : 0000000000000000 x3 : ffff0001374d3acc
[ 528.943886] x2 : 0000000000000000 x1 : ffff00010200de00 x0 : ffff000134ae3f80
[ 528.951058] Call trace:
[ 528.953516] __prestera_fi_is_direct+0x2c/0x68 [prestera]
[ 528.958952] __prestera_router_fib_event_work+0x100/0x158 [prestera]
[ 528.965348] process_one_work+0x208/0x488
[ 528.969387] worker_thread+0x4c/0x430
[ 528.973068] kthread+0x120/0x138
[ 528.976313] ret_from_fork+0x10/0x20
[ 528.979909] ---[ end trace 0000000000000000 ]---
[ 528.984998] ------------[ cut here ]------------
[ 528.989645] WARNING: CPU: 3 PID: 53 at include/net/nexthop.h:468 __prestera_fi_is_direct+0x2c/0x68 [prestera]
[ 528.999628] Modules linked in: prestera_pci act_gact act_police sch_ingress cls_u32 cls_flower prestera arm64_delta_tn48m_dn_led(O) arm64_delta_tn48m_dn_cpld(O) [last unloaded: prestera_pci]
[ 529.016676] CPU: 3 PID: 53 Comm: kworker/u8:3 Tainted: G W O 6.4.5 #1
[ 529.024368] Hardware name: delta,tn48m-dn (DT)
[ 529.028830] Workqueue: prestera_ordered __prestera_router_fib_event_work [prestera]
[ 529.036539] pstate: 60000005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)
[ 529.043533] pc : __prestera_fi_is_direct+0x2c/0x68 [prestera]
[ 529.049318] lr : __prestera_k_arb_fc_apply+0x280/0x2f8 [prestera]
[ 529.055452] sp : ffff80000b20bc60
[ 529.058781] x29: ffff80000b20bc60 x28: 0000000000000000 x27: ffff0001374d3a48
[ 529.065953] x26: ffff000105604000 x25: ffff000134af8a28 x24: ffff0001374d3800
[ 529.073126] x23: ffff000101c89148 x22: ffff000101c89148 x21: ffff00013641fda0
[ 529.080299] x20: ffff000101c89000 x19: ffff000101c89020 x18: 0000000000000059
[ 529.087471] x17: 0000000000000277 x16: 0000000000000000 x15: 0000000000000000
[ 529.094642] x14: 0000000000000003 x13: 00000000000fe400 x12: 0000000000000000
[ 529.101814] x11: 0000000000000002 x10: 0000000000000aa0 x9 : ffff8000013cee80
[ 529.108985] x8 : 0000000000000018 x7 : 000000007b1703f8 x6
---truncated--- |
| In the Linux kernel, the following vulnerability has been resolved:
drm/xe/vm: Clear the scratch_pt pointer on error
Avoid triggering a dereference of an error pointer on cleanup in
xe_vm_free_scratch() by clearing any scratch_pt error pointer.
(cherry picked from commit 358ee50ab565f3c8ea32480e9d03127a81ba32f8) |
| In the Linux kernel, the following vulnerability has been resolved:
RISC-V: KVM: fix stack overrun when loading vlenb
The userspace load can put up to 2048 bits into an xlen bit stack
buffer. We want only xlen bits, so check the size beforehand. |
| In the Linux kernel, the following vulnerability has been resolved:
bnxt_en: Fix memory corruption when FW resources change during ifdown
bnxt_set_dflt_rings() assumes that it is always called before any TC has
been created. So it doesn't take bp->num_tc into account and assumes
that it is always 0 or 1.
In the FW resource or capability change scenario, the FW will return
flags in bnxt_hwrm_if_change() that will cause the driver to
reinitialize and call bnxt_cancel_reservations(). This will lead to
bnxt_init_dflt_ring_mode() calling bnxt_set_dflt_rings() and bp->num_tc
may be greater than 1. This will cause bp->tx_ring[] to be sized too
small and cause memory corruption in bnxt_alloc_cp_rings().
Fix it by properly scaling the TX rings by bp->num_tc in the code
paths mentioned above. Add 2 helper functions to determine
bp->tx_nr_rings and bp->tx_nr_rings_per_tc. |
| In the Linux kernel, the following vulnerability has been resolved:
btrfs: fix deadlock when aborting transaction during relocation with scrub
Before relocating a block group we pause scrub, then do the relocation and
then unpause scrub. The relocation process requires starting and committing
a transaction, and if we have a failure in the critical section of the
transaction commit path (transaction state >= TRANS_STATE_COMMIT_START),
we will deadlock if there is a paused scrub.
That results in stack traces like the following:
[42.479] BTRFS info (device sdc): relocating block group 53876686848 flags metadata|raid6
[42.936] BTRFS warning (device sdc): Skipping commit of aborted transaction.
[42.936] ------------[ cut here ]------------
[42.936] BTRFS: Transaction aborted (error -28)
[42.936] WARNING: CPU: 11 PID: 346822 at fs/btrfs/transaction.c:1977 btrfs_commit_transaction+0xcc8/0xeb0 [btrfs]
[42.936] Modules linked in: dm_flakey dm_mod loop btrfs (...)
[42.936] CPU: 11 PID: 346822 Comm: btrfs Tainted: G W 6.3.0-rc2-btrfs-next-127+ #1
[42.936] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.14.0-0-g155821a1990b-prebuilt.qemu.org 04/01/2014
[42.936] RIP: 0010:btrfs_commit_transaction+0xcc8/0xeb0 [btrfs]
[42.936] Code: ff ff 45 8b (...)
[42.936] RSP: 0018:ffffb58649633b48 EFLAGS: 00010282
[42.936] RAX: 0000000000000000 RBX: ffff8be6ef4d5bd8 RCX: 0000000000000000
[42.936] RDX: 0000000000000002 RSI: ffffffffb35e7782 RDI: 00000000ffffffff
[42.936] RBP: ffff8be6ef4d5c98 R08: 0000000000000000 R09: ffffb586496339e8
[42.936] R10: 0000000000000001 R11: 0000000000000001 R12: ffff8be6d38c7c00
[42.936] R13: 00000000ffffffe4 R14: ffff8be6c268c000 R15: ffff8be6ef4d5cf0
[42.936] FS: 00007f381a82b340(0000) GS:ffff8beddfcc0000(0000) knlGS:0000000000000000
[42.936] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[42.936] CR2: 00007f1e35fb7638 CR3: 0000000117680006 CR4: 0000000000370ee0
[42.936] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
[42.936] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
[42.936] Call Trace:
[42.936] <TASK>
[42.936] ? start_transaction+0xcb/0x610 [btrfs]
[42.936] prepare_to_relocate+0x111/0x1a0 [btrfs]
[42.936] relocate_block_group+0x57/0x5d0 [btrfs]
[42.936] ? btrfs_wait_nocow_writers+0x25/0xb0 [btrfs]
[42.936] btrfs_relocate_block_group+0x248/0x3c0 [btrfs]
[42.936] ? __pfx_autoremove_wake_function+0x10/0x10
[42.936] btrfs_relocate_chunk+0x3b/0x150 [btrfs]
[42.936] btrfs_balance+0x8ff/0x11d0 [btrfs]
[42.936] ? __kmem_cache_alloc_node+0x14a/0x410
[42.936] btrfs_ioctl+0x2334/0x32c0 [btrfs]
[42.937] ? mod_objcg_state+0xd2/0x360
[42.937] ? refill_obj_stock+0xb0/0x160
[42.937] ? seq_release+0x25/0x30
[42.937] ? __rseq_handle_notify_resume+0x3b5/0x4b0
[42.937] ? percpu_counter_add_batch+0x2e/0xa0
[42.937] ? __x64_sys_ioctl+0x88/0xc0
[42.937] __x64_sys_ioctl+0x88/0xc0
[42.937] do_syscall_64+0x38/0x90
[42.937] entry_SYSCALL_64_after_hwframe+0x72/0xdc
[42.937] RIP: 0033:0x7f381a6ffe9b
[42.937] Code: 00 48 89 44 24 (...)
[42.937] RSP: 002b:00007ffd45ecf060 EFLAGS: 00000246 ORIG_RAX: 0000000000000010
[42.937] RAX: ffffffffffffffda RBX: 0000000000000001 RCX: 00007f381a6ffe9b
[42.937] RDX: 00007ffd45ecf150 RSI: 00000000c4009420 RDI: 0000000000000003
[42.937] RBP: 0000000000000003 R08: 0000000000000013 R09: 0000000000000000
[42.937] R10: 00007f381a60c878 R11: 0000000000000246 R12: 00007ffd45ed0423
[42.937] R13: 00007ffd45ecf150 R14: 0000000000000000 R15: 00007ffd45ecf148
[42.937] </TASK>
[42.937] ---[ end trace 0000000000000000 ]---
[42.937] BTRFS: error (device sdc: state A) in cleanup_transaction:1977: errno=-28 No space left
[59.196] INFO: task btrfs:346772 blocked for more than 120 seconds.
[59.196] Tainted: G W 6.3.0-rc2-btrfs-next-127+ #1
[59.196] "echo 0 > /proc/sys/kernel/hung_
---truncated--- |
| In the Linux kernel, the following vulnerability has been resolved:
powercap: intel_rapl: fix UBSAN shift-out-of-bounds issue
When value < time_unit, the parameter of ilog2() will be zero and
the return value is -1. u64(-1) is too large for shift exponent
and then will trigger shift-out-of-bounds:
shift exponent 18446744073709551615 is too large for 32-bit type 'int'
Call Trace:
rapl_compute_time_window_core
rapl_write_data_raw
set_time_window
store_constraint_time_window_us |
| In the Linux kernel, the following vulnerability has been resolved:
regulator: da9063: better fix null deref with partial DT
Two versions of the original patch were sent but V1 was merged instead
of V2 due to a mistake.
So update to V2.
The advantage of V2 is that it completely avoids dereferencing the pointer,
even just to take the address, which may fix problems with some compilers.
Both versions work on my gcc 9.4 but use the safer one. |
| In the Linux kernel, the following vulnerability has been resolved:
md/raid10: check slab-out-of-bounds in md_bitmap_get_counter
If we write a large number to md/bitmap_set_bits, md_bitmap_checkpage()
will return -EINVAL because 'page >= bitmap->pages', but the return value
was not checked immediately in md_bitmap_get_counter() in order to set
*blocks value and slab-out-of-bounds occurs.
Move check of 'page >= bitmap->pages' to md_bitmap_get_counter() and
return directly if true. |
| In the Linux kernel, the following vulnerability has been resolved:
mmc: wmt-sdmmc: fix return value check of mmc_add_host()
mmc_add_host() may return error, if we ignore its return value, the memory
that allocated in mmc_alloc_host() will be leaked and it will lead a kernel
crash because of deleting not added device in the remove path.
So fix this by checking the return value and goto error path which will call
mmc_free_host(), besides, clk_disable_unprepare() also needs be called. |
| In the Linux kernel, the following vulnerability has been resolved:
net: sched: sfb: fix null pointer access issue when sfb_init() fails
When the default qdisc is sfb, if the qdisc of dev_queue fails to be
inited during mqprio_init(), sfb_reset() is invoked to clear resources.
In this case, the q->qdisc is NULL, and it will cause gpf issue.
The process is as follows:
qdisc_create_dflt()
sfb_init()
tcf_block_get() --->failed, q->qdisc is NULL
...
qdisc_put()
...
sfb_reset()
qdisc_reset(q->qdisc) --->q->qdisc is NULL
ops = qdisc->ops
The following is the Call Trace information:
general protection fault, probably for non-canonical address
0xdffffc0000000003: 0000 [#1] PREEMPT SMP KASAN
KASAN: null-ptr-deref in range [0x0000000000000018-0x000000000000001f]
RIP: 0010:qdisc_reset+0x2b/0x6f0
Call Trace:
<TASK>
sfb_reset+0x37/0xd0
qdisc_reset+0xed/0x6f0
qdisc_destroy+0x82/0x4c0
qdisc_put+0x9e/0xb0
qdisc_create_dflt+0x2c3/0x4a0
mqprio_init+0xa71/0x1760
qdisc_create+0x3eb/0x1000
tc_modify_qdisc+0x408/0x1720
rtnetlink_rcv_msg+0x38e/0xac0
netlink_rcv_skb+0x12d/0x3a0
netlink_unicast+0x4a2/0x740
netlink_sendmsg+0x826/0xcc0
sock_sendmsg+0xc5/0x100
____sys_sendmsg+0x583/0x690
___sys_sendmsg+0xe8/0x160
__sys_sendmsg+0xbf/0x160
do_syscall_64+0x35/0x80
entry_SYSCALL_64_after_hwframe+0x46/0xb0
RIP: 0033:0x7f2164122d04
</TASK> |
| In the Linux kernel, the following vulnerability has been resolved:
drm/msm/dp: fix aux-bus EP lifetime
Device-managed resources allocated post component bind must be tied to
the lifetime of the aggregate DRM device or they will not necessarily be
released when binding of the aggregate device is deferred.
This can lead resource leaks or failure to bind the aggregate device
when binding is later retried and a second attempt to allocate the
resources is made.
For the DP aux-bus, an attempt to populate the bus a second time will
simply fail ("DP AUX EP device already populated").
Fix this by tying the lifetime of the EP device to the DRM device rather
than DP controller platform device.
Patchwork: https://patchwork.freedesktop.org/patch/502672/ |
| In the Linux kernel, the following vulnerability has been resolved:
icmp6: Fix null-ptr-deref of ip6_null_entry->rt6i_idev in icmp6_dev().
With some IPv6 Ext Hdr (RPL, SRv6, etc.), we can send a packet that
has the link-local address as src and dst IP and will be forwarded to
an external IP in the IPv6 Ext Hdr.
For example, the script below generates a packet whose src IP is the
link-local address and dst is updated to 11::.
# for f in $(find /proc/sys/net/ -name *seg6_enabled*); do echo 1 > $f; done
# python3
>>> from socket import *
>>> from scapy.all import *
>>>
>>> SRC_ADDR = DST_ADDR = "fe80::5054:ff:fe12:3456"
>>>
>>> pkt = IPv6(src=SRC_ADDR, dst=DST_ADDR)
>>> pkt /= IPv6ExtHdrSegmentRouting(type=4, addresses=["11::", "22::"], segleft=1)
>>>
>>> sk = socket(AF_INET6, SOCK_RAW, IPPROTO_RAW)
>>> sk.sendto(bytes(pkt), (DST_ADDR, 0))
For such a packet, we call ip6_route_input() to look up a route for the
next destination in these three functions depending on the header type.
* ipv6_rthdr_rcv()
* ipv6_rpl_srh_rcv()
* ipv6_srh_rcv()
If no route is found, ip6_null_entry is set to skb, and the following
dst_input(skb) calls ip6_pkt_drop().
Finally, in icmp6_dev(), we dereference skb_rt6_info(skb)->rt6i_idev->dev
as the input device is the loopback interface. Then, we have to check if
skb_rt6_info(skb)->rt6i_idev is NULL or not to avoid NULL pointer deref
for ip6_null_entry.
BUG: kernel NULL pointer dereference, address: 0000000000000000
PF: supervisor read access in kernel mode
PF: error_code(0x0000) - not-present page
PGD 0 P4D 0
Oops: 0000 [#1] PREEMPT SMP PTI
CPU: 0 PID: 157 Comm: python3 Not tainted 6.4.0-11996-gb121d614371c #35
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.0-0-gd239552ce722-prebuilt.qemu.org 04/01/2014
RIP: 0010:icmp6_send (net/ipv6/icmp.c:436 net/ipv6/icmp.c:503)
Code: fe ff ff 48 c7 40 30 c0 86 5d 83 e8 c6 44 1c 00 e9 c8 fc ff ff 49 8b 46 58 48 83 e0 fe 0f 84 4a fb ff ff 48 8b 80 d0 00 00 00 <48> 8b 00 44 8b 88 e0 00 00 00 e9 34 fb ff ff 4d 85 ed 0f 85 69 01
RSP: 0018:ffffc90000003c70 EFLAGS: 00000286
RAX: 0000000000000000 RBX: 0000000000000001 RCX: 00000000000000e0
RDX: 0000000000000021 RSI: 0000000000000000 RDI: ffff888006d72a18
RBP: ffffc90000003d80 R08: 0000000000000000 R09: 0000000000000001
R10: ffffc90000003d98 R11: 0000000000000040 R12: ffff888006d72a10
R13: 0000000000000000 R14: ffff8880057fb800 R15: ffffffff835d86c0
FS: 00007f9dc72ee740(0000) GS:ffff88807dc00000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 0000000000000000 CR3: 00000000057b2000 CR4: 00000000007506f0
PKRU: 55555554
Call Trace:
<IRQ>
ip6_pkt_drop (net/ipv6/route.c:4513)
ipv6_rthdr_rcv (net/ipv6/exthdrs.c:640 net/ipv6/exthdrs.c:686)
ip6_protocol_deliver_rcu (net/ipv6/ip6_input.c:437 (discriminator 5))
ip6_input_finish (./include/linux/rcupdate.h:781 net/ipv6/ip6_input.c:483)
__netif_receive_skb_one_core (net/core/dev.c:5455)
process_backlog (./include/linux/rcupdate.h:781 net/core/dev.c:5895)
__napi_poll (net/core/dev.c:6460)
net_rx_action (net/core/dev.c:6529 net/core/dev.c:6660)
__do_softirq (./arch/x86/include/asm/jump_label.h:27 ./include/linux/jump_label.h:207 ./include/trace/events/irq.h:142 kernel/softirq.c:554)
do_softirq (kernel/softirq.c:454 kernel/softirq.c:441)
</IRQ>
<TASK>
__local_bh_enable_ip (kernel/softirq.c:381)
__dev_queue_xmit (net/core/dev.c:4231)
ip6_finish_output2 (./include/net/neighbour.h:544 net/ipv6/ip6_output.c:135)
rawv6_sendmsg (./include/net/dst.h:458 ./include/linux/netfilter.h:303 net/ipv6/raw.c:656 net/ipv6/raw.c:914)
sock_sendmsg (net/socket.c:725 net/socket.c:748)
__sys_sendto (net/socket.c:2134)
__x64_sys_sendto (net/socket.c:2146 net/socket.c:2142 net/socket.c:2142)
do_syscall_64 (arch/x86/entry/common.c:50 arch/x86/entry/common.c:80)
entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:120)
RIP: 0033:0x7f9dc751baea
Code: d8 64 89 02 48 c7 c0 ff f
---truncated--- |
| In the Linux kernel, the following vulnerability has been resolved:
Bluetooth: hci_{ldisc,serdev}: check percpu_init_rwsem() failure
syzbot is reporting NULL pointer dereference at hci_uart_tty_close() [1],
for rcu_sync_enter() is called without rcu_sync_init() due to
hci_uart_tty_open() ignoring percpu_init_rwsem() failure.
While we are at it, fix that hci_uart_register_device() ignores
percpu_init_rwsem() failure and hci_uart_unregister_device() does not
call percpu_free_rwsem(). |
