In the Linux kernel, the following vulnerability has been resolved:
scsi: target: iscsi: Fix a race condition between login_work and the login thread
In case a malicious initiator sends some random data immediately after a
login PDU; the iscsi_target_sk_data_ready() callback will schedule the
login_work and, at the same time, the negotiation may end without clearing
the LOGIN_FLAGS_INITIAL_PDU flag (because no additional PDU exchanges are
required to complete the login).
The login has been completed but the login_work function will find the
LOGIN_FLAGS_INITIAL_PDU flag set and will never stop from rescheduling
itself; at this point, if the initiator drops the connection, the
iscsit_conn structure will be freed, login_work will dereference a released
socket structure and the kernel crashes.
BUG: kernel NULL pointer dereference, address: 0000000000000230
PF: supervisor write access in kernel mode
PF: error_code(0x0002) - not-present page
Workqueue: events iscsi_target_do_login_rx [iscsi_target_mod]
RIP: 0010:_raw_read_lock_bh+0x15/0x30
Call trace:
iscsi_target_do_login_rx+0x75/0x3f0 [iscsi_target_mod]
process_one_work+0x1e8/0x3c0
Fix this bug by forcing login_work to stop after the login has been
completed and the socket callbacks have been restored.
Add a comment to clearify the return values of iscsi_target_do_login()
In the Linux kernel, the following vulnerability has been resolved:
cifs: Fix xid leak in cifs_create()
If the cifs already shutdown, we should free the xid before return,
otherwise, the xid will be leaked.
In the Linux kernel, the following vulnerability has been resolved:
media: vimc: Fix wrong function called when vimc_init() fails
In vimc_init(), when platform_driver_register(&vimc_pdrv) fails,
platform_driver_unregister(&vimc_pdrv) is wrongly called rather than
platform_device_unregister(&vimc_pdev), which causes kernel warning:
Unexpected driver unregister!
WARNING: CPU: 1 PID: 14517 at drivers/base/driver.c:270 driver_unregister+0x8f/0xb0
RIP: 0010:driver_unregister+0x8f/0xb0
Call Trace:
<TASK>
vimc_init+0x7d/0x1000 [vimc]
do_one_initcall+0xd0/0x4e0
do_init_module+0x1cf/0x6b0
load_module+0x65c2/0x7820
In the Linux kernel, the following vulnerability has been resolved:
cifs: fix oops during encryption
When running xfstests against Azure the following oops occurred on an
arm64 system
Unable to handle kernel write to read-only memory at virtual address
ffff0001221cf000
Mem abort info:
ESR = 0x9600004f
EC = 0x25: DABT (current EL), IL = 32 bits
SET = 0, FnV = 0
EA = 0, S1PTW = 0
FSC = 0x0f: level 3 permission fault
Data abort info:
ISV = 0, ISS = 0x0000004f
CM = 0, WnR = 1
swapper pgtable: 4k pages, 48-bit VAs, pgdp=00000000294f3000
[ffff0001221cf000] pgd=18000001ffff8003, p4d=18000001ffff8003,
pud=18000001ff82e003, pmd=18000001ff71d003, pte=00600001221cf787
Internal error: Oops: 9600004f [#1] PREEMPT SMP
...
pstate: 80000005 (Nzcv daif -PAN -UAO -TCO BTYPE=--)
pc : __memcpy+0x40/0x230
lr : scatterwalk_copychunks+0xe0/0x200
sp : ffff800014e92de0
x29: ffff800014e92de0 x28: ffff000114f9de80 x27: 0000000000000008
x26: 0000000000000008 x25: ffff800014e92e78 x24: 0000000000000008
x23: 0000000000000001 x22: 0000040000000000 x21: ffff000000000000
x20: 0000000000000001 x19: ffff0001037c4488 x18: 0000000000000014
x17: 235e1c0d6efa9661 x16: a435f9576b6edd6c x15: 0000000000000058
x14: 0000000000000001 x13: 0000000000000008 x12: ffff000114f2e590
x11: ffffffffffffffff x10: 0000040000000000 x9 : ffff8000105c3580
x8 : 2e9413b10000001a x7 : 534b4410fb86b005 x6 : 534b4410fb86b005
x5 : ffff0001221cf008 x4 : ffff0001037c4490 x3 : 0000000000000001
x2 : 0000000000000008 x1 : ffff0001037c4488 x0 : ffff0001221cf000
Call trace:
__memcpy+0x40/0x230
scatterwalk_map_and_copy+0x98/0x100
crypto_ccm_encrypt+0x150/0x180
crypto_aead_encrypt+0x2c/0x40
crypt_message+0x750/0x880
smb3_init_transform_rq+0x298/0x340
smb_send_rqst.part.11+0xd8/0x180
smb_send_rqst+0x3c/0x100
compound_send_recv+0x534/0xbc0
smb2_query_info_compound+0x32c/0x440
smb2_set_ea+0x438/0x4c0
cifs_xattr_set+0x5d4/0x7c0
This is because in scatterwalk_copychunks(), we attempted to write to
a buffer (@sign) that was allocated in the stack (vmalloc area) by
crypt_message() and thus accessing its remaining 8 (x2) bytes ended up
crossing a page boundary.
To simply fix it, we could just pass @sign kmalloc'd from
crypt_message() and then we're done. Luckily, we don't seem to pass
any other vmalloc'd buffers in smb_rqst::rq_iov...
Instead, let's map the correct pages and offsets from vmalloc buffers
as well in cifs_sg_set_buf() and then avoiding such oopses.
In the Linux kernel, the following vulnerability has been resolved:
rapidio: fix possible name leaks when rio_add_device() fails
Patch series "rapidio: fix three possible memory leaks".
This patchset fixes three name leaks in error handling.
- patch #1 fixes two name leaks while rio_add_device() fails.
- patch #2 fixes a name leak while rio_register_mport() fails.
This patch (of 2):
If rio_add_device() returns error, the name allocated by dev_set_name()
need be freed. It should use put_device() to give up the reference in the
error path, so that the name can be freed in kobject_cleanup(), and the
'rdev' can be freed in rio_release_dev().
In the Linux kernel, the following vulnerability has been resolved:
Bluetooth: avoid hci_dev_test_and_set_flag() in mgmt_init_hdev()
syzbot is again reporting attempt to cancel uninitialized work
at mgmt_index_removed() [1], for setting of HCI_MGMT flag from
mgmt_init_hdev() from hci_mgmt_cmd() from hci_sock_sendmsg() can
race with testing of HCI_MGMT flag from mgmt_index_removed() from
hci_sock_bind() due to lack of serialization via hci_dev_lock().
Since mgmt_init_hdev() is called with mgmt_chan_list_lock held, we can
safely split hci_dev_test_and_set_flag() into hci_dev_test_flag() and
hci_dev_set_flag(). Thus, in order to close this race, set HCI_MGMT flag
after INIT_DELAYED_WORK() completed.
This is a local fix based on mgmt_chan_list_lock. Lack of serialization
via hci_dev_lock() might be causing different race conditions somewhere
else. But a global fix based on hci_dev_lock() should deserve a future
patch.
WebAssembly Micro Runtime (WAMR) is a lightweight standalone WebAssembly (Wasm) runtime. In WAMR versions prior to 2.4.2, when running in LLVM-JIT mode, the runtime cannot exit normally when executing WebAssembly programs containing a memory.fill instruction where the first operand (memory address pointer) is greater than or equal to 2147483648 bytes (2GiB). This causes the runtime to hang in release builds or crash in debug builds due to accessing an invalid pointer. The issue does not occur in FAST-JIT mode or other runtime tools. This has been fixed in version 2.4.2.
A cross-site scripting (XSS) vulnerability exists in the search-autootaxi.php endpoint of the ATSMS web application. The application fails to properly sanitize user input submitted through a form field, allowing an attacker to inject arbitrary JavaScript code. The malicious payload is stored in the backend and executed when a user or administrator accesses the affected report page. This allows attackers to exfiltrate session cookies, hijack user sessions, and perform unauthorized actions in the context of the victims browser.
psPAS PowerShell module does not explicitly enforce TLS 1.2 within the 'Get-PASSAMLResponse' function during the SAML authentication process. An unauthenticated attacker in a 'Man-in-the-Middle' position could manipulate the TLS handshake and downgrade TLS to a deprecated protocol. Fixed in 7.0.209.