Linux: >> Linux Kernel >> 2.0.28 Security Vulnerabilities
In the Linux kernel, the following vulnerability has been resolved:
Bluetooth: hci_core: Fix leaking sent_cmd skb
sent_cmd memory is not freed before freeing hci_dev causing it to leak
it contents.
CVSS Score
5.5
EPSS Score
0.0
Published
2024-07-16
In the Linux kernel, the following vulnerability has been resolved:
MIPS: smp: fill in sibling and core maps earlier
After enabling CONFIG_SCHED_CORE (landed during 5.14 cycle),
2-core 2-thread-per-core interAptiv (CPS-driven) started emitting
the following:
[ 0.025698] CPU1 revision is: 0001a120 (MIPS interAptiv (multi))
[ 0.048183] ------------[ cut here ]------------
[ 0.048187] WARNING: CPU: 1 PID: 0 at kernel/sched/core.c:6025 sched_core_cpu_starting+0x198/0x240
[ 0.048220] Modules linked in:
[ 0.048233] CPU: 1 PID: 0 Comm: swapper/1 Not tainted 5.17.0-rc3+ #35 b7b319f24073fd9a3c2aa7ad15fb7993eec0b26f
[ 0.048247] Stack : 817f0000 00000004 327804c8 810eb050 00000000 00000004 00000000 c314fdd1
[ 0.048278] 830cbd64 819c0000 81800000 817f0000 83070bf4 00000001 830cbd08 00000000
[ 0.048307] 00000000 00000000 815fcbc4 00000000 00000000 00000000 00000000 00000000
[ 0.048334] 00000000 00000000 00000000 00000000 817f0000 00000000 00000000 817f6f34
[ 0.048361] 817f0000 818a3c00 817f0000 00000004 00000000 00000000 4dc33260 0018c933
[ 0.048389] ...
[ 0.048396] Call Trace:
[ 0.048399] [<8105a7bc>] show_stack+0x3c/0x140
[ 0.048424] [<8131c2a0>] dump_stack_lvl+0x60/0x80
[ 0.048440] [<8108b5c0>] __warn+0xc0/0xf4
[ 0.048454] [<8108b658>] warn_slowpath_fmt+0x64/0x10c
[ 0.048467] [<810bd418>] sched_core_cpu_starting+0x198/0x240
[ 0.048483] [<810c6514>] sched_cpu_starting+0x14/0x80
[ 0.048497] [<8108c0f8>] cpuhp_invoke_callback_range+0x78/0x140
[ 0.048510] [<8108d914>] notify_cpu_starting+0x94/0x140
[ 0.048523] [<8106593c>] start_secondary+0xbc/0x280
[ 0.048539]
[ 0.048543] ---[ end trace 0000000000000000 ]---
[ 0.048636] Synchronize counters for CPU 1: done.
...for each but CPU 0/boot.
Basic debug printks right before the mentioned line say:
[ 0.048170] CPU: 1, smt_mask:
So smt_mask, which is sibling mask obviously, is empty when entering
the function.
This is critical, as sched_core_cpu_starting() calculates
core-scheduling parameters only once per CPU start, and it's crucial
to have all the parameters filled in at that moment (at least it
uses cpu_smt_mask() which in fact is `&cpu_sibling_map[cpu]` on
MIPS).
A bit of debugging led me to that set_cpu_sibling_map() performing
the actual map calculation, was being invocated after
notify_cpu_start(), and exactly the latter function starts CPU HP
callback round (sched_core_cpu_starting() is basically a CPU HP
callback).
While the flow is same on ARM64 (maps after the notifier, although
before calling set_cpu_online()), x86 started calculating sibling
maps earlier than starting the CPU HP callbacks in Linux 4.14 (see
[0] for the reference). Neither me nor my brief tests couldn't find
any potential caveats in calculating the maps right after performing
delay calibration, but the WARN splat is now gone.
The very same debug prints now yield exactly what I expected from
them:
[ 0.048433] CPU: 1, smt_mask: 0-1
[0] https://git.kernel.org/pub/scm/linux/kernel/git/mips/linux.git/commit/?id=76ce7cfe35ef
CVSS Score
5.5
EPSS Score
0.0
Published
2024-07-16
In the Linux kernel, the following vulnerability has been resolved:
scsi: myrs: Fix crash in error case
In myrs_detect(), cs->disable_intr is NULL when privdata->hw_init() fails
with non-zero. In this case, myrs_cleanup(cs) will call a NULL ptr and
crash the kernel.
[ 1.105606] myrs 0000:00:03.0: Unknown Initialization Error 5A
[ 1.105872] myrs 0000:00:03.0: Failed to initialize Controller
[ 1.106082] BUG: kernel NULL pointer dereference, address: 0000000000000000
[ 1.110774] Call Trace:
[ 1.110950] myrs_cleanup+0xe4/0x150 [myrs]
[ 1.111135] myrs_probe.cold+0x91/0x56a [myrs]
[ 1.111302] ? DAC960_GEM_intr_handler+0x1f0/0x1f0 [myrs]
[ 1.111500] local_pci_probe+0x48/0x90
CVSS Score
5.5
EPSS Score
0.0
Published
2024-07-16
In the Linux kernel, the following vulnerability has been resolved:
drm/vc4: Fix deadlock on DSI device attach error
DSI device attach to DSI host will be done with host device's lock
held.
Un-registering host in "device attach" error path (ex: probe retry)
will result in deadlock with below call trace and non operational
DSI display.
Startup Call trace:
[ 35.043036] rt_mutex_slowlock.constprop.21+0x184/0x1b8
[ 35.043048] mutex_lock_nested+0x7c/0xc8
[ 35.043060] device_del+0x4c/0x3e8
[ 35.043075] device_unregister+0x20/0x40
[ 35.043082] mipi_dsi_remove_device_fn+0x18/0x28
[ 35.043093] device_for_each_child+0x68/0xb0
[ 35.043105] mipi_dsi_host_unregister+0x40/0x90
[ 35.043115] vc4_dsi_host_attach+0xf0/0x120 [vc4]
[ 35.043199] mipi_dsi_attach+0x30/0x48
[ 35.043209] tc358762_probe+0x128/0x164 [tc358762]
[ 35.043225] mipi_dsi_drv_probe+0x28/0x38
[ 35.043234] really_probe+0xc0/0x318
[ 35.043244] __driver_probe_device+0x80/0xe8
[ 35.043254] driver_probe_device+0xb8/0x118
[ 35.043263] __device_attach_driver+0x98/0xe8
[ 35.043273] bus_for_each_drv+0x84/0xd8
[ 35.043281] __device_attach+0xf0/0x150
[ 35.043290] device_initial_probe+0x1c/0x28
[ 35.043300] bus_probe_device+0xa4/0xb0
[ 35.043308] deferred_probe_work_func+0xa0/0xe0
[ 35.043318] process_one_work+0x254/0x700
[ 35.043330] worker_thread+0x4c/0x448
[ 35.043339] kthread+0x19c/0x1a8
[ 35.043348] ret_from_fork+0x10/0x20
Shutdown Call trace:
[ 365.565417] Call trace:
[ 365.565423] __switch_to+0x148/0x200
[ 365.565452] __schedule+0x340/0x9c8
[ 365.565467] schedule+0x48/0x110
[ 365.565479] schedule_timeout+0x3b0/0x448
[ 365.565496] wait_for_completion+0xac/0x138
[ 365.565509] __flush_work+0x218/0x4e0
[ 365.565523] flush_work+0x1c/0x28
[ 365.565536] wait_for_device_probe+0x68/0x158
[ 365.565550] device_shutdown+0x24/0x348
[ 365.565561] kernel_restart_prepare+0x40/0x50
[ 365.565578] kernel_restart+0x20/0x70
[ 365.565591] __do_sys_reboot+0x10c/0x220
[ 365.565605] __arm64_sys_reboot+0x2c/0x38
[ 365.565619] invoke_syscall+0x4c/0x110
[ 365.565634] el0_svc_common.constprop.3+0xfc/0x120
[ 365.565648] do_el0_svc+0x2c/0x90
[ 365.565661] el0_svc+0x4c/0xf0
[ 365.565671] el0t_64_sync_handler+0x90/0xb8
[ 365.565682] el0t_64_sync+0x180/0x184
CVSS Score
5.5
EPSS Score
0.0
Published
2024-07-16
In the Linux kernel, the following vulnerability has been resolved:
NFSD: Fix the behavior of READ near OFFSET_MAX
Dan Aloni reports:
> Due to commit 8cfb9015280d ("NFS: Always provide aligned buffers to
> the RPC read layers") on the client, a read of 0xfff is aligned up
> to server rsize of 0x1000.
>
> As a result, in a test where the server has a file of size
> 0x7fffffffffffffff, and the client tries to read from the offset
> 0x7ffffffffffff000, the read causes loff_t overflow in the server
> and it returns an NFS code of EINVAL to the client. The client as
> a result indefinitely retries the request.
The Linux NFS client does not handle NFS?ERR_INVAL, even though all
NFS specifications permit servers to return that status code for a
READ.
Instead of NFS?ERR_INVAL, have out-of-range READ requests succeed
and return a short result. Set the EOF flag in the result to prevent
the client from retrying the READ request. This behavior appears to
be consistent with Solaris NFS servers.
Note that NFSv3 and NFSv4 use u64 offset values on the wire. These
must be converted to loff_t internally before use -- an implicit
type cast is not adequate for this purpose. Otherwise VFS checks
against sb->s_maxbytes do not work properly.
CVSS Score
7.1
EPSS Score
0.0
Published
2024-07-16
In the Linux kernel, the following vulnerability has been resolved:
NFSD: Fix ia_size underflow
iattr::ia_size is a loff_t, which is a signed 64-bit type. NFSv3 and
NFSv4 both define file size as an unsigned 64-bit type. Thus there
is a range of valid file size values an NFS client can send that is
already larger than Linux can handle.
Currently decode_fattr4() dumps a full u64 value into ia_size. If
that value happens to be larger than S64_MAX, then ia_size
underflows. I'm about to fix up the NFSv3 behavior as well, so let's
catch the underflow in the common code path: nfsd_setattr().
CVSS Score
5.5
EPSS Score
0.0
Published
2024-07-16
In the Linux kernel, the following vulnerability has been resolved:
NFSD: Fix NFSv3 SETATTR/CREATE's handling of large file sizes
iattr::ia_size is a loff_t, so these NFSv3 procedures must be
careful to deal with incoming client size values that are larger
than s64_max without corrupting the value.
Silently capping the value results in storing a different value
than the client passed in which is unexpected behavior, so remove
the min_t() check in decode_sattr3().
Note that RFC 1813 permits only the WRITE procedure to return
NFS3ERR_FBIG. We believe that NFSv3 reference implementations
also return NFS3ERR_FBIG when ia_size is too large.
CVSS Score
5.5
EPSS Score
0.0
Published
2024-07-16
In the Linux kernel, the following vulnerability has been resolved:
net: ieee802154: at86rf230: Stop leaking skb's
Upon error the ieee802154_xmit_complete() helper is not called. Only
ieee802154_wake_queue() is called manually. In the Tx case we then leak
the skb structure.
Free the skb structure upon error before returning when appropriate.
As the 'is_tx = 0' cannot be moved in the complete handler because of a
possible race between the delay in switching to STATE_RX_AACK_ON and a
new interrupt, we introduce an intermediate 'was_tx' boolean just for
this purpose.
There is no Fixes tag applying here, many changes have been made on this
area and the issue kind of always existed.
CVSS Score
5.5
EPSS Score
0.0
Published
2024-07-16
In the Linux kernel, the following vulnerability has been resolved:
parisc: Fix data TLB miss in sba_unmap_sg
Rolf Eike Beer reported the following bug:
[1274934.746891] Bad Address (null pointer deref?): Code=15 (Data TLB miss fault) at addr 0000004140000018
[1274934.746891] CPU: 3 PID: 5549 Comm: cmake Not tainted 5.15.4-gentoo-parisc64 #4
[1274934.746891] Hardware name: 9000/785/C8000
[1274934.746891]
[1274934.746891] YZrvWESTHLNXBCVMcbcbcbcbOGFRQPDI
[1274934.746891] PSW: 00001000000001001111111000001110 Not tainted
[1274934.746891] r00-03 000000ff0804fe0e 0000000040bc9bc0 00000000406760e4 0000004140000000
[1274934.746891] r04-07 0000000040b693c0 0000004140000000 000000004a2b08b0 0000000000000001
[1274934.746891] r08-11 0000000041f98810 0000000000000000 000000004a0a7000 0000000000000001
[1274934.746891] r12-15 0000000040bddbc0 0000000040c0cbc0 0000000040bddbc0 0000000040bddbc0
[1274934.746891] r16-19 0000000040bde3c0 0000000040bddbc0 0000000040bde3c0 0000000000000007
[1274934.746891] r20-23 0000000000000006 000000004a368950 0000000000000000 0000000000000001
[1274934.746891] r24-27 0000000000001fff 000000000800000e 000000004a1710f0 0000000040b693c0
[1274934.746891] r28-31 0000000000000001 0000000041f988b0 0000000041f98840 000000004a171118
[1274934.746891] sr00-03 00000000066e5800 0000000000000000 0000000000000000 00000000066e5800
[1274934.746891] sr04-07 0000000000000000 0000000000000000 0000000000000000 0000000000000000
[1274934.746891]
[1274934.746891] IASQ: 0000000000000000 0000000000000000 IAOQ: 00000000406760e8 00000000406760ec
[1274934.746891] IIR: 48780030 ISR: 0000000000000000 IOR: 0000004140000018
[1274934.746891] CPU: 3 CR30: 00000040e3a9c000 CR31: ffffffffffffffff
[1274934.746891] ORIG_R28: 0000000040acdd58
[1274934.746891] IAOQ[0]: sba_unmap_sg+0xb0/0x118
[1274934.746891] IAOQ[1]: sba_unmap_sg+0xb4/0x118
[1274934.746891] RP(r2): sba_unmap_sg+0xac/0x118
[1274934.746891] Backtrace:
[1274934.746891] [<00000000402740cc>] dma_unmap_sg_attrs+0x6c/0x70
[1274934.746891] [<000000004074d6bc>] scsi_dma_unmap+0x54/0x60
[1274934.746891] [<00000000407a3488>] mptscsih_io_done+0x150/0xd70
[1274934.746891] [<0000000040798600>] mpt_interrupt+0x168/0xa68
[1274934.746891] [<0000000040255a48>] __handle_irq_event_percpu+0xc8/0x278
[1274934.746891] [<0000000040255c34>] handle_irq_event_percpu+0x3c/0xd8
[1274934.746891] [<000000004025ecb4>] handle_percpu_irq+0xb4/0xf0
[1274934.746891] [<00000000402548e0>] generic_handle_irq+0x50/0x70
[1274934.746891] [<000000004019a254>] call_on_stack+0x18/0x24
[1274934.746891]
[1274934.746891] Kernel panic - not syncing: Bad Address (null pointer deref?)
The bug is caused by overrunning the sglist and incorrectly testing
sg_dma_len(sglist) before nents. Normally this doesn't cause a crash,
but in this case sglist crossed a page boundary. This occurs in the
following code:
while (sg_dma_len(sglist) && nents--) {
The fix is simply to test nents first and move the decrement of nents
into the loop.
CVSS Score
5.5
EPSS Score
0.0
Published
2024-07-16
In the Linux kernel, the following vulnerability has been resolved:
vt_ioctl: fix array_index_nospec in vt_setactivate
array_index_nospec ensures that an out-of-bounds value is set to zero
on the transient path. Decreasing the value by one afterwards causes
a transient integer underflow. vsa.console should be decreased first
and then sanitized with array_index_nospec.
Kasper Acknowledgements: Jakob Koschel, Brian Johannesmeyer, Kaveh
Razavi, Herbert Bos, Cristiano Giuffrida from the VUSec group at VU
Amsterdam.
CVSS Score
5.5
EPSS Score
0.0
Published
2024-07-16