| CVE |
Vendors |
Products |
Updated |
CVSS v3.1 |
| In the Linux kernel, the following vulnerability has been resolved:
iio: adc: ti-ads1298: Add NULL check in ads1298_init
devm_kasprintf() can return a NULL pointer on failure. A check on the
return value of such a call in ads1298_init() is missing. Add it. |
| In the Linux kernel, the following vulnerability has been resolved:
exfat: fix the new buffer was not zeroed before writing
Before writing, if a buffer_head marked as new, its data must
be zeroed, otherwise uninitialized data in the page cache will
be written.
So this commit uses folio_zero_new_buffers() to zero the new
buffers before ->write_end(). |
| In the Linux kernel, the following vulnerability has been resolved:
fgraph: Add READ_ONCE() when accessing fgraph_array[]
In __ftrace_return_to_handler(), a loop iterates over the fgraph_array[]
elements, which are fgraph_ops. The loop checks if an element is a
fgraph_stub to prevent using a fgraph_stub afterward.
However, if the compiler reloads fgraph_array[] after this check, it might
race with an update to fgraph_array[] that introduces a fgraph_stub. This
could result in the stub being processed, but the stub contains a null
"func_hash" field, leading to a NULL pointer dereference.
To ensure that the gops compared against the fgraph_stub matches the gops
processed later, add a READ_ONCE(). A similar patch appears in commit
63a8dfb ("function_graph: Add READ_ONCE() when accessing fgraph_array[]"). |
| In the Linux kernel, the following vulnerability has been resolved:
gve: guard XSK operations on the existence of queues
This patch predicates the enabling and disabling of XSK pools on the
existence of queues. As it stands, if the interface is down, disabling
or enabling XSK pools would result in a crash, as the RX queue pointer
would be NULL. XSK pool registration will occur as part of the next
interface up.
Similarly, xsk_wakeup needs be guarded against queues disappearing
while the function is executing, so a check against the
GVE_PRIV_FLAGS_NAPI_ENABLED flag is added to synchronize with the
disabling of the bit and the synchronize_net() in gve_turndown. |
| In the Linux kernel, the following vulnerability has been resolved:
nfs: Fix oops in nfs_netfs_init_request() when copying to cache
When netfslib wants to copy some data that has just been read on behalf of
nfs, it creates a new write request and calls nfs_netfs_init_request() to
initialise it, but with a NULL file pointer. This causes
nfs_file_open_context() to oops - however, we don't actually need the nfs
context as we're only going to write to the cache.
Fix this by just returning if we aren't given a file pointer and emit a
warning if the request was for something other than copy-to-cache.
Further, fix nfs_netfs_free_request() so that it doesn't try to free the
context if the pointer is NULL. |
| In the Linux kernel, the following vulnerability has been resolved:
drm/amd/display: fix divide error in DM plane scale calcs
dm_get_plane_scale doesn't take into account plane scaled size equal to
zero, leading to a kernel oops due to division by zero. Fix by setting
out-scale size as zero when the dst size is zero, similar to what is
done by drm_calc_scale(). This issue started with the introduction of
cursor ovelay mode that uses this function to assess cursor mode changes
via dm_crtc_get_cursor_mode() before checking plane state.
[Dec17 17:14] Oops: divide error: 0000 [#1] PREEMPT SMP NOPTI
[ +0.000018] CPU: 5 PID: 1660 Comm: surface-DP-1 Not tainted 6.10.0+ #231
[ +0.000007] Hardware name: Valve Jupiter/Jupiter, BIOS F7A0131 01/30/2024
[ +0.000004] RIP: 0010:dm_get_plane_scale+0x3f/0x60 [amdgpu]
[ +0.000553] Code: 44 0f b7 41 3a 44 0f b7 49 3e 83 e0 0f 48 0f a3 c2 73 21 69 41 28 e8 03 00 00 31 d2 41 f7 f1 31 d2 89 06 69 41 2c e8 03 00 00 <41> f7 f0 89 07 e9 d7 d8 7e e9 44 89 c8 45 89 c1 41 89 c0 eb d4 66
[ +0.000005] RSP: 0018:ffffa8df0de6b8a0 EFLAGS: 00010246
[ +0.000006] RAX: 00000000000003e8 RBX: ffff9ac65c1f6e00 RCX: ffff9ac65d055500
[ +0.000003] RDX: 0000000000000000 RSI: ffffa8df0de6b8b0 RDI: ffffa8df0de6b8b4
[ +0.000004] RBP: ffff9ac64e7a5800 R08: 0000000000000000 R09: 0000000000000a00
[ +0.000003] R10: 00000000000000ff R11: 0000000000000054 R12: ffff9ac6d0700010
[ +0.000003] R13: ffff9ac65d054f00 R14: ffff9ac65d055500 R15: ffff9ac64e7a60a0
[ +0.000004] FS: 00007f869ea00640(0000) GS:ffff9ac970080000(0000) knlGS:0000000000000000
[ +0.000004] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ +0.000003] CR2: 000055ca701becd0 CR3: 000000010e7f2000 CR4: 0000000000350ef0
[ +0.000004] Call Trace:
[ +0.000007] <TASK>
[ +0.000006] ? __die_body.cold+0x19/0x27
[ +0.000009] ? die+0x2e/0x50
[ +0.000007] ? do_trap+0xca/0x110
[ +0.000007] ? do_error_trap+0x6a/0x90
[ +0.000006] ? dm_get_plane_scale+0x3f/0x60 [amdgpu]
[ +0.000504] ? exc_divide_error+0x38/0x50
[ +0.000005] ? dm_get_plane_scale+0x3f/0x60 [amdgpu]
[ +0.000488] ? asm_exc_divide_error+0x1a/0x20
[ +0.000011] ? dm_get_plane_scale+0x3f/0x60 [amdgpu]
[ +0.000593] dm_crtc_get_cursor_mode+0x33f/0x430 [amdgpu]
[ +0.000562] amdgpu_dm_atomic_check+0x2ef/0x1770 [amdgpu]
[ +0.000501] drm_atomic_check_only+0x5e1/0xa30 [drm]
[ +0.000047] drm_mode_atomic_ioctl+0x832/0xcb0 [drm]
[ +0.000050] ? __pfx_drm_mode_atomic_ioctl+0x10/0x10 [drm]
[ +0.000047] drm_ioctl_kernel+0xb3/0x100 [drm]
[ +0.000062] drm_ioctl+0x27a/0x4f0 [drm]
[ +0.000049] ? __pfx_drm_mode_atomic_ioctl+0x10/0x10 [drm]
[ +0.000055] amdgpu_drm_ioctl+0x4e/0x90 [amdgpu]
[ +0.000360] __x64_sys_ioctl+0x97/0xd0
[ +0.000010] do_syscall_64+0x82/0x190
[ +0.000008] ? __pfx_drm_mode_createblob_ioctl+0x10/0x10 [drm]
[ +0.000044] ? srso_return_thunk+0x5/0x5f
[ +0.000006] ? drm_ioctl_kernel+0xb3/0x100 [drm]
[ +0.000040] ? srso_return_thunk+0x5/0x5f
[ +0.000005] ? __check_object_size+0x50/0x220
[ +0.000007] ? srso_return_thunk+0x5/0x5f
[ +0.000005] ? srso_return_thunk+0x5/0x5f
[ +0.000005] ? drm_ioctl+0x2a4/0x4f0 [drm]
[ +0.000039] ? __pfx_drm_mode_createblob_ioctl+0x10/0x10 [drm]
[ +0.000043] ? srso_return_thunk+0x5/0x5f
[ +0.000005] ? srso_return_thunk+0x5/0x5f
[ +0.000005] ? __pm_runtime_suspend+0x69/0xc0
[ +0.000006] ? srso_return_thunk+0x5/0x5f
[ +0.000005] ? amdgpu_drm_ioctl+0x71/0x90 [amdgpu]
[ +0.000366] ? srso_return_thunk+0x5/0x5f
[ +0.000006] ? syscall_exit_to_user_mode+0x77/0x210
[ +0.000007] ? srso_return_thunk+0x5/0x5f
[ +0.000005] ? do_syscall_64+0x8e/0x190
[ +0.000006] ? srso_return_thunk+0x5/0x5f
[ +0.000006] ? do_syscall_64+0x8e/0x190
[ +0.000006] ? srso_return_thunk+0x5/0x5f
[ +0.000007] entry_SYSCALL_64_after_hwframe+0x76/0x7e
[ +0.000008] RIP: 0033:0x55bb7cd962bc
[ +0.000007] Code: 4c 89 6c 24 18 4c 89 64 24 20 4c 89 74 24 28 0f 57 c0 0f 11 44 24 30 89 c7 48 8d 54 24 08 b8 10 00 00 00 be bc 64
---truncated--- |
| In the Linux kernel, the following vulnerability has been resolved:
usb: typec: tcpci: fix NULL pointer issue on shared irq case
The tcpci_irq() may meet below NULL pointer dereference issue:
[ 2.641851] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000010
[ 2.641951] status 0x1, 0x37f
[ 2.650659] Mem abort info:
[ 2.656490] ESR = 0x0000000096000004
[ 2.660230] EC = 0x25: DABT (current EL), IL = 32 bits
[ 2.665532] SET = 0, FnV = 0
[ 2.668579] EA = 0, S1PTW = 0
[ 2.671715] FSC = 0x04: level 0 translation fault
[ 2.676584] Data abort info:
[ 2.679459] ISV = 0, ISS = 0x00000004, ISS2 = 0x00000000
[ 2.684936] CM = 0, WnR = 0, TnD = 0, TagAccess = 0
[ 2.689980] GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0
[ 2.695284] [0000000000000010] user address but active_mm is swapper
[ 2.701632] Internal error: Oops: 0000000096000004 [#1] PREEMPT SMP
[ 2.707883] Modules linked in:
[ 2.710936] CPU: 1 UID: 0 PID: 87 Comm: irq/111-2-0051 Not tainted 6.12.0-rc6-06316-g7f63786ad3d1-dirty #4
[ 2.720570] Hardware name: NXP i.MX93 11X11 EVK board (DT)
[ 2.726040] pstate: 60400009 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)
[ 2.732989] pc : tcpci_irq+0x38/0x318
[ 2.736647] lr : _tcpci_irq+0x14/0x20
[ 2.740295] sp : ffff80008324bd30
[ 2.743597] x29: ffff80008324bd70 x28: ffff800080107894 x27: ffff800082198f70
[ 2.750721] x26: ffff0000050e6680 x25: ffff000004d172ac x24: ffff0000050f0000
[ 2.757845] x23: ffff000004d17200 x22: 0000000000000001 x21: ffff0000050f0000
[ 2.764969] x20: ffff000004d17200 x19: 0000000000000000 x18: 0000000000000001
[ 2.772093] x17: 0000000000000000 x16: ffff80008183d8a0 x15: ffff00007fbab040
[ 2.779217] x14: ffff00007fb918c0 x13: 0000000000000000 x12: 000000000000017a
[ 2.786341] x11: 0000000000000001 x10: 0000000000000a90 x9 : ffff80008324bd00
[ 2.793465] x8 : ffff0000050f0af0 x7 : ffff00007fbaa840 x6 : 0000000000000031
[ 2.800589] x5 : 000000000000017a x4 : 0000000000000002 x3 : 0000000000000002
[ 2.807713] x2 : ffff80008324bd3a x1 : 0000000000000010 x0 : 0000000000000000
[ 2.814838] Call trace:
[ 2.817273] tcpci_irq+0x38/0x318
[ 2.820583] _tcpci_irq+0x14/0x20
[ 2.823885] irq_thread_fn+0x2c/0xa8
[ 2.827456] irq_thread+0x16c/0x2f4
[ 2.830940] kthread+0x110/0x114
[ 2.834164] ret_from_fork+0x10/0x20
[ 2.837738] Code: f9426420 f9001fe0 d2800000 52800201 (f9400a60)
This may happen on shared irq case. Such as two Type-C ports share one
irq. After the first port finished tcpci_register_port(), it may trigger
interrupt. However, if the interrupt comes by chance the 2nd port finishes
devm_request_threaded_irq(), the 2nd port interrupt handler will run at
first. Then the above issue happens due to tcpci is still a NULL pointer
in tcpci_irq() when dereference to regmap.
devm_request_threaded_irq()
<-- port1 irq comes
disable_irq(client->irq);
tcpci_register_port()
This will restore the logic to the state before commit (77e85107a771 "usb:
typec: tcpci: support edge irq").
However, moving tcpci_register_port() earlier creates a problem when use
edge irq because tcpci_init() will be called before
devm_request_threaded_irq(). The tcpci_init() writes the ALERT_MASK to
the hardware to tell it to start generating interrupts but we're not ready
to deal with them yet, then the ALERT events may be missed and ALERT line
will not recover to high level forever. To avoid the issue, this will also
set ALERT_MASK register after devm_request_threaded_irq() return. |
| In the Linux kernel, the following vulnerability has been resolved:
iio: light: bh1745: fix information leak in triggered buffer
The 'scan' local struct is used to push data to user space from a
triggered buffer, but it does not set values for inactive channels, as
it only uses iio_for_each_active_channel() to assign new values.
Initialize the struct to zero before using it to avoid pushing
uninitialized information to userspace. |
| In the Linux kernel, the following vulnerability has been resolved:
iio: adc: ti-ads1119: fix information leak in triggered buffer
The 'scan' local struct is used to push data to user space from a
triggered buffer, but it has a hole between the sample (unsigned int)
and the timestamp. This hole is never initialized.
Initialize the struct to zero before using it to avoid pushing
uninitialized information to userspace. |
| In the Linux kernel, the following vulnerability has been resolved:
ksmbd: set ATTR_CTIME flags when setting mtime
David reported that the new warning from setattr_copy_mgtime is coming
like the following.
[ 113.215316] ------------[ cut here ]------------
[ 113.215974] WARNING: CPU: 1 PID: 31 at fs/attr.c:300 setattr_copy+0x1ee/0x200
[ 113.219192] CPU: 1 UID: 0 PID: 31 Comm: kworker/1:1 Not tainted 6.13.0-rc1+ #234
[ 113.220127] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.2-3-gd478f380-rebuilt.opensuse.org 04/01/2014
[ 113.221530] Workqueue: ksmbd-io handle_ksmbd_work [ksmbd]
[ 113.222220] RIP: 0010:setattr_copy+0x1ee/0x200
[ 113.222833] Code: 24 28 49 8b 44 24 30 48 89 53 58 89 43 6c 5b 41 5c 41 5d 41 5e 41 5f 5d c3 cc cc cc cc 48 89 df e8 77 d6 ff ff e9 cd fe ff ff <0f> 0b e9 be fe ff ff 66 0
[ 113.225110] RSP: 0018:ffffaf218010fb68 EFLAGS: 00010202
[ 113.225765] RAX: 0000000000000120 RBX: ffffa446815f8568 RCX: 0000000000000003
[ 113.226667] RDX: ffffaf218010fd38 RSI: ffffa446815f8568 RDI: ffffffff94eb03a0
[ 113.227531] RBP: ffffaf218010fb90 R08: 0000001a251e217d R09: 00000000675259fa
[ 113.228426] R10: 0000000002ba8a6d R11: ffffa4468196c7a8 R12: ffffaf218010fd38
[ 113.229304] R13: 0000000000000120 R14: ffffffff94eb03a0 R15: 0000000000000000
[ 113.230210] FS: 0000000000000000(0000) GS:ffffa44739d00000(0000) knlGS:0000000000000000
[ 113.231215] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 113.232055] CR2: 00007efe0053d27e CR3: 000000000331a000 CR4: 00000000000006b0
[ 113.232926] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
[ 113.233812] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
[ 113.234797] Call Trace:
[ 113.235116] <TASK>
[ 113.235393] ? __warn+0x73/0xd0
[ 113.235802] ? setattr_copy+0x1ee/0x200
[ 113.236299] ? report_bug+0xf3/0x1e0
[ 113.236757] ? handle_bug+0x4d/0x90
[ 113.237202] ? exc_invalid_op+0x13/0x60
[ 113.237689] ? asm_exc_invalid_op+0x16/0x20
[ 113.238185] ? setattr_copy+0x1ee/0x200
[ 113.238692] btrfs_setattr+0x80/0x820 [btrfs]
[ 113.239285] ? get_stack_info_noinstr+0x12/0xf0
[ 113.239857] ? __module_address+0x22/0xa0
[ 113.240368] ? handle_ksmbd_work+0x6e/0x460 [ksmbd]
[ 113.240993] ? __module_text_address+0x9/0x50
[ 113.241545] ? __module_address+0x22/0xa0
[ 113.242033] ? unwind_next_frame+0x10e/0x920
[ 113.242600] ? __pfx_stack_trace_consume_entry+0x10/0x10
[ 113.243268] notify_change+0x2c2/0x4e0
[ 113.243746] ? stack_depot_save_flags+0x27/0x730
[ 113.244339] ? set_file_basic_info+0x130/0x2b0 [ksmbd]
[ 113.244993] set_file_basic_info+0x130/0x2b0 [ksmbd]
[ 113.245613] ? process_scheduled_works+0xbe/0x310
[ 113.246181] ? worker_thread+0x100/0x240
[ 113.246696] ? kthread+0xc8/0x100
[ 113.247126] ? ret_from_fork+0x2b/0x40
[ 113.247606] ? ret_from_fork_asm+0x1a/0x30
[ 113.248132] smb2_set_info+0x63f/0xa70 [ksmbd]
ksmbd is trying to set the atime and mtime via notify_change without also
setting the ctime. so This patch add ATTR_CTIME flags when setting mtime
to avoid a warning. |
| In the Linux kernel, the following vulnerability has been resolved:
mm/page_alloc: don't call pfn_to_page() on possibly non-existent PFN in split_large_buddy()
In split_large_buddy(), we might call pfn_to_page() on a PFN that might
not exist. In corner cases, such as when freeing the highest pageblock in
the last memory section, this could result with CONFIG_SPARSEMEM &&
!CONFIG_SPARSEMEM_EXTREME in __pfn_to_section() returning NULL and and
__section_mem_map_addr() dereferencing that NULL pointer.
Let's fix it, and avoid doing a pfn_to_page() call for the first
iteration, where we already have the page.
So far this was found by code inspection, but let's just CC stable as the
fix is easy. |
| In the Linux kernel, the following vulnerability has been resolved:
arm64: ptrace: fix partial SETREGSET for NT_ARM_FPMR
Currently fpmr_set() doesn't initialize the temporary 'fpmr' variable,
and a SETREGSET call with a length of zero will leave this
uninitialized. Consequently an arbitrary value will be written back to
target->thread.uw.fpmr, potentially leaking up to 64 bits of memory from
the kernel stack. The read is limited to a specific slot on the stack,
and the issue does not provide a write mechanism.
Fix this by initializing the temporary value before copying the regset
from userspace, as for other regsets (e.g. NT_PRSTATUS, NT_PRFPREG,
NT_ARM_SYSTEM_CALL). In the case of a zero-length write, the existing
contents of FPMR will be retained.
Before this patch:
| # ./fpmr-test
| Attempting to write NT_ARM_FPMR::fpmr = 0x900d900d900d900d
| SETREGSET(nt=0x40e, len=8) wrote 8 bytes
|
| Attempting to read NT_ARM_FPMR::fpmr
| GETREGSET(nt=0x40e, len=8) read 8 bytes
| Read NT_ARM_FPMR::fpmr = 0x900d900d900d900d
|
| Attempting to write NT_ARM_FPMR (zero length)
| SETREGSET(nt=0x40e, len=0) wrote 0 bytes
|
| Attempting to read NT_ARM_FPMR::fpmr
| GETREGSET(nt=0x40e, len=8) read 8 bytes
| Read NT_ARM_FPMR::fpmr = 0xffff800083963d50
After this patch:
| # ./fpmr-test
| Attempting to write NT_ARM_FPMR::fpmr = 0x900d900d900d900d
| SETREGSET(nt=0x40e, len=8) wrote 8 bytes
|
| Attempting to read NT_ARM_FPMR::fpmr
| GETREGSET(nt=0x40e, len=8) read 8 bytes
| Read NT_ARM_FPMR::fpmr = 0x900d900d900d900d
|
| Attempting to write NT_ARM_FPMR (zero length)
| SETREGSET(nt=0x40e, len=0) wrote 0 bytes
|
| Attempting to read NT_ARM_FPMR::fpmr
| GETREGSET(nt=0x40e, len=8) read 8 bytes
| Read NT_ARM_FPMR::fpmr = 0x900d900d900d900d |
| In the Linux kernel, the following vulnerability has been resolved:
arm64: ptrace: fix partial SETREGSET for NT_ARM_POE
Currently poe_set() doesn't initialize the temporary 'ctrl' variable,
and a SETREGSET call with a length of zero will leave this
uninitialized. Consequently an arbitrary value will be written back to
target->thread.por_el0, potentially leaking up to 64 bits of memory from
the kernel stack. The read is limited to a specific slot on the stack,
and the issue does not provide a write mechanism.
Fix this by initializing the temporary value before copying the regset
from userspace, as for other regsets (e.g. NT_PRSTATUS, NT_PRFPREG,
NT_ARM_SYSTEM_CALL). In the case of a zero-length write, the existing
contents of POR_EL1 will be retained.
Before this patch:
| # ./poe-test
| Attempting to write NT_ARM_POE::por_el0 = 0x900d900d900d900d
| SETREGSET(nt=0x40f, len=8) wrote 8 bytes
|
| Attempting to read NT_ARM_POE::por_el0
| GETREGSET(nt=0x40f, len=8) read 8 bytes
| Read NT_ARM_POE::por_el0 = 0x900d900d900d900d
|
| Attempting to write NT_ARM_POE (zero length)
| SETREGSET(nt=0x40f, len=0) wrote 0 bytes
|
| Attempting to read NT_ARM_POE::por_el0
| GETREGSET(nt=0x40f, len=8) read 8 bytes
| Read NT_ARM_POE::por_el0 = 0xffff8000839c3d50
After this patch:
| # ./poe-test
| Attempting to write NT_ARM_POE::por_el0 = 0x900d900d900d900d
| SETREGSET(nt=0x40f, len=8) wrote 8 bytes
|
| Attempting to read NT_ARM_POE::por_el0
| GETREGSET(nt=0x40f, len=8) read 8 bytes
| Read NT_ARM_POE::por_el0 = 0x900d900d900d900d
|
| Attempting to write NT_ARM_POE (zero length)
| SETREGSET(nt=0x40f, len=0) wrote 0 bytes
|
| Attempting to read NT_ARM_POE::por_el0
| GETREGSET(nt=0x40f, len=8) read 8 bytes
| Read NT_ARM_POE::por_el0 = 0x900d900d900d900d |
| In the Linux kernel, the following vulnerability has been resolved:
scsi: ufs: pltfrm: Dellocate HBA during ufshcd_pltfrm_remove()
This will ensure that the scsi host is cleaned up properly using
scsi_host_dev_release(). Otherwise, it may lead to memory leaks. |
| In the Linux kernel, the following vulnerability has been resolved:
phy: rockchip: samsung-hdptx: Set drvdata before enabling runtime PM
In some cases, rk_hdptx_phy_runtime_resume() may be invoked before
platform_set_drvdata() is executed in ->probe(), leading to a NULL
pointer dereference when using the return of dev_get_drvdata().
Ensure platform_set_drvdata() is called before devm_pm_runtime_enable(). |
| In the Linux kernel, the following vulnerability has been resolved:
drm/amd/display: Adding array index check to prevent memory corruption
[Why & How]
Array indices out of bound caused memory corruption. Adding checks to
ensure that array index stays in bound. |
| In the Linux kernel, the following vulnerability has been resolved:
drm/amd/display: Fix handling of plane refcount
[Why]
The mechanism to backup and restore plane states doesn't maintain
refcount, which can cause issues if the refcount of the plane changes
in between backup and restore operations, such as memory leaks if the
refcount was supposed to go down, or double frees / invalid memory
accesses if the refcount was supposed to go up.
[How]
Cache and re-apply current refcount when restoring plane states. |
| In the Linux kernel, the following vulnerability has been resolved:
kunit: Fix potential null dereference in kunit_device_driver_test()
kunit_kzalloc() may return a NULL pointer, dereferencing it without
NULL check may lead to NULL dereference.
Add a NULL check for test_state. |
| In the Linux kernel, the following vulnerability has been resolved:
mtd: spinand: winbond: Fix 512GW, 01GW, 01JW and 02JW ECC information
These four chips:
* W25N512GW
* W25N01GW
* W25N01JW
* W25N02JW
all require a single bit of ECC strength and thus feature an on-die
Hamming-like ECC engine. There is no point in filling a ->get_status()
callback for them because the main ECC status bytes are located in
standard places, and retrieving the number of bitflips in case of
corrected chunk is both useless and unsupported (if there are bitflips,
then there is 1 at most, so no need to query the chip for that).
Without this change, a kernel warning triggers every time a bit flips. |
| In the Linux kernel, the following vulnerability has been resolved:
bpf: Fix bpf_get_smp_processor_id() on !CONFIG_SMP
On x86-64 calling bpf_get_smp_processor_id() in a kernel with CONFIG_SMP
disabled can trigger the following bug, as pcpu_hot is unavailable:
[ 8.471774] BUG: unable to handle page fault for address: 00000000936a290c
[ 8.471849] #PF: supervisor read access in kernel mode
[ 8.471881] #PF: error_code(0x0000) - not-present page
Fix by inlining a return 0 in the !CONFIG_SMP case. |
